Poisoned Destinations

## The idea Most social engineering starts with a message: someone picks recipients, writes a lure, and pushes it at them. A **watering hole** inverts that. The attacker picks a *place* the intended people already go, poisons it, and waits. The name comes from a predator sitting at the pool rather than chasing individual animals across the plain. ## Why the readership is the mechanism The selection work is done by whoever reads the site. Suppose there is an industry-association page that publishes the specification updates and conformance notes for one narrow sector, and in practice its weekly readers are the platform engineers of the two dozen firms in that sector. An operator who gets content onto that page has reached exactly those engineers, and has done so **without ever knowing a single name, address or phone number**. That is the whole trick, and it is why the technique is described as targeted even though the operator never targeted anybody. Three consequences follow, and interviewers probe all three: 1. **There is no message, so there is no message-shaped defence on the path.** Nothing was mailed, so nothing was evaluated for sender authenticity, nothing was rewritten, and there is no recipient list to reason about afterwards. Reasoning that starts with `how did it get past mail?` has already gone wrong. 2. **The reputation involved is real.** The domain was registered years ago, it belongs to the organisation whose name is on it, it is bookmarked, and the visitor arrived by habit rather than by clicking a link somebody sent. Every heuristic a person is taught for spotting a lure - check the sender, hover the link, look at the domain - is aimed at a message that does not exist here. 3. **Precision is bounded by readership, not by intent.** If the site is read by the sector *and* by students, journalists and search-engine crawlers, all of them are in scope. Collateral reach is the default cost of the technique. ## How operators narrow it anyway Because collateral reach is a cost, the poisoned page is often not served to everyone. Server-side filtering can gate on the source address range or the network the visitor comes from, on geography, on browser language or user agent, on the referring page, or on whether a cookie from an earlier visit is present. Non-matching visitors are handed the ordinary page and never see anything unusual. This is a *narrowing* move: it shrinks the pool to something closer to the intended readership, at the price of missing intended visitors who look wrong. ## What class of thing this is - and what it is not Getting the classification right matters more than the label: - It is a **delivery** technique. It answers `how does the content reach the person`, not `what does the content do`. - The poisoned thing is a **destination a human chose to visit**. If the poisoned thing sits inside an automated build path - a package namespace, a mirror, an installer pulled by a pipeline - that is a different family with different economics, because no human is choosing anything and the reach is every consumer of that artefact rather than every reader of a page. - It does not by itself imply a flaw was used. A watering hole can serve an exploit, or it can serve a panel that asks the visitor to download something. Those are different mechanisms with different answers, and assuming the first is the most common mistake here. ## The economics, from the other side A watering hole is not cheap. The operator must first obtain write access to a third party's site, or find a component that site includes and poison that instead. What they buy with that effort is reach into a group they could not have enumerated, arriving with the third party's credibility attached. That is why the technique is associated with operators who care about a *category* of victim - a sector, a community, a country's engineers - rather than with anyone hunting one named organisation, who would find a direct route cheaper. ## What removes it The thing the technique cannot substitute is a person's browser fetching content from a destination the person chose. You cannot patch a site you do not own, so the levers that actually bite are further down: controlling what may run on the endpoint after the fetch, and removing the dependency on the third-party resource so your people are no longer part of that readership.