Three Breaches, One Source
Ingrid was called in after three aerospace defense contractors — all competitors, companies that would never voluntarily share intelligence with each other — all reported similar intrusions within six weeks. The IOC sharing through the sector ISAC revealed the same malware family, the same command-and-control infrastructure, the same infection methodology across all three. Three separate security teams, three separate defended perimeters, three separate breach timelines that converged on a single root cause.
Pulling browser history from the infected endpoints across all three companies, Ingrid found the connection: every compromised workstation had visited aerodefense-weekly.com — a respected industry trade association newsletter read by aerospace professionals across the sector — in the two weeks before each breach. The timestamps were precise. First visit to the newsletter, then minutes later the first callback from the implant to its command-and-control server.
This was a watering hole attack. Instead of targeting the three aerospace companies directly — sending phishing emails into heavily monitored inboxes, probing hardened network perimeters, crafting targeted lures for security-aware employees — the attacker had simply compromised a website that those employees were already in the habit of visiting. The name came from wildlife: some predators do not hunt. They wait at the watering hole — the one place all prey must eventually come. The cyber equivalent was patient, economical, and almost impossible for the victims to detect or prevent through standard security awareness alone.
The Drive-By
The newsletter site was running WordPress 5.8 with a portfolio gallery plugin that had not been updated in eleven months. A known authenticated remote code execution vulnerability in that plugin version had been patched in a subsequent release. The attacker had exploited it to gain administrative access to the WordPress installation and injected two lines of code into the site's footer template.
Those two lines loaded a hidden iframe — a zero-pixel-by-zero-pixel invisible element pointing to attacker-controlled infrastructure. When any visitor's browser rendered the newsletter homepage, their browser automatically loaded that iframe and executed its JavaScript. The script performed fingerprinting first: it collected the browser version and build, the operating system, installed browser plugins, screen resolution, timezone offset, and installed fonts — a precise profile of the visitor's endpoint configuration. That fingerprint was transmitted to a profiling server. Based on the response, the script served a targeted exploit matched to the visitor's specific vulnerable configuration.
This was a drive-by download: malicious code that executed automatically when the browser rendered the page. No download dialog. No "click here to run." No user interaction beyond visiting the site. The exploit ran silently in the background while the visitor read the latest regulatory news in the aerospace sector. If the browser had a known JavaScript engine vulnerability, that exploit was delivered. If the visitor had an outdated PDF plugin, a different exploit was used. The fingerprinting ensured maximum success rate with minimum detection noise.
Historically, commoditized exploit kit toolkits — Angler, Neutrino, RIG — had industrialized this capability, sold and rented on criminal forums, continuously updated as new browser vulnerabilities were discovered. The sophistication of the fingerprinting in this attack suggested a purpose-built kit, likely nation-state grade, but the mechanism was identical to commodity tools.
The Malvertising Layer
Cross-referencing infection timestamps more carefully, Ingrid noticed that some endpoints had been compromised during a window when the injected iframe was temporarily absent from the page — the newsletter's volunteer IT contact had noticed an anomaly and rolled back a plugin update, inadvertently disrupting the iframe injection for several days. But infections had continued during that gap.
The newsletter ran Google AdSense in a sidebar. Ingrid pulled the ad network records. A third-party ad had been purchased through a compromised advertiser account and had rotated through aerodefense-weekly.com's ad unit during the gap period. The ad's creative payload contained obfuscated JavaScript executing the same fingerprinting and exploit delivery logic as the iframe — but served through the ad network's own legitimate JavaScript execution pipeline, indistinguishable from any normal advertisement to the newsletter's server logs.
Malvertising — malicious advertising — exploited the architecture of modern web advertising: websites served ad content from multiple third-party ad networks, and each ad was essentially arbitrary JavaScript executing with the full trust of the page context. An attacker who purchased ad space through legitimate channels, or who compromised an existing advertiser's account, could inject malicious code into an ad creative that would then serve to every website in the ad network's publisher inventory matching the targeting parameters. The same ad could simultaneously reach visitors to dozens of industry sites the attacker had profiled as frequented by their targets. Watering holes at scale.
Even highly reputable websites with strong security programs could serve malvertising — the website's own code was clean. The threat came through the advertising supply chain they had contracted with. The website owner had no visibility into the payload of every ad rendered in their ad slots.
Strategic Web Compromise
As Ingrid built out the attribution picture, the deliberateness of the target selection became apparent. The attacker had not stumbled onto aerodefense-weekly.com. They had profiled the aerospace defense community — identified where that community gathered online: the trade association newsletter, the sector conference site, the regulatory body's portal for compliance guidance, the major prime contractor vendor portal. The newsletter had the highest traffic and the weakest security posture among the candidates. The site selection was an intelligence operation before it was a technical one.
This was Strategic Web Compromise (SWC): deliberate, intelligence-driven selection of a third-party site known to be frequented by a specific victim community, as a mechanism for reaching that community without direct engagement. SWC was categorically different from opportunistic malvertising aimed at any available visitor. An SWC operation profiled where the targets browsed before choosing where to plant malware, and the compromise was maintained quietly for as long as needed to collect the targeted victims.
Nation-state APT groups used SWC extensively against defense contractors, government agencies, dissident communities, and critical infrastructure operators. The defining technical signature was visitor fingerprinting used not just for exploit targeting but for victim filtering: the malicious code examined the visitor's IP address against the target organization's known IP ranges, and only served the exploit to visitors matching the target profile. Security researchers, automated scanners, and employees of non-target organizations saw a perfectly clean site. Only employees of the three targeted aerospace companies — browsing from corporate IP addresses — received the malicious payload.
Island Hopping
Working back further through server logs, Ingrid found that the newsletter site had not been the attacker's first move. The site was hosted and managed by a small IT managed service provider — a five-person shop servicing seventeen clients, including both the newsletter and, coincidentally, one of the three targeted aerospace companies. The MSP's remote management platform had been compromised first, through a credential phishing campaign targeting the MSP's own staff — a much softer target than an aerospace defense contractor's hardened, monitored environment. From the MSP, the attacker had remote management access to all seventeen client systems. Compromising the newsletter site had been trivial from that position.
This was island hopping: using a less-secure third party as a stepping stone to reach the actual target. The concept came from World War II Pacific strategy — moving from island to island, each step enabling the next advance toward the primary objective. In cybersecurity, the "islands" were the intermediate organizations: vendors, MSPs, contractors, law firms, accounting firms, cloud service providers — any entity with trusted access to the primary target.
The canonical illustration remained the 2013 Target Corporation breach. Target had strong security on their payment processing systems. Attackers compromised Fazio Mechanical Services — an HVAC and refrigeration vendor with network access to Target's systems for remote temperature monitoring. Fazio's credentials were used to authenticate to Target's vendor portal. From there, the attackers pivoted through a network segmentation failure to the point-of-sale network and installed RAM-scraping malware on POS terminals in 1,797 stores. Approximately 40 million credit card numbers and 70 million customer records were exfiltrated. The cost to Target exceeded $162 million; both the CEO and CIO resigned. Fazio had nothing the attackers wanted. Target did. Fazio was the island.
SolarWinds: The Ultimate Watering Hole
Ingrid used SolarWinds as her anchor teaching case for the ISAC sector briefing, because SolarWinds was what happened when the watering hole concept was extended to its logical extreme — not a website, but a software update mechanism itself.
In 2020, investigators determined that the Russian SVR — Foreign Intelligence Service, known in Western threat intelligence as Cozy Bear and APT29 — had compromised the build pipeline of SolarWinds, a major IT monitoring software vendor whose Orion platform was used by more than 33,000 organizations worldwide, including a significant portion of US federal agencies. The attacker had inserted malicious code — SUNBURST — directly into the Orion source code during the build process, before compilation. The resulting software update packages were compiled, digitally signed with SolarWinds' legitimate code-signing certificate, and distributed through SolarWinds' official update servers as routine Orion updates.
Approximately 18,000 customer organizations downloaded and installed the trojanized update. Among them: the US Treasury, State Department, Department of Homeland Security, Department of Energy, and the cybersecurity firm FireEye, which discovered the attack after noticing its own red team tools had been stolen. The signed binary passed every security check — the hash matched, the certificate chain was valid, the software came from a trusted vendor through a trusted update mechanism. Every check passed because the compromise had occurred upstream of all checks, in the build system itself, before the binary was generated.
SUNBURST was dormant for 12 to 14 days after installation — specifically to defeat sandbox analysis environments. It then used SolarWinds' own legitimate network protocols for command-and-control communication, blending with normal Orion traffic in network logs. The "watering hole" was the software update process every security team had been trained to perform diligently.
XZ Utils and SBOM
Ingrid's second anchor case for the briefing was more recent and, in some ways, more alarming than SolarWinds — because it required no nation-state build-pipeline access. It required only patience and a convincing false identity.
In March 2024, Andres Freund — a Microsoft engineer doing performance benchmarking on a Debian Linux system — noticed that SSH logins were approximately 500 milliseconds slower than expected. On a benchmarking system, 500 milliseconds was an anomaly worth investigating. He traced the latency to the xz utilities package — a widely-used compression library present on virtually every Linux system — and specifically to versions 5.6.0 and 5.6.1, recently updated. What he found embedded in the xz build system was CVE-2024-3094: a sophisticated backdoor that, in production Linux distributions, would have allowed remote code execution on any Linux system running a systemd-based SSH daemon — a description applicable to hundreds of millions of servers worldwide.
The backdoor had been inserted by a contributor operating under the identity "JiaT75" (Jia Tan), who had spent approximately two and a half years building credibility in the xz open-source project: submitting quality bug fixes, being genuinely helpful to the overwhelmed maintainer, gradually accumulating commit access. The compromised versions were already present in the development branches of Debian, Fedora, and other major distributions. Had Freund not been benchmarking at exactly that moment, the backdoor would have shipped in stable releases within weeks and been installed on production systems globally.
The defense framework for software supply chain attacks centered on three capabilities. First, SBOM — Software Bill of Materials: a machine-readable inventory of every software component, library, version, and dependency in an application or system. An SBOM enables organizations to immediately identify whether they use a vulnerable component when a CVE is published. When Log4Shell was disclosed in December 2021, organizations with SBOMs assessed their exposure in hours; organizations without them spent weeks manually inventorying application stacks. CISA and Executive Order 14028 now require SBOMs for software sold to US federal agencies. Second, SCA — Software Composition Analysis: automated tooling that scans source code and build manifests for known-vulnerable components, running continuously in CI/CD pipelines. Third, reproducible builds: a build process allowing any party to independently verify that the distributed binary matches the published source code exactly, making silent injection during the build process detectable by comparison.
Defense Strategy
Ingrid closed the ISAC briefing with her recommendations, framed around the core challenge: watering hole defenses had to assume that any legitimate website could be compromised. The attack's entire premise was that the victim visited a real, trusted site and did nothing wrong. Traditional security awareness — "don't click suspicious links" — provided zero protection, because there were no suspicious links. The attack required only that the visitor render a webpage.
Remote Browser Isolation (RBI) was her highest-confidence recommendation for privileged users. In RBI, the browser did not execute locally. Browsing was performed in a remote isolated container — a cloud-based or on-premise virtual machine — and only the rendered pixel stream was transmitted to the user's screen. JavaScript executed in the container. Exploits executed in the container. If a drive-by download succeeded, the malware ran in a disposable container that was destroyed when the session ended and never had access to the corporate network. The user saw the same webpage. The malware had nowhere to reach.
DNS filtering — Cisco Umbrella, Cloudflare Gateway, and similar platforms — blocked connections to known malicious domains at the DNS resolution layer, before any connection was established. Even after a successful drive-by exploit, the deployed malware needed to reach its command-and-control server. DNS filtering severed that communication for known C2 infrastructure.
Third-party risk management addressed the island-hopping and MSP-pivot vectors: vendor security assessments before granting any network access, contractual security requirements, strict network segmentation of vendor connections to only the specific resources they required, mandatory MFA for all vendor remote access, just-in-time provisioning rather than standing access, and session logging for all vendor activity. The MSP that had been the stepping stone to the newsletter would have been identified as a risk under a mature TPRM program.
SBOM adoption for all critical software, combined with SCA scanning of development dependencies and reproducible builds for internally developed software, provided the supply chain visibility layer.
Patch management remained foundational: exploit kits targeted known, patched vulnerabilities the majority of the time because the target population's patching lag provided a sufficient attack surface without the risk of burning zero-days. Aggressive browser and OS patching significantly reduced that surface.
Security awareness mattered in a specific way for watering holes: employees should understand that legitimate, trusted sites can be compromised. The newsletter was not suspicious. The goal was not to make employees paranoid about every site — it was to ensure that when browser-based alerts or EDR notifications triggered, employees took them seriously rather than dismissing them as false positives on a "safe" site.