What Actually Happens in the First Hour of a Breach

TLDR: By the time most organizations know they have a problem, the attacker has already been inside for days. The first hour of a real incident looks nothing like the IR plan: detection is late, scope is unknown, decisions get made without good information, and evidence disappears while people are still figuring out who to call. What separates organizations that contain incidents from those that don’t usually comes down to what happens in that first window, and most organizations have never honestly practiced it.

The IR Plan and the Room Are Different Places

Every organization with a security program has an incident response plan. It describes a process: detect the threat, contain it, eradicate it, recover from it. The steps are logical. The roles are assigned. The document exists.

What the plan doesn’t describe is the actual room.

The actual room is a conference call where three people are talking over each other, someone’s laptop won’t connect, and the most important decision-maker hasn’t been reached yet. It’s a senior IT manager staring at an alert they’ve seen a hundred times before, trying to decide if this one is different. It’s a security lead calling legal while simultaneously texting the CEO while simultaneously trying to figure out whether to pull systems offline and potentially destroy the forensic evidence they need.

The plan assumes clarity. The room is full of noise.

This post is about the gap between those two things, and what organizations consistently get wrong in the time that matters most.

The First Hour Is Almost Never the First Hour

The most important thing to understand about the first hour of breach response is that it is rarely the first hour of the breach.

By the time an alert fires or an anomaly gets flagged, the attacker has usually been present for hours, days, or weeks. The “first hour” is the first hour of knowing, not the first hour of compromise. That distinction matters enormously, because it changes what you’re actually dealing with when response begins.

Change Healthcare is the clearest recent example. Attackers affiliated with the ALPHV/BlackCat ransomware group accessed the company’s network on February 12, 2024, through a Citrix remote access portal that had no multi-factor authentication enabled. For nine days they moved laterally through the environment, mapping systems and exfiltrating data. Change Healthcare’s team didn’t know until the morning of February 21, when encryption began and systems started going dark.

Their “first hour” of response was actually hour 216 of the breach.

The scope of what had already happened, 6 terabytes of data exfiltrated and ultimately 190 million patient records affected, was entirely unknown to them when they began making containment decisions. This was confirmed in congressional testimony by UnitedHealth Group’s CEO.

This is not an outlier. It is the pattern. Dwell time before detection is measured in days and weeks in most significant incidents. Organizations respond to the moment they discover the breach, not to the moment the breach began, and those are almost always very different moments.

Five Things That Actually Happen When the Alert Fires

The real signal arrives looking like every false one. By the time a significant incident surfaces, the analyst who first encounters the relevant alert has usually made the right call dozens of times before by dismissing it. The institutional conditioning to treat alerts as noise is built from accurate experience with actual noise. That’s what makes it dangerous. The indicator that eventually triggers a confirmed incident frequently sat in the same queue as alerts that were, in fact, nothing. Whether it gets escalated or dismissed in that first moment often comes down to factors that have nothing to do with the indicator itself: who’s on shift, how the day has gone, what else is open on the screen. The difference between the real one and all the false ones is only obvious in retrospect.

The scope is completely unknown, and the first decisions are irreversible. The instinct when an incident is confirmed is to act: pull systems, change credentials, block traffic. Containment and preservation pull in opposite directions in those first minutes, and the cost of choosing wrong is asymmetric. A decision made in the first thirty seconds of containment can destroy thirty days of forensic reconstruction. Pulling a compromised endpoint offline stops lateral spread but may erase the memory artifacts that would have shown exactly how the attacker moved through the environment. Revoking credentials before capturing authentication logs can leave the scope of access permanently unclear. The teams that handle this well have thought through the tradeoff before the incident, so it doesn’t have to be resolved under pressure for the first time. Most haven’t. Decisions get made anyway, because inaction also has a cost.

Communication breaks down immediately. Most IR plans have a notification sequence on paper. In practice, that sequence collapses under the pressure of the moment. The questions that need answers are not technical: Who has authority to approve a system shutdown without assembling a committee? Does legal get called before or after the insurer? What can be said to the CEO who is now calling every five minutes? Who is the single spokesperson if this becomes public? These questions require pre-established answers with pre-designated people, and they require that those people have been through the scenario before, even artificially.

MGM Resorts illustrates this failure clearly. In September 2023, initial access came from a ten-minute vishing call to the IT help desk. The first indication something was wrong wasn’t a security alert. It was operational systems going offline. By the time the security team understood what was happening, guest-facing systems were already down and the scope of the attacker’s access was unclear. The communication and decision-making challenge that followed was severe, in part because the chain of who needed to know what, and when, had not been genuinely stress-tested before the incident.

The “is this real?” phase burns time that doesn’t come back. There is almost always a period in every confirmed incident where significant organizational energy goes toward confirming what is already obvious in hindsight. This is partly rational, because acting on a false positive has real costs. But in practice, the confirmation process delays decisions by thirty minutes, an hour, sometimes longer. In retrospect, after the full scope becomes clear, that lost time looks very different than it did in the moment.

Evidence disappears during response. Logs get overwritten. Systems get rebooted. Network connections get severed before traffic is captured. Some of this happens because of containment actions taken in good faith. Some happens because normal system operations continue during the early confusion. By the time a forensic investigator arrives, the first hours of the attacker’s activity are often the hardest to reconstruct, precisely because they overlap with the earliest and most chaotic period of response.

What We Saw

We responded to a hospital incident earlier this year. When we arrived, the organization had already made several decisions: systems had been pulled, accounts had been reset, and the IT team member coordinating with us had been in the role for less than a year.

That last detail matters more than it might appear. He knew his environment well enough to keep it running; that’s what the role had asked of him. But the organization’s institutional knowledge about its own environment, what was normal traffic, what wasn’t, where the critical systems actually lived and how they connected, had left with people who were no longer there. The documentation that should have carried that knowledge forward hadn’t been written.

The IT function had been focused on what IT functions at most organizations of that size focus on: keeping operations running day to day, responding to tickets, keeping people from getting locked out of accounts. That work is legitimate and necessary. Building and maintaining incident response processes is a different discipline, and under the resource constraints of a mid-market organization, it tends not to get prioritized until something happens.

What that meant in practice was that decisions about what to contain and in what order had to be made in real time with incomplete information, by someone who didn’t yet have full command of the environment. That’s a hard position to be in. It’s also a common one. And it’s avoidable with the right preparation before a crisis starts.

What Good Actually Looks Like

Organizations that handle the first hour well share some characteristics, and none of them are primarily about tools.

They have pre-designated decision authority. Someone has the explicit, documented, understood ability to authorize containment actions without convening a committee. That person knows they have it. The rest of the organization knows who it is.

They have a practiced communication sequence. Not a documented one. A practiced one. Legal, insurer, executive leadership, board if necessary: the order is known, the contact information is current, and the relevant people have run through it in a scenario that didn’t follow a clean script.

They treat evidence preservation as a first-class concern from the start, not an afterthought. The tension between containment and preservation is acknowledged before an incident occurs, so it doesn’t have to be resolved for the first time under pressure.

They have documented their own environment well enough that a competent person who is new to the role can still orient themselves quickly when things go wrong. That documentation doesn’t have to be elaborate. It has to exist and it has to be accurate.

Most importantly, they have practiced being uncomfortable. A tabletop exercise that hands participants a clean incident description on slide two is not useful preparation for the actual room. The ambiguity and noise of the first hour has to be simulated deliberately, not smoothed over in the interest of a productive training session.

Most organizations will not know how they perform in the first hour until they are in it. The plan will not tell them. The tools will not tell them. Only having been through it, even artificially and imperfectly, gives a team the muscle memory to function when the noise is loudest and the stakes are real.

That’s what preparation actually means.

One Thing a Security Leader Can Do Today

Your IR plan probably covers most of this on paper. The question worth asking is whether your team has actually internalized it. Four things worth confirming before the next incident:

  1. Does the person designated to authorize containment decisions know they have that authority, and have they exercised it under any kind of pressure, even simulated?
  2. When your notification sequence was last practiced, did it follow a realistic scenario or a comfortable one?
  3. If your most experienced team member was unavailable at the moment of detection, does your environment documentation give their replacement enough to orient themselves?
  4. Has your legal and insurance contact sequence been stress-tested, or does it only exist as a list of phone numbers in a document nobody has opened in eighteen months?

These are not questions for a consultant. They’re questions for your next team conversation. A two-hour tabletop that doesn’t hand participants the incident type on slide one will answer all four more honestly than any documentation review.

Start there.

References

Change Healthcare / UnitedHealth Group (2024) UnitedHealth Group CEO Andrew Witty confirmed the details of the Change Healthcare breach in written testimony submitted to the Senate Finance Committee and the House Energy and Commerce Subcommittee on Oversight and Investigations on May 1, 2024. Witty confirmed that attackers used stolen credentials to access a Citrix remote access portal with no MFA enabled on February 12, 2024, spent nine days moving laterally before deploying ransomware on February 21, and that approximately 6 terabytes of data were exfiltrated.

MGM Resorts International (2023) The September 2023 MGM incident was attributed to the Scattered Spider threat group, confirmed through reporting by Reuters, The Wall Street Journal (which reported on the help desk social engineering in detail), and TechCrunch. The Wall Street Journal and Bloomberg reported that the attacker posed as an employee on a call to the IT help desk and reset credentials without additional verification. Note that WSJ and Bloomberg articles may be behind a paywall.

Final CTA Section
GET STARTED

Ready to Strengthen Your Defenses?

Whether you need to test your security posture, respond to an active incident, or prepare your team for the worst: we’re ready to help.

Schedule Consultation
📧 [email protected]
📍 Based in Atlanta | Serving Nationwide

Discover more from Satine Technologies

Subscribe now to keep reading and get access to the full archive.

Continue reading