What is a watering hole attack and how do you defend against it?

A watering hole attack compromises a website that a specific group of people regularly visits, then uses that site to attack the visitors' browsers or devices. The attacker does not need to trick anyone into opening an email. They wait where the target already goes.

How is it defined?

MITRE ATT&CK catalogs this under Drive-by Compromise (T1189). The entry says an adversary may gain access to a system through a user visiting a website over the normal course of browsing. When the site is one visited by a particular community, such as a government, an industry or a region, MITRE says the campaign is often called a strategic web compromise or watering hole attack.

The word targeted is the key. A general drive-by hits whoever lands on the page. A watering hole picks the page because of who reads it.

How does the attacker get code onto the page?

MITRE lists several routes:

• A legitimate website is compromised and malicious code is injected.
• Script files loaded by a legitimate site from a publicly writable cloud storage bucket are altered.
• Malicious ads are bought and served through legitimate ad providers (malvertising).
• Built-in features that accept user content are abused to insert scripts or iframes, for example through cross-site scripting.
• Browser push notifications are abused after a user clicks allow.

Notice how many of these are about third-party content. The site owner may never touch their own server. A script loaded from a bucket they forgot about is enough.

What happens in the visitor's browser?

MITRE describes a typical sequence. The visitor opens the page. Scripts run and look at the versions of the browser and plugins. If the version is vulnerable, exploit code is delivered. If it works, the attacker gets code execution on the visitor's machine unless other protections are in place. In some cases a second visit is needed before the exploit is delivered. The entry also notes that this commonly gives access to systems on the internal network.

A constructed example

A trade association runs a members' portal for 300 water utility engineers. A script on the portal's login page comes from a storage bucket that a former contractor created. The bucket allows anyone to write. An attacker changes the script so that it only fires for visitors from utility network ranges and with an out-of-date browser. Most visitors see nothing odd. Two engineers with an old browser on an unpatched laptop get a payload. The association's own server logs show no intrusion, because its server was never touched.

Which defenses help?

MITRE's mitigation list for this technique is practical:

1. Keep browsers and plugins updated and use modern browsers with security features on. This removes the exploit stage for known flaws.
2. Use browser sandboxing and application isolation to limit the damage, knowing that sandbox escapes can exist.
3. Restrict web content: ad blockers and script blocking can stop malicious ad code and JavaScript from running, and unneeded push notifications can be disabled.
4. Use exploit protection features that look for exploitation behavior.
5. Train users, mainly for the social steps such as clicking allow on a prompt.

If you run a site that others rely on, add: audit every third-party script and storage location, remove public write access, and monitor for unexpected changes to files your pages load.

How to check or apply this

1. List the websites your staff use for work that are specific to your industry. Those are your likely watering holes.
2. Check that managed browsers update automatically and report versions.
3. Turn off browser push notifications by policy where they are not needed.
4. For sites you run, inventory every external script and every storage bucket your pages load from. Remove public write permission.
5. Alert on changes to those assets, such as a changed file hash or an unexpected new domain.
6. Add the pattern to your incident playbook: a compromised site you only visit, with no phishing email to trace.

Quick check

Sources

• MITRE ATT&CK T1189, Drive-by Compromise

Last reviewed: 18 October 2026.