Teams often delete the malicious script and stop there, but that leaves the underlying compromise unresolved. A safer response is to restore clean code from a known good backup or redeploy fresh source, review server logs for the intrusion path, and then fix the vulnerability that enabled the injection. If the entry point remains open, the attacker can return.
What teams miss after they remove the cryptojacker
Deleting the malicious snippet is only the first visible step. If the site is still vulnerable, the attacker can reinject code, swap in a different payload, or reuse the same foothold later. The real question is whether the compromise was contained, the entry path understood, and the affected code or infrastructure rebuilt from a trusted baseline.
In practice, cryptojacking on a website is often a symptom of broader compromise, not the whole incident. That means the response has to extend beyond script cleanup to source integrity, access review, log analysis, and vulnerability remediation. Otherwise, the removal is temporary and the attacker retains a path back in.
What a complete cleanup actually needs
A sound response starts with restoring the site from a known good backup or redeploying clean source, not editing the infected page in place. Teams should then inspect logs for the initial intrusion path, confirm which files or components were altered, and identify whether the attacker used stolen credentials, a vulnerable plugin, an exposed admin interface, or another weak control.
That review matters because cryptojacking code is usually easy to replace but hard to prevent if the root cause remains. If the compromise touched server-side files, deployment pipelines, or reusable credentials, the cleanup must include rotation or revocation of any secrets that could still provide access. NHIMG’s Guide to the Secret Sprawl Challenge is useful here because it ties hardcoded credentials and secret exposure to practical remediation choices.
Where the intrusion path is unclear, teams should treat the environment as only partially trusted until they can prove otherwise. That usually means checking for other injected code, persistence mechanisms, and unauthorised changes beyond the one script that was discovered. A single visible cryptojminer can mask a broader webshell, credential theft, or CMS compromise.
Why partial removal keeps the attacker in play
The core failure is assuming that the malicious script is the problem rather than the attacker-controlled access that delivered it. If the underlying weakness is still live, the same account, exploit, or upload mechanism can be used again immediately. That is why “delete and move on” often produces repeated reinfection instead of recovery.
For teams that need a reference point on what compromise patterns look like in the wild, NHIMG’s 52 NHI Breaches Report and the companion 52 NHI Breaches Analysis both reinforce a broader lesson: once access paths and credentials are exposed, attackers tend to reuse them unless the environment is rebuilt or locked down.
That is also why source restoration is better than manual surgery on a live compromised site. Manual removal can leave hidden fragments, modified includes, or corrupted templates behind. A known-good redeploy narrows the chance that the cleanup itself becomes another blind spot.
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 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 Control 16 — Application Software Security | Cryptojacking on a site usually exploits web-app weaknesses or tampering paths. |
| CIS Control 8 — Audit Log Management | The answer depends on reviewing logs to identify the intrusion path and scope. | |
| CIS Control 5 — Account Management | If credentials or admin access were abused, account cleanup and rotation become part of recovery. | |
| Recommendation — Harden the application and close the injection path that enabled the malicious script. Review and retain logs to trace the compromise and confirm what was altered. Revoke or rotate any accounts and secrets that could still be used to reinfect the site. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions Are Managed | Preventing reinfection requires closing the access path, not just deleting payload code. |
| DE.CM-7 — Monitoring for Unauthorized Personnel, Connections, Devices and Software | Log review and integrity checks are central to finding the compromise source and hidden changes. | |
| RC.RP-1 — Recovery Plan Is Executed During or After an Incident | The answer emphasizes restoring clean code and rebuilding from trusted sources. | |
| Recommendation — Tighten permissions so the compromised path cannot be reused. Use monitoring and log review to detect additional malicious changes and persistence. Execute recovery by redeploying trusted code rather than editing the compromised site in place. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secret Sprawl | Cryptojacking often follows exposed credentials or hardcoded secrets used to reach the site. |
| NHI-04 — Overprivileged Non-Human Identities | A compromised deployment or service credential can let attackers reinject code repeatedly. | |
| NHI-10 — Incomplete Offboarding | Recovery depends on revoking access that should no longer be valid after compromise. | |
| Recommendation — Find and remove exposed secrets that could have enabled the compromise. Reduce excessive access so a stolen credential cannot keep modifying the site. Revoke stale or abused access paths during incident cleanup. | ||
Practitioner Guidance
What to prioritise: Restore the site to a trusted state first, then investigate how the code was injected. If you cannot explain the entry point, you do not yet have a complete cleanup.
What to verify: Confirm that the vulnerable path is closed, affected credentials are rotated or revoked, and no other files, themes, plugins, or deployment artifacts were altered. Evidence of one deleted script is not evidence of recovery.
Common mistake: Treating visible malware removal as incident closure. For web compromise, the operational win is not “the script is gone”, it is “the attacker can no longer return through the same path.”
Practitioner takeaway: The decisive step is not removal alone, it is eliminating the attacker’s original access route and restoring trust in the codebase, so reinfection becomes materially harder.
Related resources from NHI Mgmt Group
- What do teams get wrong about protecting source code from malicious insiders and compromised developer accounts?
- What do teams get wrong about removing secrets from source code after a leak is found?
- What do security teams get wrong about secrets in third-party code and integrations?
- What do security teams get wrong about trusting code repositories?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
