Inside a 72-hour assumed-breach operation
What actually happens, hour by hour, when a red team starts from a single compromised laptop.
Why start from the inside
Most organisations have tested their perimeter many times. 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 simple. We are given the access of a single ordinary employee: one laptop, one account, the permissions anyone in that role would have. Everything after that is earned.
What follows is a composite of how these operations tend to run. The details change with every organisation. The shape rarely does.
Before the clock starts
The first hours of the operation happen weeks earlier. We agree objectives with a small group who know the operation 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. Rules of engagement set out the systems that are off limits, the hours we will work and the point at which we stop if something looks fragile. A deconfliction channel means that if your team spots something and escalates, the sponsor can confirm quickly whether it is us or a real incident.
None of this is paperwork for its own sake. It 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 this time learning the environment from the position of the account we were given: what it can see, what it can reach and what looks normal.
The temptation is to move fast. The discipline is to move slowly. Every action is weighed against how it would look to a defender who was watching. The question is never only whether something is possible, but how loud it would be.
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 is about turning a map into a path. It rarely hinges on a single dramatic weakness. Far more often it is a chain of small, ordinary things: a permission broader than it needed to be, a shared resource that holds more than its owner realised, 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. This is why we document the chain rather than the individual items. The finding is the path.
Throughout, we log everything: what we did, when we did it and from where. That record becomes the backbone of the debrief.
Hours 60 to 72: the objective, and the evidence
Reaching the objective is not the end of the operation. Proving it is. We gather the minimum evidence needed to show the objective was met, without touching anything that would put the business at risk. Then we stop.
The final hours belong to the defenders' side of the story. We line up our log against what your monitoring recorded. Some actions will have been seen and acted on. Some will have been seen and dismissed. Some will not have been seen at all. Each group tells you something different, and the second is often the most valuable, because it shows where the signal existed and the judgement did not.
What to do about it
You do not need a full operation to start asking the right questions.
- Pick one ordinary account and ask honestly 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.