toolkit

Scenario · Something looks broken

There's spam text on the page

“There's spam text on the page.” The detection step — see `site-got-hacked` for the response.

Spam text suddenly appearing on a page isn't a copy problem — it's a sign the site has been compromised, and treating it as a wording fix instead of a security incident is how the same injected content quietly comes back within days. This scans for the actual patterns of injected spam — pharmacy and casino text, phishing bait, foreign-language keyword blocks — and stays deliberately quiet on a clinic's own legitimate medical content, so a real finding here is a trigger to escalate immediately, not something to just edit away.

What to ask for

Injected-content scanInjected-content scan — finds content on a site that should not be there.

See it work

A real run of Injected-content scan:

FAIL
      [error] Pharmacy spam: "Buy cheap viagra"

  report: ./out/injected-content-scan-injected-content-scan.html
  text:   ./out/injected-content-scan-injected-content-scan.txt

The captured report, exactly as a run hands it to a client —open the full report ↗

Injected content is not a copy problem, it’s a compromise finding. Every pattern here requires spam grammar, never a topic word alone — a clinic’s own drug list reads as medicine; “buy cheap viagra no prescription” reads as an injection — which is what keeps this check quiet on a site that legitimately writes about medicine.

  1. Run the foreign-content scan against the affected public page and preserve the flagged evidence exactly as found — a screenshot and the raw matched text, not a paraphrase.
  2. Treat any confirmed finding as an investigation trigger, not a copy edit. Identify the exact page, the injected text, and — if visible — the mechanism (a hidden div, a foreign-script block, a stuffed link) before anyone touches the content.
  3. [manual] Escalate immediately to the site owner for containment and root-cause work. This check finds what’s there; it does not clean files, rotate credentials, or find how the injector got in — see site-got-hacked for that response, in that order (contain, then clean).
  4. After the owner remediates, rerun the check and keep both reports — the before and the after — so a recurrence is visible rather than assumed fixed.

A finding here is not the end of the job

Deleting the visible spam and closing the ticket is the standard mistake: if the entry point is still open, the same content comes back within days. This scenario is the detection half; the response — containment before cleanup, in that order — is site-got-hacked.

What this does not cover

The entry point, and the cleanup. It finds injected or foreign-script content that does not belong on the page — pharmacy/casino/replica spam, phishing bait, a foreign-language keyword block, hidden link stuffing. It does not fix anything, identify how it got in, or scan the rest of the site; the injector re-adds it within days unless someone finds the entry point.

← All scenarios