2021-03-01 21:24:25
DFIR Post-Mortem Report Writing
Hi,
I wanted to seek some input or available examples of DFIR Post-Mortem report writing relating to attacks such as ransomware etc.
What granularity of detail do you go into?
For example, is it better to go event by event such as:
On the server named Domain Controller One the following actions occurred:
RDP Brute force identified from external IP starting at 02:29 UTC
Tools downloaded via PowerShell at 02:44 UTC
Network Enumeration tool executed at 02:48 UTC
Procmon.exe executed at 03:00 UTC
Ransomware.exe executed at 03:07 UTC
Or
Is it better to provide a higher level synopsis such as:
On 1 August 2020, At 02:29 UTC a brute force attack was identified on Domain Controller one from the external IP x.x.x.x and successfully gained access at 02:40 UTC. Tools were dropped onto the machine at 02:44 UTC. Subsequently, evidence shows the network was scanned, processes examined and ransomware was executed encrypting all user files with specific extensions.
What are the advantages of going deeper? Will there be too much technical information for someone to understand?
I find it can sometimes lead to analysis paralysis, as in some cases you are dealing with multiple machines with numerous artifacts making it difficult to properly work out what has occurred while also keeping in mind what will the target audience actually find beneficial in knowing.
Any advice? and apologies for my two examples they are just to provide an idea of what I am thinking.
rorywag
We use both in our reports.
Executive Summary starts the report and serves as our high level synopsis. Then we will have one or two paragraphs on each stage of the incident or malware analysis. Finally, we close out with a review/round up with our evaluations/recommendations.
We include a timeline of events identified during the analysis. Ours is slightly different as it includes vulnerabilities (if applicable) and system build/implementation dates.
Farstone
Overall the client doesn't care about us showing how smart we are are
They want to know:
how the attacker got in (so they can fix it)
what the attacker did (what did they see, what did they leave behind, do they still have a problem)
what did the attacker take (reporting obligations)
They don't tend to care about the more specific or academic granularity of the attack unless it's going to help them answer the above.
randomaccess3_dfirAlways consider your audience. If this will be going to upper level executives, you're going want to at least have an executive summary in layperson's terms for them to read. Dig deeper in subsequent sections that people with more technical knowledge can read.
Back when I worked in law enforcement, the go to words of advice were to explain everything as though you are talking to a fifth grader. Obviously you want to be careful about insulting people's intelligence, but for the high level explanation, don't go into any more technical detail than is necessary to explain the series of events and subsequent steps taken.
Executives (usually) just want to get a high level understanding of what was impacted (services/applications, not ip addresses or host names), what data is or may have been compromised, whether the bleeding has been stopped, and what steps have or are going to be taken to prevent it from happening again.
For the technical audience, be thorough but also concise. Technical writing is an art form and you will pick up what works for you and your audience over time.
not_a_terrorist89 @malwr
67 views18:24
M
