Common indicators include unusual CPU consumption, unexpected outbound connections, modified startup services, and evidence that firewall or host protections were disabled. Defenders should also look for process chains originating from web service activity, suspicious script execution through legitimate binaries, and downloads of attacker-controlled files. When these signals appear together, the server should be treated as actively compromised, not merely misconfigured.
How IIS Exploitation Turns Into Cryptomining Activity
An IIS exploit usually matters because it gives the attacker an execution foothold, not just an initial flaw to patch. Once that foothold exists, cryptominers are commonly deployed as a low-noise payload that can survive for days or weeks if defenders only look for web application symptoms instead of post-exploitation behaviour. The most useful question is whether the server starts behaving like a long-lived compute asset under someone else’s control.
One strong signal is a sustained shift in resource use that does not match the server’s normal web traffic pattern. Mining workloads tend to create flat, persistent CPU pressure, often with intermittent memory or disk activity when the miner updates itself or fetches configuration. That pattern is more meaningful when it appears after a web-facing exploit, because the attacker’s objective is typically to keep the host busy without generating obvious interactive logons or ransomware-style disruption.
Another useful indicator is process lineage. If a miner or dropper is launched from web service activity, spawned through a script engine, or injected into a trusted binary chain, the server is no longer just “slow”, it is executing attacker-directed code through a path that should not exist in routine IIS operation. In practice, that often includes downloaded payloads, encoded command lines, renamed binaries, and abnormal parent-child relationships that begin with the web worker process or a script host.
- Review the process tree from the IIS worker process outward, not just the final miner process name.
- Check for repeated outbound connections to mining pools, proxy infrastructure, or uncommon remote hosts.
- Look for persistence changes such as new services, scheduled tasks, or startup entries created after the exploit window.
- Correlate those events with any security control changes, especially firewall exceptions or disabled endpoint protections.
Risk and Threat Considerations
Cryptomining is often treated as nuisance activity, but on a compromised Windows server it is a reliable indicator that the attacker has achieved enough control to keep returning. The main risk is not only CPU theft, it is the likelihood that the same foothold can be reused for credential access, lateral movement, or follow-on payloads once the attacker has stable execution.
Failure mechanism: The exploit gives the attacker code execution inside the web server context, and the mining payload then uses persistence, outbound connectivity, and control tampering to remain active while blending into normal service behaviour. If defenders focus only on performance degradation, they may miss the broader compromise path.
Impact: Expect service slowdown, degraded availability, higher cloud or power cost, and a much larger attack surface than the miner itself suggests. A server showing mining plus disabled defenses or unusual web-to-script execution should be treated as fully compromised, because the attacker has already demonstrated control of the host.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
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 |
|---|---|---|
| MITRE ATT&CK | T1496 — Resource Hijacking | Cryptomining after exploitation is classic resource hijacking on the host. |
| T1059 — Command and Scripting Interpreter | Web-to-script execution is a common post-exploit path used to launch miners. | |
| T1105 — Ingress Tool Transfer | Attackers commonly download mining binaries and updates after IIS exploitation. | |
| Recommendation — Map mining activity to T1496 and hunt for persistence, pool traffic, and CPU abuse. Inspect script-host execution and encoded commands spawned from the web worker process. Block and alert on attacker-controlled downloads from compromised web servers. | ||
| CIS Controls v8 | CIS 10 — Audit Log Management | Log review is needed to tie IIS exploitation to payload launch and persistence. |
| CIS 5 — Account Management | Attacker persistence often relies on new services, startup entries, or abused accounts. | |
| Recommendation — Centralise and review web, process, and service-change logs for post-exploit activity. Review and remove unexpected service accounts, scheduled tasks, and startup persistence. | ||
| NIST CSF 2.0 | DE.CM — Continuous Monitoring | The answer depends on monitoring CPU, traffic, process lineage, and control tampering. |
| RS.AN — Analysis | Once indicators appear together, the host should be analysed as an active compromise. | |
| Recommendation — Monitor host behaviour continuously for mining-like resource use and protection changes. Analyse correlated host and network indicators as a likely compromise, not a tuning issue. | ||
Practitioner Guidance
What to verify: Confirm whether the CPU spike is paired with new persistence, outbound mining traffic, and control changes. A single noisy process can be a false positive, but the combination of resource abuse, web-originated execution, and tampering with protections is a strong compromise pattern.
Decision rule: If the server is still actively generating miner traffic or you cannot explain the process lineage from an approved deployment change, isolate the host first and investigate later. Waiting for proof of exfiltration is the wrong threshold for a web server that has already shown post-exploit behaviour.
Practitioner takeaway: The key judgement is whether the server is merely unstable or whether it is behaving like an attacker-managed compute node. Once the latter is true, treat the system as a compromise response case, not a tuning or hardening issue.
Related resources from NHI Mgmt Group
- Which controls matter most after a server-side exploit in a shared web platform?
- What are the signs that a path handling flaw is being abused for stealth or impersonation on Windows?
- What are the signs that a public-facing application is being abused after credentials have been stolen?
- What are the signs that a webshell is being used after exploitation of a server vulnerability?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
