Join our Newsletter — 33% off our NHI Course

Website Compromise

Website compromise is the state in which an attacker has gained enough access to alter site content, inject scripts, or persist malicious changes. In cryptojacking incidents, it usually means the mining code is only one outcome of a broader security failure. The compromise must be investigated, not just the visible payload removed.

How Website Compromise Happens

Website compromise usually starts with a weakness that lets an attacker change server-side content or application behaviour, then progresses to script injection, defacement, malicious redirects, or persistence inside templates, plugins, credentials, or deployment paths. The visible payload is often only the symptom.

That distinction matters because the compromise may sit in the application layer, the hosting layer, or the delivery chain. If the attacker can continue to write content, tamper with code, or reuse stolen access, the site can be re-compromised even after the obvious malicious script is removed.

A common pattern is abuse of trusted publishing paths, which can include stolen admin credentials, vulnerable extensions, exposed secrets, weak file permissions, or compromised third-party integrations. In those cases, the site remains unsafe until the underlying access path is found and closed.

What Changes When the Site Is Compromised

A compromised site stops being a trusted publishing channel and becomes an attacker-controlled delivery point. That can affect visitors through malicious JavaScript, credential theft, fake payment flows, drive-by downloads, or redirect chains that move traffic to other infrastructure.

The compromise can also damage integrity in ways that are harder to see than a defacement. Search-engine poisoning, SEO spam, hidden iframe injection, and altered checkout or login logic can survive long enough to create business, reputational, and fraud impact before anyone notices.

For cryptojacking, the mining payload is usually incidental. The real issue is that the attacker has achieved enough control to run arbitrary code, so the same access could just as easily support data theft, phishing, lateral movement, or persistence.

Why Investigation Must Go Beyond Cleanup

Removing the visible payload without tracing the original entry point leaves the attacker’s foothold intact. Good investigation looks for altered files, new administrator accounts, unexpected cron jobs, web shells, credential misuse, and changes in deployment or content management paths.

It also helps to compare the current state with known-good versions so you can identify what was changed, when it changed, and whether the attacker modified multiple layers. The compromise may involve both the website and the systems that publish or support it, so containment often has to extend beyond the homepage.

Where the compromise involved stolen credentials or reused secrets, the recovery scope should include those access paths as well. A site can appear clean while the attacker still has the ability to log back in or reintroduce malicious content through a trusted workflow.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
CIS Controls v8 CIS 5 — Account Management Website compromise often follows abused admin or publishing accounts.
CIS 6 — Access Control Management Compromise persists when attackers retain write access to site content or deployment paths.
CIS 16 — Application Software Security Injected scripts and altered site behaviour are application-security failures at the web layer.
Recommendation — Review and revoke unneeded website admin access, and alert on suspicious account changes. Enforce least-privilege write access for web content, plugins, and deployment systems. Scan web apps and extensions for tampering, insecure components, and injected code.
NIST CSF 2.0 PR.AC — Identity Management, Authentication and Access Control Compromise frequently uses stolen credentials or misused access to alter site content.
DE.CM — Continuous Monitoring Compromised sites require detection of unauthorized file, script, and account changes.
Recommendation — Tighten authentication and access control around content publishing and administration. Monitor website files, accounts, and deployment activity for unauthorized change.
MITRE ATT&CK T1190 — Exploit Public-Facing Application Public-facing web apps are a common entry path for website compromise.
T1505.003 — Web Shell Persistent malicious changes on a website often involve web shells or similar backdoors.
T1059.007 — JavaScript Injected JavaScript is a common payload in compromised websites.
Recommendation — Hunt for exploit-driven access in web app logs and patch exposed services quickly. Inspect web roots for unauthorized scripts and remove any web shell footholds. Validate front-end code integrity and investigate unexpected script execution paths.
OWASP Non-Human Identity Top 10 NHI-01 — Secrets Management and Rotation Website compromise often begins with exposed or reused publishing secrets and tokens.
Recommendation — Rotate exposed web credentials and move secrets into controlled secret storage.

Practitioner Guidance

What to watch for: Treat any unexpected script, redirect, admin account, plugin change, or unexplained content drift as a sign of broader compromise rather than a single-page problem. The practical question is not only what was injected, but how the attacker got write access in the first place.

Governance implication: Website ownership needs clear separation between content administration, code deployment, and secret management. When those controls blur, compromise becomes easier to miss and harder to contain because one stolen access path can affect the whole publishing pipeline.