Incident response on a compromised Windows laptop

Support

Incident response on a compromised Windows laptop

A method write-up.

Problem

A Windows machine had been compromised after a social-engineering phone call convinced someone to install remote-access software. Before anything could be wiped or "cleaned", the machine needed a proper look: how the attacker got in, what ran, and what evidence existed. The instinct to reboot and tidy up is the enemy of all three.

Diagnosis

The rules for this job are set by forensics, not convenience: never boot the compromised operating system, never write to the evidence drive, and reconstruct what happened from artefacts rather than memory. The plan was to work against the drive in read-only mode, identify persistence, and sequence events from the filesystem timeline.

Action

  • Worked against the drive with strictly read-only block access, so the source state could not change
  • Enumerated two independent persistence channels: a consumer remote-support tool, and a cloud-managed RMM agent pushed by the attacker
  • Reconstructed a timeline of attacker activity from the NTFS master file table
  • Recovered the RMM agent's local policy database, including the uninstall credential it had configured, which made clean removal possible instead of a wipe-and-hope
  • Wrote a phased incident report: containment, evidence, findings, remediation
  • Moved the laptop to Linux afterwards and gave the user an account with no admin access

Outcome

  • Two separate remote-access mechanisms identified and removed
  • A reconstructed timeline of the intrusion instead of guesswork
  • Clean removal using the agent's own recovered configuration
  • A repeatable triage process and report structure for the next incident

What I'd do differently

Pending

Reflection to be written by Jupiter.

Clock
--:--:--—Local time