EC2 DFIR Workshop

Module Overview: Why Forensicate?

• Reasons to Perform a Forensic Analysis
• NIST Incident Response Life Cycle
• Crucial Forensic Outputs DURING Incident Response
• PICERL Incident Response Life Cycle

Reasons to Perform a Forensic Analysis

• Who did it? (Attribution*)
• What happened?
• Where did it happen? (incident Scoping)
• When did it happen? (Timeline Analysis)
• Why? (Attacker Motivation*)
• How did it happen? (Root Cause Analysis)

*Attribution is difficult and may not be meaningful. Similarly determining attacker motivation generally assumes clear attribution.

NIST Incident Response Life Cycle

IMAGE 1: NIST Incident Response Life Cycle, NIST SP 800-61R2

Crucial Forensic Outputs DURING Incident Response

During an incident, it is critical to determine its SCOPE

Forensic analysis of select systems may be used to identify:

• Indicators of Compromise (IOC)
• Tactics, Techniques, and Procedures (TTP)
• Important events on the incident timeline

PICERL Incident Response Life Cycle

IMAGE 2: PICERL Incident Response Life Cycle

Preparation

• During a Security Incident, Time is of the essence
• Forensic Analysis takes time, reduce the time by being prepared
• Understand the strengths and limitations of your tools
• Practice…better yet DRILL

EXAMPLES

• Appropriate access and permissions
• Forensic Workstation pre-provisioned and up-to-date
• Memory Modules created in advance

Identification

• Generally, the earlier that an incident is detected the less harm
• Terminology Matters: Security Event / Security Incident / Breach
• Need clear protocol on how the Incident Response Plan is invoked
• Need clear steps (and training) for first responders

“Um, so, yeah…we had an EC2 instance that seemed to have malware, so we terminated it…just wanted to let you know”

Containment

Incident Handler’s Focus:

• “Stop the Bleeding”
• What systems are impacted? (Scope)

Forensicator’s Focus:

• What IOCs are on this system? (Incident Handlers can search across fleet)
• What weakness or vulnerability was exploited? (Used by Incident Handlers to contain the incident)
• When was this system compromised? (Used to determine scope and impact)
• Are other systems involved?

Eradication & Recovery

• Completely address the root cause
• Terminate infected instances, replace with fully patched and hardened ones
• Additional network segmentation controls
• Additional monitoring to ensure compromise does not re-occur
• Common Mistake: Eradication before Containment
• Reinfection or repeated compromise
• Whack-a-mole Game
• Recovery is complete when environment has been verified to be operating normally with the new countermeasures confirmed to be operating effectively

Lessons Learned

• “Never waste a crisis” – Never waste a Security Incident
• Drive your security agenda forward by taking advantage of teachable moments
• Use the feedback to improve DFIR Preparation and Response

Recommendations

• During incident capture and share notes with incident response team
• Create an Incident Report based the notes
• Conduct an Incident Post-Mortem using a draft of the Incident Report
• Do not finalize the Incident Report until after the Post-Mortem