The breach that wasn’t on the laptop
A creative firm reported an email account doing things no one recognised. We were brought in to answer two questions — what actually happened, and is anything still inside. The answer was entirely cloud-side, and proving the endpoint was clean meant imaging a Mac that can’t be imaged the usual way.
A small creative firm called with a problem that sounds worse than it usually is: one of their email accounts had been taking actions no one recognised — messages moving, replies going out, rules firing — and the alerts mentioned “scripts.” To the people living it, that reads like malware on a machine. We were brought in to answer two questions, in order, and to resist the urge to answer anything else first.
Two questions, in order
What actually happened, and is anything still inside? Everything else — whose laptop, which app, what to rebuild — waits until those two are answered with evidence rather than assumption. The discipline matters because the obvious story (“a computer got infected and ran scripts”) is the one most likely to be wrong, and chasing it burns the hours that matter most in the first day of an incident.
The finding: it was cloud-side
The compromise was cloud-side. A mailbox with no multi-factor authentication was taken by a password-spray attack; the attacker signed in from overseas addresses and drove mailbox automation from the cloud, never from a company computer. The “scripts” in the alerts were server-side mail rules — inbox rules and automation running in the platform — not a program executing on anyone’s laptop. That single distinction changes the entire response: you are hardening an identity, not disinfecting a device.
The curveball: a decoy disk image
The disk image we were first handed turned out to be an empty rebuild scaffold — a fresh operating-system skeleton with no user data on it at all. Rather than trust the label on the file, we proved it was empty three independent ways, then went and located the actual machine and acquired it properly. The lesson we keep relearning: verify the scene before you reason about it. An artifact is not what its filename says it is until you’ve checked.
The method: imaging a Mac you can’t image the usual way
The endpoint was a modern Apple-Silicon Mac, which can’t be imaged with the traditional pull-the-disk, write-blocker workflow. So we triaged it live and read-only over an isolated, air-gapped link — collecting persistence mechanisms, running processes, remote-access configuration, and the usual indicators without altering the scene, then removing every artifact of our own access afterward. Read-only and reversible isn’t a nicety here; it’s what keeps the findings defensible if anyone ever asks how we know.
The result: a clean endpoint
The laptop was clean: no malware, no unauthorised remote access, no rogue administrator account, and every startup item traced back to a legitimate vendor. With the device ruled out on evidence, the conclusion was unambiguous — the breach lived entirely in the cloud account. We closed the endpoint question and handed over a remediation runbook.
- MFA everywhere — every account, no exceptions, starting with the mailbox that was taken
- Disable legacy / basic authentication so a stolen password alone can’t sign in
- Audit every mailbox rule and forwarding address for attacker-planted automation
- Conditional Access policies with a tested break-glass account
- Re-baseline sign-in logs and alert on impossible-travel and spray patterns
None of this is exotic. The work that made the difference was answering the right question first — identity, not endpoint — and being willing to prove the boring answer (“the laptop is clean”) to the same standard as an exciting one. That’s the field note: when an account starts acting on its own, look at the account.