Watering Hole Attacks Guide: Compromised Websites and Strategic Web Compromise

A watering hole attack compromises a website that a chosen group already trusts and visits, then uses it to deliver malware or exploits to those visitors. The technique is also called strategic web compromise, and MITRE ATT&CK files it under Drive-by Compromise (T1189), with the attacker's preparation of the site recorded as Drive-by Target (T1608.004). It bypasses email filtering and user suspicion because the lure is a legitimate site: an industry association, a regional news outlet, a supplier portal or a community forum. This guide explains how these campaigns work at a level useful to defenders, where they appear, how to detect them and which browser, network and endpoint controls reduce the risk. It is written for security architects, SOC analysts and endpoint engineers, and it deliberately contains no attacker procedures.

Key takeaways

• Trust is the delivery mechanism. Users visit the compromised site voluntarily, so awareness training and email controls do little; browser and endpoint controls carry the load.
• Most campaigns filter their victims. Injected scripts fingerprint visitors and serve the payload only to the IP ranges, browsers or regions of interest, which hides the compromise from researchers and from most site owners.
• Two payload routes dominate. Browser or operating system exploits (sometimes zero-days) and fake software update prompts that rely on the user running a download. Defend against both.
• Patch velocity for browsers is the main control. In the published iOS and macOS campaigns, the exploits used were already patched or were fixed within days of disclosure; unpatched clients are the exposure.
• You may also be the watering hole. Your public website can be compromised to target your customers or partners, so integrity monitoring of your own web estate belongs in the same programme.

How the attack works

A watering hole campaign has four defender-relevant stages. Understanding them tells you where telemetry exists and where controls can break the chain.

1. Target selection: the attacker identifies sites a sector, community or company habitually visits. Industry news, trade bodies, regional government pages, diaspora and religious community sites, and software download pages recur in published reporting.
2. Site compromise: the attacker gains write access to the site, typically through an unpatched content management system, plugin, hosting account or stolen administrator credentials, and inserts a script, iframe or redirect (ATT&CK T1608.004 Drive-by Target; the site itself becomes compromised infrastructure, T1584.004 Server).
3. Visitor profiling: the injected script collects browser, operating system, IP address, referrer and sometimes cookie data and sends it to an attacker server that decides whether to serve the next stage. Kaspersky's 2020 "Holy Water" report described a validator that returned a simple yes or no for each visitor, so non-targets saw nothing unusual.
4. Payload delivery: selected visitors receive either an exploit chain against the browser and operating system (T1203 Exploitation for Client Execution) or a social engineering prompt, most often a fake browser or plug-in update, that delivers a file the user runs (T1204.002 Malicious File).

After execution the behaviour is that of any intrusion: an implant, credential theft, lateral movement. The watering hole only explains how the first device was reached.

Watering hole compared with related techniques

See the Malvertising and SEO Poisoning Guide and the Phishing Guide for those neighbouring techniques.

Where it shows up

• State espionage against communities: Google's Threat Analysis Group reported in November 2021 that two Hong Kong websites, a media outlet and a pro-democracy labour and political group, served exploits through iframes to visiting Mac and iPhone users. TAG assessed the actor as well resourced and likely state backed.
• Mass but covert surveillance: Google Project Zero's August 2019 analysis described a small set of hacked sites, receiving thousands of visitors a week, that attacked every visiting iPhone with no target selection, using five exploit chains covering iOS 10 to iOS 12.
• Disruptive and criminal payloads: ESET's October 2017 analysis of Bad Rabbit described popular news and business sites in Russia, Ukraine, Bulgaria and other countries injected with JavaScript that offered selected visitors a fake Flash Player update. The ransomware then spread inside networks over SMB.
• Threat groups on record: ATT&CK lists many groups with Drive-by Compromise procedures, including APT28, APT32 and APT37. See the APT28 (Fancy Bear) Threat Actor Profile.
• Sector and supplier sites: trade association portals, regulator pages and supplier download areas are attractive because the visitor population is predictable. A compromised vendor support site that serves a modified installer sits on the border with supply chain compromise; see the Software Supply Chain Security Guide.

Impact

• Initial access to well-defended organisations: staff who would never open an unknown attachment still read the sector news site, so a watering hole reaches users that phishing does not.
• Full device compromise without user action: exploit-chain campaigns need only a page visit. The 2019 iOS chains installed a monitoring implant on visiting phones.
• Credential and session theft: an implant on a workstation can read browser-stored sessions, tokens and saved passwords, so the identity exposure outlasts the endpoint clean-up.
• Propagation: where the payload carries worm-like spreading, as Bad Rabbit did over SMB, one visit becomes a network-wide incident.
• Reputational and legal exposure for the site owner: an organisation whose website served malware to its own customers faces notification questions and loss of trust even though it was not the target.

Detection

Detection is hard at the delivery stage because the domain is legitimate and the payload is served selectively. The most reliable signals come from what happens on the endpoint immediately after the visit. ATT&CK's detection strategy for T1189 draws on proxy, firewall and HTTP logs, browser child-process activity, file writes to temporary folders, macOS unified logs and identity provider events such as new token issuance.

When one host triggers, pivot on the referring site: query proxy logs for every user who visited the same page in the same window, because profiling means some visitors received the payload and some did not.

Metrics that show the controls work

• Browser patch latency: median and 95th percentile time from a browser security release to deployment across the estate.
• Unsupported or outdated browser count: devices running browser versions more than one release behind, target zero.
• Executable download block rate: share of executable downloads from uncategorised or low-reputation sites that were blocked or detonated.
• SmartScreen or safe browsing bypass attempts: should be zero once bypass is prevented by policy.
• Time to scope: time from a browser child-process alert to a full list of other visitors to the same page.

Prevention and hardening

Browser and endpoint controls

• Fast browser and OS patching (ATT&CK M1051 Update Software): treat browsers as internet-facing software with automatic updates and a forced relaunch deadline measured in days. See the Patch Management Guide.
• Reputation filtering with no bypass: on Windows, enable the Edge policy "Configure Microsoft Defender SmartScreen" and set "Prevent bypassing Windows Defender SmartScreen prompts for sites" and "Prevent bypassing of Microsoft Defender SmartScreen warnings about downloads" (MDM: Browser/AllowSmartScreen, Browser/PreventSmartScreenPromptOverride, Browser/PreventSmartScreenPromptOverrideForFiles). Microsoft notes SmartScreen does not cover files on UNC or SMB paths.
• Application control (D3FEND Executable Allowlisting): users should not be able to run a downloaded "update". AppLocker or Windows Defender Application Control on Windows, and equivalent controls elsewhere, stop the fake-update route outright.
• Exploit protection and sandboxing (M1050, M1048): keep browser sandboxing and site isolation at their defaults, do not grant users local administrator rights, and keep OS exploit mitigations on. The 2021 macOS chain failed on Big Sur because of its added protections.
• Restrict web content (M1021): remove legacy plug-ins, block script execution on uncategorised sites for high-risk groups, and control extensions. See the Enterprise Browser and Browser Security Guide.
• Isolation for high-risk users: remote browser isolation keeps active content off the endpoint for executives, administrators and staff who must visit sites linked to targeted communities. See the Remote Browser Isolation Guide.

Network controls

• Protective DNS (D3FEND DNS Denylisting): the NCSC describes protective DNS as checking both the requested domain and the returned IP against deny lists. Block outbound DNS on ports 53 and 853 that does not use the approved resolver, and disable DNS over HTTPS or route it through the protective resolver so logging continues. See the DNS Security Guide.
• Secure web gateway with URL reputation (D3FEND URL Reputation Analysis): block newly registered and uncategorised domains for executable downloads and detonate executables in a sandbox (NIST SP 800-53 SC-44 Detonation Chambers). See the Secure Web Gateway and Web Filtering Guide.

Protecting your own sites from becoming the watering hole

• Harden the publishing chain: patch the CMS and plugins, enforce MFA on CMS and hosting accounts, and remove unused administrator accounts.
• Detect unauthorised change: run file integrity monitoring on web roots and alert on new third-party script sources.
• Constrain what pages can load: a Content Security Policy listing allowed script sources, and Subresource Integrity hashes on third-party scripts, make injected scripts fail or stand out.

Choosing controls by organisation size

The trade-off is friction: isolation and allowlisting break some sites and installers. Start in audit mode, measure what would have been blocked for two to four weeks, then enforce in pilot rings.

Rollout sequence

1. Inventory browsers, versions and extensions; set forced update policies.
2. Enable reputation filtering, first with warnings and logging, then with bypass prevented.
3. Deploy protective DNS and block alternative DNS paths, keeping an allow list for critical services.
4. Deploy EDR detections for browser child processes and executable writes; tune with a week of baseline.
5. Run application control in audit mode, review the log, then enforce for a pilot ring before wider rollout. Keep the previous policy version for rollback.
6. Add isolation for high-risk users and harden your own web estate.

Framework mapping

Lessons from incidents

• iPhone campaign, 2019: Project Zero reported two of the vulnerabilities to Apple on 1 February 2019 and Apple shipped iOS 12.1.4 on 7 February. Devices that took the update promptly closed the zero-day exposure; mobile fleets need the same patch deadlines as laptops.
• Hong Kong sites, 2021: the browser exploit, CVE-2021-1789, had been patched in January 2021, months before the campaign was found in August. An n-day was enough because visitors had not updated.
• Bad Rabbit, 2017: the fake update only worked where users could run executables, and ESET's update noted that the MS17-010 patch stopped its SMB spreading. Application control and patching both cut the chain.
• Holy Water, 2019 to 2020: Kaspersky found no exploit at all, only a fake Flash update hosted on GitHub. Reputation filtering and blocking user-run installers would have stopped it, while patching alone would not.

Practitioner checklist

• Set forced browser updates with a relaunch deadline and report browser patch latency monthly.
• Enable SmartScreen or safe browsing and block user bypass for sites and downloads.
• Remove local administrator rights and enforce application control for user-writable paths.
• Deploy protective DNS and block DNS on ports 53 and 853 outside the approved resolver.
• Detect browsers spawning shells, script hosts or installers, and executables written by browsers.
• When an alert fires, scope every visitor to the referring page, not just the alerting host.
• Revoke sessions and tokens for users whose devices were compromised; see the Identity Incident Response Playbook.
• Use isolation for high-risk roles and keep admin workstations off general browsing.
• Monitor your own websites for file changes and new third-party script sources, with CSP and SRI in place.

Standards and references

• MITRE ATT&CK: Drive-by Compromise (T1189)
• MITRE ATT&CK: Drive-by Target (T1608.004)
• NCSC: Mitigating malware and ransomware attacks
• NCSC: Protective DNS for the private sector
• Microsoft Learn: Available Microsoft Defender SmartScreen settings
• Google Project Zero: A very deep dive into iOS exploit chains found in the wild
• Google TAG: Analyzing a watering hole campaign using macOS exploits
• Kaspersky Securelist: Holy water, ongoing targeted water-holing attack in Asia

Related NHI Mgmt Group resources: Enterprise Browser and Browser Security Guide · Remote Browser Isolation Guide · Malvertising and SEO Poisoning Guide · Zero-Day and Exploited Vulnerabilities Guide · Threat Intelligence Guide