Service
Incident Response
Contain, evict and recover, then a root-cause account of how it happened.
Two things are needed at once during an incident and they conflict: stop the damage, and preserve enough evidence to understand what happened. Acting too fast destroys the answer, acting too slowly extends the damage. The work is sequencing those correctly under time pressure, and then producing an account honest enough to be useful afterwards.
How this works
Establish scope before acting
The first question is not how to remove the attacker but how far they have reached. Pulling one machine off the network while three others are compromised announces the response and achieves nothing. Scope comes from authentication logs, process and network telemetry, and the identity layer, and it is established quickly rather than exhaustively.
Contain in one move where possible
Containment is planned so it lands across the whole known footprint at once. Credentials rotated, sessions revoked, access removed and network paths closed together, because a staged response gives an attacker with any awareness time to re-establish through a route nobody has found yet.
Evict, including the persistence nobody looks for
Removing malware is the easy half. The half that gets missed is the persistence that survives it: an added multi-factor method, an OAuth application consent, a mail forwarding rule, an API key, a scheduled task, a modified service account. These outlive credential rotation and are how an organisation gets compromised twice by the same actor.
Root cause written honestly
The account states how entry was achieved, what was reached, what was taken if that can be established, and what could not be determined from the evidence available. The last of those matters: an investigation that answers every question is usually one that guessed at some of them.
What we look for
- Initial access vector, established from evidence rather than assumed
- The full account and host footprint before containment, not after
- Persistence mechanisms that survive password rotation, especially identity-layer ones
- Data staging and exfiltration: what was accessed, what left, and over which channel
- Whether the intrusion is ongoing or historic, which changes the response entirely
- Which existing telemetry recorded the activity and was never alerted on
What you get
- Containment and eviction guidance during the incident, in the order it should happen
- A written account of entry, spread, and impact, with what remains unknown stated as unknown
- Indicators of compromise in a form your tooling can consume
- Specific changes that would have prevented it, and the ones that would have caught it sooner
What this does not include
- Legal or regulatory notification advice, which needs your counsel
- Negotiation with an extortion actor
- Rebuilding infrastructure, though the sequence and priorities are advised
- Attribution to a named group, which is rarely determinable from one organisation's evidence and rarely changes what you do next
Questions people ask
- What should we do before you arrive?
- Preserve rather than clean. Do not wipe or rebuild affected machines, do not delete suspicious mailbox rules, and do not rotate every credential yet, because each of those destroys evidence of scope. Isolating a machine at the network level while leaving it powered on is usually the right first move.
- Do we need to take everything offline?
- Rarely, and doing it reflexively causes a self-inflicted outage while telling you nothing. Containment is targeted at the known footprint once scope is established, which is normally a small number of accounts and hosts.
- Will you tell us it was our fault?
- The account says what happened, including where a control was absent or ignored. It is written to be usable rather than comfortable, and without the language of blame, because a report that people argue with is a report nobody acts on.