Cryptojacking creates dual impact because the visitor loses CPU cycles and battery life, while the site owner inherits the larger security failure that allowed the code to be planted. In many cases, the mining script is only a visible symptom of a broader compromise. That means the real risk can extend to data exposure, persistence, and further attacker activity on the web server.
Why cryptojacking is a shared risk, not just a visitor nuisance
Cryptojacking is usually read as a performance drain, but the real security concern is that it often exists because an attacker already gained a foothold in the web stack. For visitors, that means waste and degraded experience. For site owners, it can indicate script injection, web shell activity, stolen credentials, or weak controls that let the miner persist.
The visitor impact is immediate and visible: CPU consumption rises, devices heat up, batteries drain faster, and page responsiveness drops. That does not make the issue harmless. A malicious script running in-browser still demonstrates that untrusted code can execute in a trusted session, which is a useful signal that the page or one of its dependencies has been compromised.
How the owner-side risk extends beyond the mining script
The owner-side risk is broader because cryptojacking is often only the symptom. If an attacker can place or inject mining code, they may also be able to access server-side secrets, alter application files, plant persistence, or pivot to other actions on the host. That turns a resource-abuse incident into a web integrity problem and potentially a data exposure problem.
In practice, the same weakness that allowed the miner can also enable broader compromise, for example a vulnerable CMS plugin, exposed admin credentials, insecure deployment pipeline, or reused keys in code or config. The miner consumes resources, but the compromise mechanism is what matters most for incident scope and remediation.
Risk and Threat Considerations
Cryptojacking matters because it can hide in plain sight while signalling a deeper compromise path. The attacker benefits from quiet, long-lived execution, while the owner absorbs resource cost, reputational damage, and the possibility that the same access path is being used for data theft or further intrusion.
Failure mechanism: A malicious script, injected dependency, or compromised server component gains execution in the web delivery path and continues running because the underlying trust failure is not removed.
Impact: Visitors experience degraded performance and battery loss, while site owners may face persistence, broader server compromise, and exposure of data or authentication material.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK 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 4 — Secure Configuration of Enterprise Assets and Software | Cryptojacking often follows insecure software or hosting configuration. |
| CIS 5 — Account Management | Stolen or abused admin access can let attackers plant cryptojacking code. | |
| CIS 8 — Audit Log Management | Cryptojacking investigations depend on logs that show injection, access, and persistence. | |
| Recommendation — Harden web assets and remove unsafe defaults that allow code injection or persistence. Review and revoke unnecessary administrative access paths that could be used to modify web content. Centralise and retain logs that can reconstruct how the mining code was introduced and maintained. | ||
| NIST CSF 2.0 | PR.AC — Access Control | Owner-side risk depends on preventing unauthorized changes to web delivery paths. |
| DE.CM — Security Continuous Monitoring | Cryptojacking is often detected through abnormal resource use or script behaviour. | |
| RS.AN — Response Analysis | Owners need to determine whether the miner indicates broader compromise. | |
| Recommendation — Restrict who can modify code, content, and deployment paths. Monitor for unusual CPU spikes, script injection, and altered web assets. Investigate the initial access path before removing only the visible mining script. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Cryptojacking on servers is frequently enabled by exposed or reused secrets. |
| NHI-03 — Excessive Privilege and Access | An attacker who plants miners usually benefits from more access than the task requires. | |
| NHI-08 — Third-Party and Supply-Chain Exposure | Injected scripts or vulnerable dependencies can be the entry point for cryptojacking. | |
| Recommendation — Rotate exposed credentials and remove secrets from code, config, and deployment tooling. Reduce privilege on web and deployment identities so compromise cannot easily expand. Review third-party scripts and dependencies that can alter the browser or server execution path. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Cryptojacking commonly uses script execution in web and server contexts. |
| Recommendation — Hunt for unauthorized script execution paths that can load or sustain the miner. | ||
Practitioner Guidance
What to verify: Treat unexpected mining activity as an integrity and exposure check, not just a performance ticket. Confirm whether the script is served from your own assets, from a third-party dependency, or from a tampered server file, because that determines whether you are dealing with simple abuse or a deeper compromise.
Decision rule: If cryptojacking appears on a production site, prioritise containment and source identification before tuning performance or removing the visible script. If the delivery path is unknown, assume the attacker may still have a viable foothold and verify adjacent controls such as administrative access, file integrity, and recent deployment changes.
Practitioner takeaway: The miner is the symptom; the security question is whether someone can still write, inject, or persist code where your site and users trust it.
Related resources from NHI Mgmt Group
- Why do consent notices and site tracking create governance risk even when they do not identify visitors by name?
- Why do exposed cloud credentials create such a fast cryptojacking risk?
- Why do all-site browser permissions create risk for enterprise identity sessions?
- Why do stale code owners create remediation risk in AppSec programmes?