Read on Twitter
One of most undervalued aspects of incident response is incident documentation
In my experience as a consultant step 1 is interviewing client & reviewing whatever scattered notes
https://abs.twimg.com/emoji/v2/... draggable="false" alt="đ" title="Lesezeichen" aria-label="Emoji: Lesezeichen">https://abs.twimg.com/emoji/v2/... draggable="false" alt="đ" title="Memo" aria-label="Emoji: Memo">they have about an incident & organizing it in a logical manner b/c most orgs do this poorly https://abs.twimg.com/emoji/v2/... draggable="false" alt="đ" title="Nichts sehen-Affe" aria-label="Emoji: Nichts sehen-Affe">
In my experience as a consultant step 1 is interviewing client & reviewing whatever scattered notes
Challenge is analysts (due to crisis) move fast to respond quickly & most orgs donât experience impactful breaches often
This leads to scattered knowledge/understanding & each analyst documenting things in their own way that is efficient for them but not overall investigation
This leads to scattered knowledge/understanding & each analyst documenting things in their own way that is efficient for them but not overall investigation
In my experience - here are the most important things to track (a spreadsheet is my preferred tool)
One table for each of the following:
-Timeline of forensic artifacts
-Systems
-Indicators (I prefer separate table for host and network)
-Compromised accounts
One table for each of the following:
-Timeline of forensic artifacts
-Systems
-Indicators (I prefer separate table for host and network)
-Compromised accounts
Key timeline elements:
-Timestamp (UTC time in ISO 8601 format 2020-07-20T13:27:36Z)
-Forensic artifact description (e.g MFT Created)
-System
-Summary (normalized field w/most important data)
-User account
-Hash
-Attribution
-Comment
Gives chronological view of entire incident
-Timestamp (UTC time in ISO 8601 format 2020-07-20T13:27:36Z)
-Forensic artifact description (e.g MFT Created)
-System
-Summary (normalized field w/most important data)
-User account
-Hash
-Attribution
-Comment
Gives chronological view of entire incident
Key elements to track for systems (note: most likely table to be customized per incident)
-Hostname
-IP
-OS
-Date added
-System status
-Investigative lead
-Multiple fields to track forensic acquisition status & date, analyst assigned, analysis status, remediation status/date
-Hostname
-IP
-OS
-Date added
-System status
-Investigative lead
-Multiple fields to track forensic acquisition status & date, analyst assigned, analysis status, remediation status/date
When tracking system status - what we settled on @Mandiant was the following:
-Infected (actor deployed malware that would enable them to regain access [backdoor, webshell...etc])
-Accessed
-Compromised (superset of infected & accessed systems)
-TBD (needs further analysis)
-Infected (actor deployed malware that would enable them to regain access [backdoor, webshell...etc])
-Accessed
-Compromised (superset of infected & accessed systems)
-TBD (needs further analysis)
I think youâre better off being more conservative w/system status. TBD systems move to FP or Accessed/Infected. Accessed systems only move to Infected
Only put system in category when solid evidence
Example: netflow data of actor IP connecting to system isnât âproofâ of access
Only put system in category when solid evidence
Example: netflow data of actor IP connecting to system isnât âproofâ of access
Note regarding system status - a threat actor running malware/tools on a system (say it a password dumper) doesnât make it infected. It would have been accessed until you find evidence enabling access (e.g backdoor, sticky keys exploit, webshell).
Key elements to track for indicators:
-Indicator description (File name, IP address...etc)
-Indicator detail
-System identified on (at least one - doesnât have to be all)
-Attribution
-Relations (for IPs track hashes and vice versa & filenames track hashes)
-Date added
-Comment
-Indicator description (File name, IP address...etc)
-Indicator detail
-System identified on (at least one - doesnât have to be all)
-Attribution
-Relations (for IPs track hashes and vice versa & filenames track hashes)
-Date added
-Comment
In general youâll see a pattern emerge that enables you to figure out when you learned something, what itâs attributed to & make connections between each of the independent tables for all of your incident data & enable quick/automated generation of key incident metrics
Speaking of key incident metrics here are some important ones I usually track (sometimes per threat actor):
-earliest evidence of compromise
-most recent evidence of activity
-# compomised systems (with breakdown of infected vs. accessed)
-# of systems requiring analysis
-earliest evidence of compromise
-most recent evidence of activity
-# compomised systems (with breakdown of infected vs. accessed)
-# of systems requiring analysis
Is this a lot of work to maintain - you bet
Youâre role as an investigative lead is like a point guard in basketball. You run offense but rest of team does bulk of the scoring. You need complete mastery of technical details - but you arenât the one generating the findings
Youâre role as an investigative lead is like a point guard in basketball. You run offense but rest of team does bulk of the scoring. You need complete mastery of technical details - but you arenât the one generating the findings
