The Collective Era 1999–2012

Section 07 / 13 / Hosting Security

Injected Link Rings on Amateur Shared Hosting

How injected-link campaigns hit hobby sites: what the injections looked like, how operators found them, and why the spam outlives the site by a decade.

A dusty rack-mounted server showing an amber warning light in a small equipment closet

Somewhere in the middle of most dead hobby sites' histories there is an incident nobody wrote about at the time. For a few weeks or months, the site was serving a block of outbound links to products it had nothing to do with — outerwear, handbags, footwear, watches — placed there by somebody who had never read a page of it. This happened to an enormous number of amateur sites in the 2010s, and its traces are still measurable more than a decade later. It is worth understanding both as history and as a live risk, because the failure modes have not changed.

Why hobby sites were the target

The campaigns were not after traffic, data or defacement. They were after links. A page on a long-established domain with a genuine history and real inbound citations is worth something to whoever is trying to rank a storefront, and the cheapest way to obtain one is to take it.

Amateur sites were ideal marks on four counts. They ran on cheap shared hosting where hundreds of accounts sat on one machine, so a single weak neighbour could expose everyone. They accumulated add-on software — a forum, a gallery, a guestbook, a hit counter — which was installed once and never patched. They were maintained by one part-time volunteer who checked the site by looking at the front page in a browser. And critically, they were old: the same properties that made them worth citing made them worth stealing.

What an injection looked like

The signature technique on static sites is almost comically blunt: a block of anchor tags appended to the HTML file after the closing </html> tag. Browsers of the period tolerated content there and rendered nothing visible, or rendered a strip of links below the fold that nobody scrolled to. Automated crawlers parsed it perfectly.

Variants abounded and all of them optimised for invisibility to a human eye:

  • Links wrapped in a container positioned far off-screen with a negative coordinate, or given a zero height and hidden overflow.
  • Text set to the exact background colour of the page.
  • Content served conditionally — the injected block returned only to requests that looked like a search-engine crawler, so the operator viewing their own site saw nothing wrong.
  • On sites with a database-driven component, links written into a template or a footer field so they appeared on every page at once without any file looking modified.

A telling detail from surviving cases: the injection frequently targeted only the front page. The rest of the site — hundreds of comic pages, section indexes, community areas — was left untouched, because only the front page carried enough accumulated authority to be worth the effort. Anyone auditing a suspected compromise from a browser rather than from the filesystem will therefore find the damage in exactly the one place they are least likely to look carefully.

The reciprocal ring

Individual sites were not compromised in isolation. They were assembled into rings: dozens or hundreds of unrelated compromised properties, each linking to the others and all of them linking to a small set of commercial destinations. The clusters were startlingly ordinary — a lumber yard, a neighbourhood church, a civic association, a regional charity, a hobby comics site — with nothing in common except a hosting provider or an unpatched package.

Ring membership is what made the campaigns durable. Cleaning one site removed one node; the other three hundred kept carrying links to it, so the target site's link profile continued to show the spam long after the site itself was clean. Anyone analysing a domain's history today will see this and is likely to misread it. A concentrated burst of thousands of referring domains appearing within a three-to-five-month window, all with commercial anchors bearing no relation to the site's subject, is not the site's history — it is somebody else's campaign that happened to be aimed at it.

How operators found out

Rarely by looking. The three realistic discovery paths were all external: a search engine flagged the site or its listing began showing unrelated product terms; the hosting provider sent a notice, often accompanied by a suspension; or a reader emailed to ask why a comics site was advertising winter coats.

The lag was substantial. Comparing archived captures of compromised hobby sites, an injection routinely sat live for two to four months before anything visible changed. Then a holding page would go up — some variant of "pardon our dust, we are fixing a problem" — for a few weeks, followed by a restored site.

Why the cleanup usually failed the first time

Removing the visible block is not a fix, and this was the near-universal mistake. The injected links are the output; the access is the problem. If the entry route was an outdated forum package or a stolen FTP credential, deleting the appended HTML buys days.

The steps that actually worked, then and now, are unglamorous:

  1. Rotate every credential — hosting control panel, FTP, database, and any content-management account — from a machine you have reason to trust, since credential-stealing malware on the operator's own computer was a common vector.
  2. Find the entry point before restoring anything. Check modification timestamps across the whole document root, not just the pages you noticed; look for files whose timestamps cluster on one date you cannot account for.
  3. Remove or update the add-on software. An abandoned forum with no posts since 2011 is not worth the exposure — take it offline and redirect its addresses.
  4. Restore from a backup that predates the intrusion, then reapply legitimate changes by hand. Restoring the most recent backup usually restores the injection.
  5. Compare against a known-good copy afterwards. A simple file-by-file diff of the document root catches what a visual check never will.

The OWASP Top Ten is still the clearest short summary of how these intrusions begin — outdated components and broken access control account for most of them — and national cyber agencies such as CISA publish plain-language guidance aimed squarely at small operators with no security budget.

Why the spam outlives the site

This is the part that surprises people. A hobby site compromised in 2014, cleaned in 2015, frozen in 2020 and removed from hosting in 2022 will still, in the 2020s, show tens of thousands of referring domains carrying commercial anchors. The site has not existed for years. The links persist because they live on other compromised sites, many of which were never cleaned at all and are themselves abandoned. Each of those pages keeps being recrawled, so the link keeps being recorded as current.

The practical consequences are real. Anyone evaluating one of these domains — for archival research, for acquisition, for any purpose — will see a link profile that is overwhelmingly junk, with the genuine history buried underneath at perhaps one or two percent of the total. The honest read requires separating the burst from the baseline: look at when links first appeared, whether they cluster in a narrow window, whether their anchor text has anything to do with the subject, and whether the addresses they point at ever existed on the site. Campaign templates commonly targeted paths that were never real — a server-side script extension on a site that only ever served static files, for example — which is one of the cleanest tells available.

What this means for the archive

For preservation work, the compromise window matters in a specific way: captures taken during it are not representative of the site, and the holding page that replaced the front page during cleanup is not the site either. Both turn up in archives and both get mistaken for the real thing. Date the incident from the captures, exclude that window, and read the site on either side of it — because in most cases the actual publication carried on entirely normally throughout. The intrusion was a parasite on the site, not a chapter in its history. That distinction is easy to lose and it is the difference between an accurate account and a defamatory one. See archive decay for where the incident usually sits in the wider sequence, and preserving webcomics for making a copy before any of this becomes relevant.