Remediation strategy in #DFIR is always a fun topic - with many opinions & not always a clear rule book to follow. It's like the English language for every rule there are 5 exceptions. My views have evolved over time - from combo of experience & as monitoring tools have improved
If you catch attacker early in attack lifecycle - this one is pretty easy. Take action immediately before they get a strong foothold. Very few exceptions to this rule. Tipoffs you are early in attack lifecycle. Malware owned by primary user of system or malware in startup folder
Opposite end of spectrum - if attacker has been there for months/years - it will take at the very (and I mean very) least a few days to get bare minimum handle on infected systems & how accessing the environment. Bigger challenge is client ability to take "big" remediation steps
Most victims who have to remediate quickly, will do least resilient measures (e.g block IPs/domains, change affected passwords of few accounts, & rebuild a few systems). Biggest risk here is that you've missed a backdoor & inadequate remediation steps allow attacker to "run wild"
Once you've tipped your hand to attacker - you've committed your org to permanent whack-a-mole (for as long as it takes) until you've dealt w/ problem. For great example - check out @ItsReallyNick & @matthewdunwoody's No Easy Breach talk @DerbyCon#APT29
One time on day 1 of a compromise assessment - I found attacker had compressed a few hundred gigs of sensitive data the day before...but had only stolen a few of the split RAR archives. We were in a real pickle. They'd been there for months - and we had no idea scope of intrusion
We got creative & wrote tool that could corrupt password protected RAR archives & also rate limited attacker's C2 where they exfilled data. We watched the attacker steal (very slowly) RAR archives over the next few weeks while we scoped the intrusion & prepared for remediation
We accomplished the goal of protecting the client (and their data) while giving our teams the time and space to remediate. Side note: would love to see face of the Chinese APT operator(s) when they realized they spent a month downloading hundreds of Gigs of corrupted RAR archives
• • •
Missing some Tweet in this thread? You can try to
force a refresh
C-level credential phished while on vacation - APT34 used account access to phish entire company. Even though infosec team blocked URL on web proxy - employees switched to guest wi-fi to access the URL.
Here is a thread on the "missing" DNC server and my experience/advice from conducting similar investigations.
First, some background for my comments. Over the last decade, I've personally led investigations at over 100 organizations & taught dozens of classes for both federal law enforcement and the private sector on incident response and digital forensics.
I've never once physically acquired a server or asked someone to physically acquire a server. Literally the first thing you learn in digital forensics is how to take a forensic image (or in laymen's terms a complete copy of a computer).
Reading justice.gov/opa/pr/russian… today reminded me how I got my start in #DFIR in 2008 investigating FIN1. Let's take a walk down memory lane.
FIN1 (in my experience) has had a few major periods of activity (2007-2009, 2011-2012, and 2014-2015) - each with their own distinct set of TTPs. They've significantly improved their capabilities over the years (even though multiple members have been arrested)
FIN1 in the first period had the following TTPs: 1) didn't use backdoors 2) broke in commonly via SQL Injection 3) uploaded new tools by creating temporary tables and exporting the file via BCP 4) deployed a sniffer named sn.exe to identify systems with track data in memory