Same incident, two teams: What Hacker Halted revealed about incident readiness

At EC-Council's Global CISO Forum this week, two groups of security leaders faced the same problem: an $847,000 commission payment had gone to the wrong bank account.

The missing money was only the first clue.

A threat actor had compromised a Microsoft 365 account through credential stuffing and MFA fatigue. The actor registered a rogue device, created a hidden forwarding rule, monitored financial email, accessed cloud services, staged commission records, and sent encrypted archives to external infrastructure. A fraudulent PDF then redirected the payment.

Both teams had 24 minutes of observed exercise time. Both found the compromise. They still took markedly different paths.

That contrast became the subject of Ron Dilley's presentation, "Two Different Responses: A Tale of Two Teams," at the Global CISO Forum during Hacker Halted 2026. Ron compared the teams' decisions, technical actions, communications, and misses using the record captured during each simulation.

A fitting case for Hacker Halted

Hacker Halted 2026 brought practitioners and senior security leaders to The Westin Peachtree Plaza in Atlanta on October 8 and 9. The theme, "Cyber Carnival: Where Illusion Meets Intrusion," focused on deception, manipulation, AI, and the judgment defenders need when the facts are incomplete.

The Sweetgum Health Plan scenario fits that theme. The visible problem was a fraudulent wire. The deeper incident involved identity compromise, persistence, mailbox surveillance, data exfiltration, legal exposure, regulatory pressure, and an angry business partner.

No participant had the whole picture at the start. The teams had to build it while the clock ran.

Team 1 found the attack, then missed the business clock

Team 1 reconstructed the attack chain quickly. By minute five, participants had identified credential stuffing, MFA fatigue, the unauthorized device, persistent tokens, the fraudulent email path, the forwarding rule, and the impersonation domain.

Their containment work was broad:

• Minute 11: lock the account, reset credentials, and terminate active sessions and persistent tokens.

• Minute 16: block all three known malicious IP addresses and preserve relevant logs.

• Minute 18: remove the hidden forwarding rule.

• Minute 19: isolate associated devices for forensic review.

The team also brought in Legal and Communications, shared confirmed facts, contacted the FBI, and kept external messaging constrained.

The largest gaps sat outside the console. No one called the originating bank during the exercise. FINRA sent an inquiry at minute five, but the team did not send an acknowledgment before a second notice arrived at minute twenty-three. The exercise also ended without a complete account of the exposed data, the affected population, or the legal significance of the attacker's encryption.

Team 1 showed strong technical instincts. Its process did not convert those facts into timely financial and regulatory action.

Team 2 called the bank, then hesitated on command

Team 2 treated the money as an immediate business problem. At minute six, it initiated cancellation, reversal, and recall requests through the originating bank and clearinghouse.

The team also scoped the technical incident well. It established that the event centered on a cloud identity rather than an infected workstation. It found the rogue device, mailbox rule, OneDrive staging directory, exfiltrated financial records, and three malicious IP addresses.

By minute seventeen, responders had disabled the account, revoked active sessions and persistent tokens, and reset the password. By minute twenty-three, all known attacker infrastructure had been blocked.

Yet the team was still debating whether it had a confirmed incident after account compromise and data exfiltration were established. It also encrypted the cloud staging directory before showing a forensic copy, integrity hashes, metadata capture, or chain-of-custody record. The action restricted access, but it modified the source evidence.

Team 2 moved quickly on financial recovery. It was less disciplined about incident declaration, evidence handling, and completion of every eradication step.

The common failure was coordination

Both teams had capable people. Both struggled to turn individual work into a shared operating picture.

Roles took time to settle. Investigators sometimes completed good work without reporting the result. Leaders discussed tasks without always assigning one owner. Some mitigation steps occurred sequentially even after several access paths were known.

The participation data made the split visible. In Team 2, two participants performed fourteen of the sixteen console activities and had no measured bridge talk. The two incident commanders accounted for about 28 percent of the discussion and performed no console actions.

That division can work. Incident commanders should avoid becoming keyboard operators. It fails when the people working do not report completion and the people leading do not translate decisions into named actions with verification.

The practical bridge update is short:

1. What changed?

2. What completed?

3. What remains open?

4. Who owns the next action?

Why simulation found more than a tabletop

A traditional tabletop usually asks participants what they would do. That format is useful for policy review and executive discussion. It can also make intended action look like completed action.

The Hacker Halted exercises required participants to work. They queried a bounded investigation console, routed mitigation requests, sent messages, assigned tasks, and responded to agents representing counsel, regulators, law enforcement, business partners, executives, and the adversary.

Those agents adapted to participant behavior. The scenario changed according to what each team said, typed, completed, or ignored. One team received a second FINRA notice because it failed to respond. Another exposed an evidence-handling gap because a participant changed the source before preserving it.

The platform also recorded the exercise at a level a human scribe cannot match: failed commands, execution results, bridge participation, communication timing, open tasks, and the sequence between discovery and containment.

This is where crisis simulation can be far more effective than a conventional tabletop. It exposes the gap between knowing the answer and producing the outcome.

Measure how the team works

Ron also introduced a behavioral model called VECTOR: Velocity, Evidence, Command, Teaming, Optionality, and Resilience.

The model looks beyond response time. It asks whether people act too quickly or too slowly, preserve and use evidence, establish command, work as a team, consider competing hypotheses, and remain effective under pressure.

That evidence can improve team design and training. It can also support hiring. During the Q&A, one attendee asked how to assess incident-response candidates. Ron described a customer that planned to put candidates through a 20-minute simulation. The point was simple: claimed experience is hard to verify in an interview, but behavior under pressure is observable.

Other attendees asked whether the method applies outside cyber incidents and how teams should balance checklists with judgment. The answer was practical. The same model can support business continuity, disaster recovery, and privacy exercises. Teams still need a short set of non-negotiable actions, such as establishing command, preserving evidence, keeping notes, and engaging counsel. The technical response must leave room for investigation and adaptation.

The questions continued until the moderator called time. That was a good sign: the audience had moved from listening to considering how to use the method.

Practice the work

The two teams did not produce a winner and a loser. They produced different evidence.

Team 1 showed how strong investigation and containment can coexist with missed financial and regulatory deadlines. Team 2 showed how fast business action can coexist with weak declaration and evidence discipline. Both showed why roles, ownership, and completion signals must be practiced before an incident.

We published the full comparison, including the scenario, team timelines, findings, and recommendations, in the paper Same incident, different outcomes: What two crisis simulations revealed about incident readiness.

Policies describe the intended response. Simulation reveals the response a team can deliver.