Attackers often scan for known vulnerabilities that remain unpatched long after disclosure, then use the compromised web application to run unauthorized mining code. The issue is not novelty but persistence in patch gaps and exposed application surfaces. Teams should prioritize patch hygiene, web app monitoring, and configuration review because stale weaknesses remain highly profitable targets for opportunistic abuse.
How stale web application flaws turn into mining infrastructure
Old vulnerabilities are attractive because they are predictable, repeatable, and easy to find at scale. Attackers do not need a novel exploit when a forgotten flaw still exposes a shell, upload path, command injection point, or remote code execution route. In practice, the web application becomes a free compute host once the attacker can execute a miner, alter startup scripts, or stage a persistence mechanism.
The most common pattern is opportunistic abuse of unfinished patching and weak asset visibility. A vulnerable page, framework component, or plugin sits exposed long enough for scanning infrastructure to detect it, and the attacker converts that foothold into unauthorized resource consumption. For a broader view of how unpatched weaknesses map to real compromise paths, see OWASP Top 10 and the CISA Known Exploited Vulnerabilities Catalog.
Once inside, attackers usually prefer low-noise execution. Web-facing compromise gives them a process already allowed to run, network reach to fetch payloads, and enough discretion to blend miner traffic with normal application behavior. That is why stale flaws remain profitable long after disclosure: the exploit is old, but the target is still reachable.
For a concrete example of how public web-facing weaknesses can become code execution and broader abuse, NHIMG’s ASP.NET machine keys RCE attack shows how exposed application material can be converted into direct execution. NHIMG’s 52 NHI Breaches Analysis also illustrates how compromised access material often becomes the bridge from initial foothold to broader abuse.
Why cryptojacking survives in web apps even after the flaw is known
Cryptojacking is not usually a single-step event. Attackers often chain the original flaw with weak hardening, permissive runtime settings, exposed admin surfaces, or poor segmentation. That combination lets them keep mining even if the original entry point is later discovered, because persistence has already been established elsewhere in the application stack.
The operational cost to defenders is also asymmetrical. A miner can consume CPU, inflate cloud bills, trigger performance degradation, and obscure other malicious activity without immediately breaking the application. That makes cryptojacking a useful abuse case for opportunistic actors: the compromise can remain active while the business attributes symptoms to load, misconfiguration, or an ordinary capacity spike.
Old vulnerabilities are especially effective in web environments that mix frequent change with inconsistent ownership. If patching, deployment, and runtime review are split across teams, attackers only need one exposed interface to convert the application into mining infrastructure. The problem is less about the age of the CVE than the persistence of the exposure surface.
Industry guidance for exposure-driven abuse is consistent: if a flaw is known to be exploited in the wild, treat it as an active risk even when the application appears stable. The CISA cyber threat advisories and the NIST Cybersecurity Framework 2.0 both support a posture that emphasizes exposure reduction, detection, and recovery rather than assuming obscurity or delay will protect the asset.
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 NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Web app cryptojacking often starts with abused secrets or exposed runtime material. |
| NHI-03 — Privilege and Access Scope | Attackers profit when a web app can execute beyond the minimum needed for service operation. | |
| Recommendation — Rotate exposed secrets quickly and remove long-lived credentials from web workloads. Reduce execution scope so compromised apps cannot freely spawn miners or persist tooling. | ||
| NIST CSF 2.0 | PR.IP — Information Protection Processes and Procedures | Patch hygiene and configuration review are core exposure-reduction practices for known web flaws. |
| DE.CM — Continuous Monitoring | Cryptojacking is often detected through abnormal resource use and process activity. | |
| Recommendation — Enforce timely patching and configuration review for externally exposed applications. Monitor application runtime, resource consumption, and outbound behavior for abuse indicators. | ||
| CIS Controls v8 | 7 — Continuous Vulnerability Management | The question centers on old vulnerabilities remaining exploitable long after disclosure. |
| 8 — Audit Log Management | Mining activity is easier to confirm when web app and host logs are retained and reviewed. | |
| Recommendation — Continuously identify and remediate exposed weaknesses before attackers can reuse them. Collect and review logs that can reveal unusual execution, persistence, or outbound mining traffic. | ||
| MITRE ATT&CK | T1496 — Resource Hijacking | Cryptojacking is a direct example of adversary resource hijacking for unauthorized mining. |
| Recommendation — Detect and disrupt unauthorized compute consumption consistent with resource-hijacking behavior. | ||
Practitioner Guidance
What to prioritise: Start with internet-facing applications that have long patch tails, legacy plugins, and weak asset ownership. Those are the systems most likely to be mined silently because the attacker can reuse a public exploit path instead of developing a new one.
What to verify: Confirm that patch status is tied to an actual exposure inventory, not just a ticket queue. The key question is whether the vulnerable component is still reachable from outside the trusted network and whether the application can execute unexpected processes or outbound connections.
Common mistake: Teams often look for visible service disruption before investigating. Cryptojacking usually presents first as resource drift, noisy bills, or degraded response times, so monitoring needs to catch abnormal compute use and suspicious web process behavior before the workload is visibly failing.
Practitioner takeaway: Old vulnerabilities become mining infrastructure when exposure persists after disclosure, so the control objective is fast removal of reachable weaknesses plus enough runtime visibility to catch abuse before the attacker turns your application into a stable compute host.
Related resources from NHI Mgmt Group
- How should security teams use DAST to find runtime web application vulnerabilities before attackers do?
- Why do passwords remain dangerous when attackers use AI to find vulnerabilities?
- How should security teams validate web applications when attackers often start there too?
- How should security teams validate web applications that use OAuth 2.0 or SSO without breaking the user experience?
