Five Telemetry Failures That Real Breaches Exploited

Every major breach has a moment that doesn’t make it into the headlines. It’s not the initial exploit. It’s not the data exfiltration. It’s the quiet realization, weeks or months later, that the defenders could have caught it if only they’d known their telemetry was broken.

We analyzed five of the most consequential breaches of the last decade. In every single case, the attack succeeded not because the security tools failed to detect the threat, but because the telemetry those tools depended on had silently degraded or disappeared, and nobody noticed.

These aren’t theoretical scenarios. These are documented facts from government investigations, congressional testimony, and forensic reports. Every one of them illustrates the same fundamental problem: organizations don’t monitor whether their security monitoring is working.

1. Equifax (2017) - The expired certificate that hid 76 days of exfiltration

What happened: Attackers exploited CVE-2017-5638, a critical Apache Struts vulnerability, to gain initial access to Equifax’s online dispute portal. Over the next 76 days, they moved laterally across 48 servers, accessed 51 databases, and exfiltrated the personal data of 147.9 million Americans, including names, Social Security numbers, birth dates, addresses, and driver’s license numbers.

The telemetry failure nobody talks about: Equifax had invested in a network traffic inspection system specifically designed to detect data exfiltration. The system worked by inspecting SSL/TLS traffic for suspicious patterns. There was just one problem: the SSL certificate required for inspection had expired 19 months earlier.

For nineteen months, the inspection device sat on the network, powered on, reporting healthy in infrastructure monitoring, consuming rack space and electricity, and inspecting nothing. Traffic flowed past it uninspected because without a valid certificate, it couldn’t perform the TLS interception it was designed for.

When Equifax finally renewed the certificate on July 29, 2017, the inspection system immediately detected the exfiltration because the attackers were still actively stealing data at that moment. The breach that had been running for 76 days was discovered within hours of the monitoring being restored.

The gap in numbers:

• 19 months of certificate expiration (expired January 2016, renewed July 2017)
• 76 days of active exfiltration (May 13 to July 29, 2017)
• 48 servers compromised during the blind period
• 147.9 million people affected
• $1.4 billion in total breach costs

What monitoring would have caught it: A system that tracked not just “is the inspection device online” but “is the inspection device actively inspecting traffic and producing results” would have flagged the expired certificate within hours. The telemetry source was present. The telemetry source was powered on. But the telemetry source was producing nothing, and nobody checked.

Source: GAO Report GAO-18-559, “Actions Taken by Equifax and Federal Agencies in Response to the 2017 Breach”

Equifax Timeline - 19 months blind, 76 days exploited

2. SolarWinds (2020) - When the monitoring tool becomes the attack vector

What happened: Russian intelligence operatives (APT29/Cozy Bear) compromised the SolarWinds Orion build environment and inserted a backdoor, SUNBURST, into software updates distributed to approximately 18,000 organizations. The attack gave them access to networks at multiple US government agencies, major technology companies, and critical infrastructure operators.

The telemetry failure nobody talks about: SolarWinds Orion is a monitoring tool. Its entire purpose is to provide visibility into IT infrastructure. The attackers didn’t just compromise a random application. They compromised the tool organizations relied on for telemetry and visibility.

The deeper telemetry failure was what SUNBURST did once deployed. The malware actively checked for and disabled security monitoring tools before executing its payload. Specifically, it:

• Enumerated running processes and cross-referenced them against a hardcoded blocklist of security and forensic tools
• Identified security software including endpoint detection, antivirus, and forensic analysis tools
• Disabled or avoided systems it identified, ensuring its C2 communications would not be inspected
• Lay dormant for up to two weeks after installation before activating, evading initial deployment monitoring windows

The attackers maintained access to the SolarWinds build environment for 14 months before the backdoor was discovered, not by SolarWinds, not by any of the 18,000 affected organizations, but by FireEye, who detected it only because the attackers made the mistake of using their access to steal FireEye’s own red team tools.

The gap in numbers:

• 14 months of attacker access to build environment before discovery
• 18,000 organizations received compromised updates
• ~100 organizations confirmed deeply compromised (including US Treasury, Commerce, Homeland Security)
• 0 detections from traditional monitoring; discovery was incidental

What monitoring would have caught it: A system that monitored whether security tools were actively producing telemetry, not just whether they were installed, would have detected the selective disabling of security monitoring. When SUNBURST killed a security process or blocked its network communication, the telemetry from that tool would have stopped. If anyone had been watching for that silence, the attack could have been detected in its earliest stages instead of running for over a year.

Source: Mandiant/FireEye SUNBURST Technical Analysis; CISA Emergency Directive 21-01

3. Target (2013) - $1.6 million in detection that nobody was watching

What happened: Attackers compromised Target’s network through an HVAC vendor (Fazio Mechanical) who had access to Target’s vendor management portal. They pivoted from the vendor network into the payment processing environment, deployed memory-scraping malware on point-of-sale terminals, and exfiltrated 40 million credit card numbers and personal data of 70 million customers.

The telemetry failure nobody talks about: Target had deployed FireEye, a leading threat detection platform, just months before the breach. The system cost approximately $1.6 million. It was installed. It was running. And it did exactly what it was supposed to do: it detected the malware.

On November 30, 2013, FireEye generated alerts flagging the malware as it was being deployed. The alerts were real. The detections were accurate. The telemetry was flowing.

But Target’s security team in Minneapolis had configured the system with auto-delete disabled for malware, a feature FireEye offered that could have automatically quarantined the threat. The alerts fired, were visible in the console, and were ignored. The team in Bangalore that first saw the alerts escalated them. Nothing happened.

This is a more subtle telemetry failure than a crashed agent or an expired certificate. The detection telemetry was produced and delivered. But the operational telemetry, “did a human acknowledge this alert? did the remediation workflow trigger? is the response pipeline working?”, didn’t exist. There was no monitoring of whether the monitoring was being acted upon.

Additionally, the US Secret Service later notified Target of the breach on December 12, meaning an external party detected the breach through their own monitoring of stolen card data being sold on criminal forums, twelve days after Target’s own tools had correctly identified the threat.

The gap in numbers:

• $1.6 million spent on the FireEye deployment that detected but didn’t prevent
• 12 days between first FireEye alert and external notification by Secret Service
• 17 days of total breach duration before containment
• 40 million credit cards stolen
• $292 million in total breach costs

What monitoring would have caught it: A system that tracked not just “are alerts being generated” but “are alerts being acknowledged, triaged, and resolved within defined SLAs” would have flagged the unactioned alerts within hours. The telemetry pipeline was working perfectly. The response pipeline was broken, and nobody was monitoring it.

Source: US Senate Committee on Commerce, Science, and Transportation, “A ‘Kill Chain’ Analysis of the 2013 Target Data Breach” (2014)

Breach Detection - Who Actually Found It?

4. Colonial Pipeline (2021) - Blind shutdown because nobody could see

What happened: On May 7, 2021, the DarkSide ransomware group encrypted systems at Colonial Pipeline, which operates the largest refined fuel pipeline in the United States, carrying 45% of the East Coast’s fuel supply. Colonial shut down all pipeline operations for six days, triggering fuel shortages, panic buying, and a national emergency declaration.

The telemetry failure nobody talks about: Colonial Pipeline’s most critical decision during the incident wasn’t whether to pay the ransom (they did, $4.4 million). It was their decision to shut down the pipeline entirely, and the reason reveals a devastating telemetry gap.

As CEO Joseph Blount testified before the US Senate: Colonial shut down operations because they could not determine whether the ransomware had spread from their IT network into their operational technology (OT) network that controlled the pipeline itself. They had no visibility into the OT environment. No monitoring. No telemetry. No way to answer the question: “Is the pipeline safe to operate?”

The initial access was through a legacy VPN account that wasn’t protected by multi-factor authentication and that the company didn’t even know was still active. An abandoned account, with no access monitoring, no usage telemetry, and no decommission record.

The total shutdown, six days of no fuel flowing through a pipeline serving 50 million Americans, wasn’t because the OT network was compromised. It was because they couldn’t tell whether it was. The absence of monitoring forced a worst-case assumption that paralyzed critical infrastructure.

The gap in numbers:

• 6 days of total pipeline shutdown
• 45% of East Coast fuel supply disrupted
• $4.4 million ransom paid (most later recovered by FBI)
• 1 legacy VPN account with no monitoring = initial access vector
• 0 telemetry sources in the OT environment

What monitoring would have changed the outcome: Two monitoring capabilities would have made a difference. First, monitoring the authentication telemetry would have flagged a dormant VPN account suddenly becoming active. Second, having any telemetry in the OT environment would have allowed Colonial to assess the blast radius without a full shutdown. They didn’t need to prevent the ransomware. They needed to see where it was.

Source: CEO Joseph Blount, testimony before US Senate Committee on Homeland Security and Governmental Affairs, June 8, 2021

5. MOVEit / Cl0p (2023) - Two years of reconnaissance that nobody saw

What happened: The Cl0p ransomware group exploited a zero-day SQL injection vulnerability (CVE-2023-34362) in Progress Software’s MOVEit Transfer, a managed file transfer (MFT) platform widely used for secure file exchange. The attack compromised over 2,700 organizations and exposed data of more than 93 million individuals worldwide, making it one of the largest mass-exploitation events in history.

The telemetry failure nobody talks about: This wasn’t a smash-and-grab. Forensic analysis by Kroll revealed that the Cl0p group had been testing vulnerabilities in MOVEit Transfer since at least July 2021, nearly two years before the mass exploitation in May 2023.

During those two years, Cl0p probed MOVEit instances, tested SQL injection techniques, and refined their exploitation methodology. They did this across internet-facing instances at organizations worldwide. None of those organizations detected the reconnaissance.

Why? Because MFT platforms are almost universally treated as infrastructure, not as security-relevant systems. Organizations monitor their SIEMs, their EDR consoles, their firewall dashboards, but the system that handles their most sensitive file transfers? It runs. It transfers files. Nobody watches what it logs.

The MOVEit instances were producing logs. The SQL injection attempts were leaving traces. But the telemetry from these systems was either not being collected, not being forwarded to the SIEM, or not being analyzed by detection rules. The data that could have revealed two years of enemy reconnaissance was sitting in log files that nobody read.

The gap in numbers:

• ~2 years of Cl0p testing and reconnaissance (July 2021 to May 2023)
• 2,700+ organizations compromised in the mass exploitation
• 93+ million individuals’ data exposed
• 0 organizations detected the two-year reconnaissance phase
• $10+ billion estimated total impact across all victims

What monitoring would have caught it: A system that monitored all security-relevant telemetry sources, including MFT platforms, for anomalous access patterns would have detected the SQL injection probing. More fundamentally, a system that tracked whether MFT logs were being collected and analyzed at all would have revealed that this critical data source was completely unmonitored. You can’t detect what you’re not watching. But you can detect that you’re not watching.

Source: CISA Advisory AA23-158A; Kroll Cyber Threat Intelligence report, “Cl0p MOVEit Transfer Exploitation”

Telemetry Failure Types Across Five Breaches

The pattern

Look at these five breaches side by side and a pattern emerges that should concern every security leader:

The security tools were purchased. Equifax had traffic inspection. Target had FireEye. SolarWinds customers had Orion. Colonial Pipeline had IT security infrastructure. MOVEit users had security programs in place.

The security tools were deployed. They were installed, configured, turned on. Budget was allocated. Checkboxes were checked.

The security tools weren’t producing usable telemetry, and nobody noticed.

An expired certificate. A compromised update mechanism. Unactioned alerts. Missing OT monitoring. Uncollected MFT logs. Five different technical failures, but the same organizational failure every time: no system was monitoring whether the monitoring was working.

This isn’t a technology gap. Technology to monitor security telemetry health exists, or rather, it could exist. The gap is conceptual. Security operations are built around the assumption that if tools are deployed, they’re producing useful data. That assumption is wrong, and it’s been wrong in every major breach we examined.

The cost of not knowing

These telemetry failures carry staggering costs:

• Equifax: $1.4 billion in breach costs. A certificate renewal costs $0.
• SolarWinds: Incalculable damage to national security. Monitoring for telemetry gaps in security tools costs nothing compared to the damage.
• Target: $292 million in losses. Monitoring whether alerts are being actioned is a solved problem.
• Colonial Pipeline: $4.4 million ransom, plus untold economic damage from a six-day fuel supply disruption. Any OT visibility would have prevented the blind shutdown.
• MOVEit: $10+ billion in estimated total impact across thousands of organizations. Forwarding MFT logs to the SIEM is a configuration change.

The combined cost of these five breaches exceeds $12 billion. The combined cost of the telemetry monitoring that would have caught them? A rounding error by comparison.

Breach Cost vs. Cost of Monitoring That Would Have Caught It

What these breaches teach us

Each of these incidents reveals a different dimension of the telemetry monitoring problem:

Equifax teaches us that infrastructure monitoring is not telemetry monitoring. The inspection device was up. It was online. It was “healthy.” It just wasn’t doing its job. Monitoring the output of security tools, not just their availability, is what matters.

SolarWinds teaches us that monitoring tools can become blind spots. When the tool you rely on for visibility is compromised, you need an independent system watching whether that tool is behaving normally. Quis custodiet ipsos custodes, who watches the watchmen?

Target teaches us that detection without response monitoring is incomplete. Generating an alert is half the job. Confirming that a human acknowledged, triaged, and acted on that alert is the other half. If nobody monitors the response pipeline, detection is theater.

Colonial Pipeline teaches us that blind spots force worst-case decisions. When you can’t see the blast radius of an incident, you’re forced to assume the worst and take the most disruptive remedial action. Visibility doesn’t just help you detect attacks. It helps you respond proportionally instead of shutting everything down.

MOVEit teaches us that unmonitored data sources are effectively unprotected. Every system in your environment produces logs. The delta between “systems producing logs” and “systems whose logs are collected, forwarded, and analyzed” is your actual attack surface for undetected compromise.

The question worth asking

After reading about these five breaches, consider these questions about your own environment:

• Do you know, right now, whether every security tool you’ve deployed is actively producing telemetry?
• If a sensor crashed on one of your servers at 3 AM last Tuesday, would you know yet?
• Can you tell the difference between “no alerts because nothing is happening” and “no alerts because the data stopped flowing”?
• If you were breached tomorrow, could you immediately tell the investigation team which segments had full telemetry and which had gaps?

If you can’t answer yes to all four, you have the same problem that Equifax, SolarWinds, Target, Colonial Pipeline, and MOVEit had. The only difference is whether an attacker exploits it.

The good news: this is a solvable problem. The technology to continuously monitor security telemetry health, at the individual asset level, across every data source, with real-time alerting, exists. We know, because we’re building it.

The silence is the threat. Detecting it is the answer.

---