Inside a 72-hour assumed-breach operation
Hour by hour: how a red team gets from one compromised laptop to the objective, and what the defenders saw on the way.
Why start from the inside
Most organisations have tested their perimeter many times, and far fewer have tested what happens after it fails. An assumed-breach operation skips the question of whether an adversary can get in and asks the more useful one: once they are in, how far can they get, and would anyone notice?
The starting point is the access of one ordinary employee: a laptop, an account and the permissions anyone in that role would have. Everything after that has to be earned.
What follows is a composite drawn from operations we have run. The details change with every organisation, and the shape is familiar in most of them.
Before the clock starts
The first hours of the operation happen weeks earlier. We agree objectives with a small group who know it is running, usually a sponsor and one or two senior defenders. The objectives are concrete: reach a named system, read a named dataset, demonstrate control of a named process.
We also agree what we will not do. The rules of engagement name the systems that are off limits, the hours we work and the point at which we stop if something looks fragile. A deconfliction channel lets the sponsor confirm within minutes whether an escalation from your team is us or a real incident.
That preparation is what lets us move like an adversary without behaving like one.
Hours 0 to 24: orientation
The first day is quiet by design. An adversary who has just landed does not know where they are, and neither do we. We spend the day learning the environment from the position of the account we were given, and in particular what counts as normal for it.
Every action is weighed against how it would look to a defender who was watching, so the pace stays slow and the footprint stays small.
By the end of the first day we usually have a working map of the parts of the organisation that matter to the objective, and a short list of routes that look promising.
Hours 24 to 60: closing the distance
The middle of the operation turns the map into a path. In most operations the path is a chain of small, ordinary things: a permission broader than it needed to be, and a trust relationship that made sense when it was created and has not been revisited since.
Each link on its own would sit low in a vulnerability report. Together they form the route, which is why we document the chain and treat the path itself as the finding.
Throughout, we log every action with its time and its source. That record becomes the backbone of the debrief.
Hours 60 to 72: the objective, and the evidence
Reaching the objective opens the final phase. We gather the minimum evidence needed to show it was met, without touching anything that would put the business at risk, and then we stop.
The last hours belong to the defenders' side of the story. We line up our log against what your monitoring recorded. Actions that were seen and acted on show the controls working. Actions that were seen and dismissed are the most valuable finding of the whole operation, because the signal existed and the judgement did not. Actions nobody saw tell you where the next sensor belongs.
What to do about it
You do not need a full operation to start asking the right questions.
- Pick one ordinary account and ask what it could reach in your environment today.
- Review the trust relationships and broad permissions that nobody has looked at since they were created.
- Test whether an alert that fires is investigated, as well as whether it fires.