The Attack Did Not Wait for the Meeting to Finish

The previous article, “When Stopping The Attack Means Disrupting Your Own Organisation”, examined how your teams can sustain essential work while a protective restriction remains in place.

In this article, we look at what happens when an attack moves beyond the scope of a proposed intervention before your team can apply it. While your teams discuss restricting one session or isolating one server, the attacker can open another session or reach another system. Your decision record needs to show what you observed when you proposed the action, what has changed since then and what the action still covers when you apply it.

The next article, “When Reality Overtakes Preparation”, takes that question from a single intervention to the incident plan as a whole. It examines how your teams can revise decisions when several assumptions about systems, dependencies and recovery no longer hold.

Consider an incident call. Security wants to end a remote support session that has begun issuing unusual commands. Operations asks for five minutes to check which work will be interrupted. Finance needs to understand the cost of a stoppage. Legal asks the incident lead to record what is known before the action is agreed.

Those are reasonable requests. While the discussion continues, a responder sees a second session on a different server using the same account. The new session needs investigation. If it belongs to the same attacker, ending the first session will leave another route available.

The decision that opened the meeting is still on the screen. It names one session. Your teams can still end it, but the incident lead now has to determine whether that action covers the access under investigation.

The initial proposal in this scenario is precise. It would end one session on one server. That precision is useful because the service owner can identify what work depends on the session and the responder can check whether it closed.

A second session raises a different question about scope. If the two sessions are linked, the incident lead may need to restrict both or look at the account itself. The service consequences change with the target. Suspending the account, for example, could also interrupt jobs that never used the original session.

Keep the two decisions distinct in the incident record. Ending the first session may remain justified on the information already available. Whether to restrict the second session or the account depends on the newer findings and the consequences of that wider action. The update belongs alongside the pending decision so the person applying it can see which action is current.

During the call, the responder closest to the systems should be able to say what changed since the action was proposed. Keep the timestamp, target and intended effect together. A report that the same account is now active elsewhere matters more to the pending restriction than another general update on incident severity.

The incident lead can then confirm the limited action, extend the scope where justified or replace the original proposal. If a newer instruction supersedes it, mark the earlier one as withdrawn so an operator working from a message or ticket does not apply it later.

Someone still has to accept the service consequences of the action that will actually be taken. The person doing so deserves a current description of the target and the likely interruption. A short decision record gives them a way to see what has changed while the discussion is still in progress.

Suppose the responder ends the first session. Verify that it closed and check whether the second remains active. If your teams later suspend the account, confirm what happened to both sessions and to any jobs that depend on it. A successful first action answers a specific question about one target. The remaining access belongs in the next decision.

Those observations also give your incident team a clearer handover. A colleague joining the call can see which intervention was proposed, which one was applied and what activity remains under investigation.

When the incident call reaches a decision, read back the target as it exists now. If the original session is already closed, the next action may concern another connection. Give the responder one current instruction and record which access remains under investigation.

Without automated containment, an incident alert brings your responders onto a call. While they assess the activity and decide whether to close the remote support session, the attacker is already looking for the next server.

Our Server Intrusion Protection exposes and traps intruders attempting to gain remote access to protected servers, including those using compromised administrator credentials. It detects that reconnaissance and automatically blocks unauthorised access and interrupts malicious server activity, stopping the attacker from using that route to move deeper into your environment.

That changes the decision on the incident call. Our platform has already stopped the attacker on that route. Your responders can now focus on how the attacker got in. Stopping the attack before it reaches more systems reduces the work of investigating the compromise and restoring affected services. That saves your organisation time and money.

“When Reality Overtakes Preparation” examines the wider planning problem. The British Library’s own account shows how its plans enabled escalation during a ransomware attack, while legacy systems and service dependencies shaped a recovery programme the original plan could not fully anticipate.