You Were Already Breached. A Red Team's View of How It Happens — and Why You Can't Recover

Introduction: The Engagement Nobody Wants to Read About

Every red team engagement tells a story. It is rarely the story the client expects. They expect to hear about a firewall misconfiguration or a missing patch. What they actually hear, when a real red team does real work, is that the company was already breached in every meaningful sense. The controls were wrong, the trust model was wrong, and the assumption that someone would notice was catastrophically wrong.

This article walks through a representative red team engagement from initial reconnaissance through ransomware detonation and post-incident insurance denial. It is written not as a technical manual but as a business consequence document, because the executives who need to understand it are not reading CVE advisories. They are reading profit-and-loss statements, and those are about to look very different.

The red team did not hack your company. They revealed that your company was never secure to begin with

The engagement described here reflects patterns drawn from real-world assessments I have completed. If any section makes you uncomfortable, that discomfort is your risk register speaking.

Phase 1: Reconnaissance — You Are Already Visible

The engagement begins before a single packet is sent. The red team opens a browser. That is frequently enough. Open-source intelligence, OSINT, has become devastatingly effective against mid-market companies that believe obscurity is a defense strategy. LinkedIn alone surrenders an organizational chart, technology stack, key vendor relationships, and the names of employees likely to have privileged access. Job postings reveal the EDR platform, the ticketing system, and whether the company runs a hybrid Azure environment. A single poorly configured DNS record can expose the managed service provider handling infrastructure. The attack surface is published voluntarily, updated continuously, and indexed by search engines.

In a typical engagement, within 48 hours of starting passive recon, the team has identified the following without touching a single client system:

•       The full name and direct email format of the COO, CFO, and IT Manager

•       The MSP handling endpoint management, backup, and firewall support, including the MSP's own LinkedIn presence, their technician roster, and the RMM platform they advertise in their job postings

•       At least two former employees whose credentials may still exist in integrated SaaS systems

•       The company's cyber insurance carrier, disclosed in a public filing or insurance industry database

•       Technology identifiers embedded in the company's public-facing web presence

None of this required a court order. None of it required technical sophistication. It required patience and a few open tabs. The question is never whether this information is available. It is whether you have taken any steps to control it.

The MSP identification is not incidental. It is strategic. Your MSP is your recovery plan. The red team noted their name on day one.

Phase 2: Initial Access — The Phish You Will Never Remember Clicking

Social engineering in 2026 is not what it looked like in 2014. The spray-and-pray phishing email with a Nigerian prince subject line is a relic (although it was surprisingly effective for a long time). Modern phishing campaigns are surgical, personalized, and informed by weeks of reconnaissance.

The red team constructs a pretext built around something real. Regulatory notice. A wire confirmation. A benefits enrollment reminder timed to open enrollment season. The target's name is correct. Their title is correct. The sender domain is a convincing lookalike registered six days ago. The email passes SPF and DKIM because the attacker controls the sending infrastructure. It lands in the inbox.

The link does not immediately execute anything. It takes the user to a credential-harvesting page that mirrors the company's SSO portal with precision. The user authenticates. The session token is captured. The red team now has valid credentials to the environment without ever having deployed a payload.

In environments without phishing-resistant MFA, which, in the mid-market, is the majority of environments, this access is immediate and clean. In environments with SMS-based MFA, a real-time adversary-in-the-middle proxy handles the token intercept transparently. The user experiences slightly slow login and moves on. The red team moves in.

The initial access phase in this engagement took eleven minutes from send to valid session. The target never knew they had clicked anything suspicious.

Once inside, a lightweight implant is established for persistence. Keylogging begins quietly. The team observes. They do not act. This is where patience becomes the attacker's most dangerous weapon.

Phase 3: Dwell Time — Ninety-One Days of Silence

The single most important number in modern ransomware economics is not the ransom demand. It is the dwell time,  the number of days between initial compromise and detonation. For sophisticated threat actors, that number is engineered, not accidental.

Most companies operating in the $50M to $250M revenue range maintain backup retention of 30 to 90 days. Some stretch to 180 days on paper, but the practical reality is that immutable, verified, offsite backups are frequently absent, untested, or quietly misconfigured. The red team's pre-engagement survey of the client's environment confirmed a 60-day rolling backup window with a 30-day local snapshot tier.

The threat actor does not detonate on day one. They observe. They map. They identify backup infrastructure, domain controllers, the MSP's remote management agent, and every system that would be essential to recovery. They escalate privileges methodically. They establish multiple persistence mechanisms in case one is discovered. And they wait.

Ninety-one days after initial compromise, every backup in the retention window is either within the period of infection, meaning it will restore an already-compromised environment, or has been quietly corrupted. The company does not have a valid restore point. They do not know this yet.

During this dwell period, the keylogger has captured:

•       Domain administrator credentials

•       Backup console credentials and the associated encryption keys

•       MSP RMM portal credentials, enabling the attacker to pivot to other clients in the MSP's portfolio

•       File server path structures, database connection strings, and the location of the most sensitive documents on the network

Ninety-one days of silence is not patience. It is forensic clock management. When detonation occurs, every backup the company thought it had is inside the infection window.

Phase 4: Exfiltration Without a Trace

Before the ransomware detonates, the data leaves. This is not incidental, it is the basis of the double extortion model that has become standard among sophisticated threat actors. The encryption is the operational disruption. The exfiltration is the leverage.

Here is where conventional DLP controls fail in a predictable and specific way. Traditional data loss prevention tools are built to detect and block unusual outbound file transfers, large ZIP archives, bulk uploads to unknown cloud destinations, anomalous data volumes moving to external IPs. They do well at the pattern they were designed to catch.

They were not designed to catch a threat actor using a sanctioned collaboration platform as an exfiltration channel. In several documented real-world cases and red team scenarios, attackers have abused the draft-saving functionality in webmail platforms to stage and exfiltrate documents. Sensitive files are opened, their contents are copied into a draft that is never sent, and the draft is accessed later from an external session. No outbound transfer. No attachment. No email in the sent folder. The DLP engine sees normal user activity in an approved application.

The red team confirmed in this engagement that the client's DLP policy had no coverage for draft-based staging in the webmail environment. Approximately 400 sensitive documents, board materials, client financial statements, regulatory correspondence, were staged over a two-week period with zero alerts generated.

The lesson is not about any specific application or technique. It is about the gap between where DLP coverage is assumed to exist and where it actually exists. That gap is measured in gigabytes.

Phase 5: Taking Out Your Lifeline — The MSP Strike

One of the most consequential findings in a red team engagement is consistently underestimated by clients: the managed service provider is not a firewall. It is an attack surface.

The MSP identified during Phase 1 became a parallel target, I have found it useful to make them inert right off the bat so they cannot act as a foil or assistance to the target. The same social engineering techniques used against the primary target were applied to the MSP's helpdesk, a smaller team, operating under higher volume and time pressure, less likely to have rigorous identity verification procedures before providing access. The MSP's RMM credentials were accessible through the keylogger data captured on the primary target's machines. The MSP's own portal had MFA configured as optional for senior technicians.

The strategic objective of compromising the MSP is straightforward: eliminate the fastest path to recovery. When the ransomware detonates and the client's first call goes to the MSP, the red team wants that call to go to an organization that is also down, also scrambling, and also unable to provide the remote recovery support the client depends on. In real-world incidents, MSP compromise has been used to simultaneously detonate ransomware across dozens of the MSP's clients from a single command-and-control instance.

Your MSP is not just your support vendor. They hold the keys to your environment. If an attacker gets into the MSP first, they do not need to get into you. You are already open.

The client had no visibility into the MSP's own security posture. There was no contractual requirement for the MSP to carry a SOC 2 Type II certification. There was no annual review of the MSP's security controls. The SLA covered uptime and response times. It said nothing about the MSP's own breach notification obligations or their incident response capabilities. The relationship was built entirely on trust. Trust is not a control.

Phase 6: Detonation — Day One

When the ransomware executes, it does not announce itself. The first indication is a help desk ticket from an employee who cannot open a file. By the time IT escalates, the encryption has propagated across file servers, shared drives, and backup volumes. The domain controllers have been targeted for maximum operational disruption. Shadow copies have been deleted. The backup console is inaccessible. The MSP's remote management agent is unresponsive.

The company's incident response plan, if one exists, calls for isolating affected systems and contacting the MSP. The MSP is unreachable, I made sure of that. The IR plan does not have a secondary escalation path. The legal team is not on the contact list. The cyber insurer's breach hotline number is in a file on a server that is now encrypted and your IT team is busy trying to restore from backups I have encrypted.

Within four hours, the organization is functionally offline. Within 24 hours, the double extortion notice arrives, confirming that data has already been exfiltrated and will be published or sold unless a ransom is paid. The company now faces two simultaneous crises: operational paralysis and a data breach notification obligation under multiple state privacy laws.

The red team debrief will note that detonation took less than 40 minutes to reach full environmental impact. It will note that there was no valid backup. It will note that the MSP was simultaneously compromised. And it will note that none of this required zero-day exploits or nation-state resources. It required patience, reconnaissance, and the exploitation of trust assumptions that the company had never audited.

Phase 7: The Insurance Gauntlet — You're Screwed Twice

The ransom demand is not the end of the financial exposure. In many cases it is not even the largest component. The cyber insurance claim process, if the company has coverage at all, has become a sophisticated adversarial proceeding in its own right.

What Your Insurer Is Actually Asking

When the claim is filed, the carrier's forensic team begins an investigation that will determine not just how the breach occurred, but whether the company was in compliance with the security representations made on the policy application, unfortunately this is all going on while the company is down. That application, signed 11 months ago, asked about MFA deployment, backup procedures, endpoint detection, employee security awareness training, and third-party vendor risk management. The answers the company provided at application time will now be audited against the actual state of the environment at the time of the breach. All the answers given which were Blue Sky (the most hopeful of thoughts) never got implemented.

The carrier will ask specifically:

•       When was your last penetration test, and by whom? Provide the report.

•       What is your MFA deployment rate across privileged and remote access accounts?

•       Provide your MSP's most recent SOC 2 Type II report and your annual review of that report.

•       Provide the SLA with your MSP including their security obligations and breach notification requirements.

•       Provide your documented DR and BCP plan, the date of your last tabletop exercise, and the results.

•       What is your backup architecture, retention policy, and when was your last verified restore test?

•       What DLP controls were in place, and what was their coverage scope?

If the honest answers to those questions differ from the answers on the application, the carrier has a coverage defense. In the insurance industry, this is called a material misrepresentation. In plain language, it means they do not have to pay.

Denial Statistics and the Coverage Gap Reality

The cyber insurance market has hardened significantly. Carriers that were writing broad policies with minimal underwriting scrutiny in 2019 and 2020 have retrenched. Denial rates for ransomware claims have increased substantially as carriers apply post-breach forensics to application representations. Industry data suggests that a material percentage of small to mid-market ransomware claims face either partial denial, coverage dispute, or significant payment reduction based on non-compliance findings discovered during the claims investigation.

The most common grounds for denial or reduction include: absence of MFA on remote access and privileged accounts; failure to maintain tested, immutable backups; no documented IR plan or evidence of tabletop exercises; absence of a vendor risk management program covering the MSP; and representations about endpoint security that did not match deployed configurations.

The insurance policy you purchased assumed a security posture you may not have maintained. The gap between the application and reality is where claims go to die.

State Privacy Law: The Second Bill

Independent of the insurance outcome, the data breach has triggered notification obligations. Depending on the states in which affected individuals reside, the company may face notification requirements under California's CPRA, New York's SHIELD Act, Massachusetts Chapter 93H, and a growing roster of state privacy statutes. Each has different timelines, different content requirements, and different enforcement mechanisms.

The exfiltrated data, 400 documents including client financial statements and regulatory correspondence. almost certainly contains information triggering these obligations. Attorney General enforcement actions, class action litigation, and regulatory examinations from FINRA or the SEC compound the exposure. The ransom payment, if made, does not extinguish these obligations. The breach occurred. The notification clock is running.

Conclusion: What the Red Team Actually Delivered

A red team engagement is not a hacking exercise. It is a business risk quantification exercise that happens to involve hacking. The deliverable is not a list of open ports. It is a documented, evidence-based demonstration of what an actual adversary would do, how far they would get, and what the business consequences would be.

In this engagement, the red team demonstrated: full environmental compromise from a single phishing email; 91 days of undetected dwell time enabling backup destruction; exfiltration of sensitive data through coverage gaps in the DLP architecture; simultaneous compromise of the MSP; and detonation resulting in no valid recovery path. Every finding has a corresponding control deficiency. Every control deficiency has a corresponding business consequence. Every business consequence has a dollar value that dwarfs the cost of the assessment.

The companies that read this article and recognize themselves are the ones who still have time to act. The companies that dismiss it as hypothetical are the ones who will be on the phone with a ransomware negotiator in 18 months trying to remember where they printed the cyber insurer's breach hotline number.

The red team does not create your risk. It finds the risk you already have. The only question is whether you find it first.

Timcke Risk Management LLC provides IT risk assessments, red team readiness reviews, DR/BCP program development, and vCISO services for organizations in the $1M–$250M revenue range.