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).
In the physical world we cordon off the crime scene and take pictures/video & other forensic evidence (e.g. fingerprints...etc.) of the crime scene. Expecting a cyber investigation to "physically" take a server is akin to physically moving the room out of the building.
Victim's 1st responsibility is to protect their: org, systems & data. Investigation always 2nd priority. Goals of investigation (in order) 1) Evict attacker asap (this may take days->weeks depending on sophistication of attacker & how established their presence is in the network)
2) While preping to evict attacker, monitor their activity(to ensure your remediation is successful &/or remediate early if attacker taking actions/data deemed too risky/valuable) 3) Scope historical activity (e.g. find backdoors & attacker activity, identify their motives/goals)
When dozens/hundreds of systems involved and attacker who is very active, it's also often impractical and/or unnecessary (if you have the right tools) to take a forensic image of every system.
Example: attacker accesses 300 systems and runs a password dumper on each one
@Mandiant we deploy @FireEye endpoint software to every system to scale investigation across the enterprise. We pull forensic data at scale to conduct historical investigation & monitor the attacker's activity in realtime. Only take images of systems of significant importance.
Majority of recent Presidential campaigns on both sides have been successfully compromised by nation states. In the past, the motive was to get an insight into politician's views on policies/positions important to the attacker's government. (next tweet has links to articles)
Think of presidential campaigns like hypergrowth startups (w/ relatively short end date). Most/all infrastructure is temporary & cloud based tech (office365/gsuite, AWS/Azure) instead of physical data centers.
Therefore, most systems aren't "physical" - it's virtual/cloud-based.
Trick question:
If all your servers are virtualized or cloud-based...then how do you take a "physical" server?
Exactly - you don't
Hypergrowth startups are so focused on growth that anything (including security measures) that detracts from executing on their goal/mission is usually ignored. Check out this thread by @dotMudge
In my experience, there are 3 types of cases. Investigations that are: 1) Never made public, or have little public/political interest 2) Involve private orgs that have major public/political interest (e.g. Equifax, Anthem...etc.) 3) Involve government and/or political orgs
For #DFIR professionals w/investigations at orgs like #2 or #3:
-Assume anything you say or put in writing w/ government/political org will get leaked for political purposes. I learned this the hard way coming from a heavy background in corporate cases where leaks rarely occur
-Every action you take will be put under intense scrutiny after the fact by non-technical "arm chair quarterbacks". It's helpful for you to document (at a minimum in your own notes) what you knew & when you knew it (as it's occurring) - so you can refer to this later
-The public & politicians expect that cyber investigations & remediation happen in hours/days when they take days/weeks or sometimes months. You can't change this expectation. (side note: this will only get worse with 72 hour notification requirement with GDPR)
-You're better off taking remediation sooner than you feel ready - at the risk/tradeoff that you will not successfully evict the attacker. This makes the ability to identify attacker activity in real-time becomes critical so you can respond if/when attacker becomes active again.
• • •
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.
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
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