ZEKASTRA

Ransomware, intrusion, insider

Incident response and breach investigation

Incident response is forensics under time pressure. Containment and evidence preservation pull in opposite directions; the discipline is to collect the volatile and fragile evidence first, in a defined order, so that the later questions of how, since when and what was taken can still be answered.

01Scope

  • Triage: what to collect from many hosts fast (event logs, registry, Prefetch, Amcache, $MFT, memory where justified)
  • Initial access, persistence, privilege escalation, lateral movement, exfiltration, impact
  • Account compromise in directories and cloud identity
  • Ransomware: encryption start, affected shares, deleted shadow copies, ransom note artifacts
  • Evidence for notification and regulatory decisions: which data, how much, which subjects

02Questions it answers

  • How did the attacker get in, and when was the earliest sign?
  • Which systems and accounts were touched, in what order?
  • Was data accessed or taken, and can the volume and content be bounded?
  • Is the attacker still present, and through which persistence?
  • What evidence supports or refutes a notification obligation?

03Evidence used

SourceWhat it yieldsNote
Triage packages from each host (logs, registry hives, Prefetch, Amcache, $MFT, $UsnJrnl, scheduled tasks)Execution, persistence and file activity at scaleHash each package; record the collection tool and the host clock offset.
Domain controller Security logs and directory change recordsAuthentication across the estate, account creation, group changes, Kerberos activityThe DC is where lateral movement becomes visible; preserve its logs first.
EDR, antivirus, firewall, VPN and proxy telemetryProcess trees, blocked actions, remote sessions, outbound volumesExport raw events with their own time zone noted; dashboards summarise and drop detail.
Memory images of key hosts and full images of patient-zero systemsTooling in memory, decrypted payloads, the initial access vectorImage before rebuild; a rebuilt host is lost evidence.
Backups and their logsClean reference copies; evidence of backup deletion or tamperingCompare a pre-incident backup with the live system to find what changed.

04How it is approached

  1. Open the incident record

    One log, one clock (UTC), one owner. Every action, decision and collected item gets a line with time and person. This record is later evidence of due diligence.

  2. Preserve before you contain, where the risk allows

    Isolate at the network rather than powering off; capture memory on the hosts that matter; extend log retention and export cloud logs; snapshot virtual machines.

  3. Build one timeline from all sources

    Host artifacts, directory logs, telemetry and cloud logs on one UTC axis with per-source offsets applied. Mark the first and last attacker action per host.

  4. Scope by pivoting on indicators

    Each confirmed indicator (account, hash, IP, tool name, task name) is searched across every source; each hit extends the scope and the timeline.

  5. Bound the data impact honestly

    Access logs, file-server audit, staging archives, outbound transfer volumes. Where evidence is absent, say 'cannot be excluded', not 'no evidence of'.

05Artifacts

The library records behind this area:

06Pitfalls

  • Rebuilding or rebooting systems during containment destroys memory and volatile evidence; decide deliberately.
  • The earliest alert is rarely the earliest access; search back from the first indicator.
  • Encryption time is the end of the attack, not the beginning.
  • Indicators from threat reports are hypotheses to test in this environment, not findings.
  • Absence of exfiltration evidence often reflects absence of logging, and must be reported that way.

07What the report states

  • Incident record extract: who did what, when, under whose decision.
  • Evidence inventory with hashes, sources, collection times and clock offsets.
  • Attack timeline per phase, with the artifact behind each entry.
  • Data impact statement separating confirmed access, probable access and cannot-be-excluded.
  • Root cause and the evidence gap list.

08Questions to ask a report

  • Which systems were imaged or memory-captured before containment changed them?
  • How far back was the earliest attacker activity traced, and from which artifact?
  • What exactly supports the statement about data taken, and what logging was missing?
  • Is the timeline built with per-source clock offsets?

09Standards

  1. NIST SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations
  2. NIST SP 800-86 — Guide to Integrating Forensic Techniques into Incident Response
  3. ISO/IEC 27043:2015 — Incident investigation principles and processes
  4. ISO/IEC 27035-1:2023 — Information security incident management
  5. MITRE ATT&CK — Enterprise matrix