The First Hour After You Find a Breach

The first hour produces a great many actions and almost no record, and everything that comes after it depends on that record. Open a note somewhere outside the systems you are worried about. A paper pad is fine. A note on your phone is fine.

Write down the time you noticed, what you saw, and who told you. Then log every action against the time you took it. Account disabled. Cable pulled. Call made to the provider. You will want this for the investigation, for your insurer, possibly for a regulator, and for the meeting in a fortnight where nobody can remember whether the password was reset before or after the sessions were revoked.

Leave the original evidence where you found it. Do not forward the suspicious email to five colleagues and then delete it from the mailbox it arrived in. Export it properly with the headers intact, or leave it in place and record exactly where it is.

Move the conversation off the systems you suspect. If the mail platform may be compromised, discussing your containment plan over company email hands that plan to the person you are containing. Agree a channel now: a group chat on a different platform, or the phone.

Containment and evidence pull against each other for a short while. Isolation is what resolves the tension. You want the attacker cut off and the machine intact, and both are achievable at once.

Pull the network cable, or disable the wireless adapter, or move the machine onto an isolated network. Leave it switched on. Everything living in memory goes when the power does, and memory is where you find the running process, the keys it is holding and the connections it has open.

On accounts, disable rather than delete. A deleted account takes its sign in history, its mailbox rules and its permission grants with it, and those are precisely the records that answer the question of what was reached.

For a cloud account or a server you cannot walk up to, the equivalent moves are revoking active sessions and refresh tokens, resetting the password, removing the account from privileged groups, and blocking sign ins from the addresses involved. If the platform can snapshot the machine before you change anything, do that first.

There is a right order and it is not the obvious one. First, the person in your organisation who can make decisions and commit money without asking anybody. Usually a director. They do not need to be technical. They need to be awake and reachable. Second, whoever runs your IT, whether that is an internal team or an outside provider, if they are not already in the room.

Third, and this is the one people get wrong, your insurer, before you engage anybody. Cyber policies commonly require early notification and commonly require you to use responders from their approved list. Hiring your own forensics firm first can reduce or void the cover you have been paying for all year. Keep the policy number and the notification line somewhere you can reach without the network.

Then legal, because privilege and notification duties both begin early. Then the specialist responders. Customers, staff and regulators come once you know something real, though somebody should start drafting straight away. Drafting is slow and the clocks are not.

Do not rebuild the machine. This is the most common and most expensive mistake in the whole sequence, and it is always made with good intentions by somebody trying to get a colleague working again. A reimaged laptop cannot tell you what was taken, how they got in, or whether the same access is still live elsewhere in the business.

Do not delete the mail forwarding rule you just found. Screenshot it, export it, note when it was created and which session created it. Then remove it.

Do not change passwords one at a time over several days. An attacker with a foothold watches that happen and moves ahead of you. Plan the reset, then run it in one push across the affected accounts, revoking sessions at the same moment. A password change without a session revoke leaves them signed in and comfortable.

Do not confront the employee whose account was used. Do not pay anything. Do not give customers a number before you have one. Do not switch off logging in a panic, and do not let a helpful colleague clear disk space on the affected server.

Removing a piece of malware is not the same as removing the attacker. By the time most intrusions get noticed they are running on valid credentials, and valid credentials survive an antivirus cleanup without any difficulty.

Work through the whole list. Passwords and sessions for the affected accounts. Application passwords and any legacy protocol still accepting a password on its own. Multi factor methods added recently. Third party applications granted access to a mailbox or a drive. API keys and personal access tokens. Remote access accounts. Any account or group membership created since the earliest suspicious activity.

Pay particular attention to anything that grants access without a password. An application consent on a mailbox survives every password change you make. So does an inbox rule quietly copying mail somewhere else. Those are the mechanisms that let an intrusion come back a month later looking like a fresh one.

If a privileged account was involved, treat the credential store itself as in question and plan a wider reset with your responders. It is slow and unpleasant. Doing half of it means doing all of it again in a few weeks.

The question everybody asks first is what was taken. You answer it from logs, and those logs have a retention window that is quietly running down while you decide what to do.

Preserve first and analyse second. Export the sign in logs, the mailbox audit logs, file access records, firewall and proxy data, the endpoint agent timeline and any relevant snapshots. Copy them somewhere outside the affected environment. Do this in the first hour even though nobody will read them until tomorrow.

Then build a timeline backwards from the thing you noticed. First successful sign in from somewhere unusual. First privilege change. First bulk download. The earliest confirmed event sets the window that everything else gets measured against, including which backup you can safely restore from.

Be honest about the gaps. Where logging was never switched on, write that down plainly rather than letting silence imply nothing happened there. Absence of evidence gets written up as absence of impact far more often than it should be, and it tends to be the thing that unravels later.

Several deadlines begin at the moment you become aware, and awareness usually arrives earlier in the story than anyone would like.

In India, the national computer emergency response team requires certain categories of incident to be reported, and the window it gives you is short. Sector regulators add their own duties on top. If you hold data about people in other countries, those rules travel with the data. Somebody in your business should have found out which of these apply long before today.

Contracts carry obligations of their own. Plenty of customer agreements include a notification clause with a stated period, and those periods are often tighter than anything the law asks for. Your insurance policy has one too, and it is frequently the shortest of the lot.

None of this means announcing before you know anything. It means the person handling communication starts drafting while the technical work runs, so the message can go out when the facts arrive rather than a day after them.

Rebuild once you understand the way in, not before. A clean rebuild that restores the same unpatched appliance, the same exposed remote access or the same credential the attacker still holds puts you exactly where you started. The second time round is worse, because by then you have used up both your goodwill and your evidence.

The order that works is understand the entry point, close it, verify it is closed, then rebuild from known good sources rather than from the running system. Restore data from a point before the earliest confirmed activity wherever you can, and check that point carefully rather than trusting the date on it.

Watch the environment more closely than usual for a while afterwards, and watch specifically for the same access pattern returning. Crews come back, and they come back to the door they already know.

Then write it up while the detail is still fresh, and put one item at the very top of the actions list: the control that would have caught this earlier. Fund that one before the longer list of smaller improvements underneath it.