Containing C2 and crypto-mining on production servers that couldn't go offline
The situation
Internet-exposed production servers were running at 100% CPU. The usual first moves, isolating the hosts or stopping their services, were constrained by uptime requirements. Whatever we did had to work while the servers kept serving.
Finding it
I baselined process behaviour on the affected servers against a known-good host. The difference stood out: processes presenting themselves as Realtek audio services were running from a temp directory instead of System32. The names looked right. The path did not.
Containment and clean-up
- Deployed CrowdStrike to the affected hosts.
- Extracted binary hashes and validated them against VirusTotal.
- Terminated the malicious services with PowerShell and removed the registry Run-key persistence.
- Blocked the confirmed hashes, plus the wider threat-group IOC set sourced from Group-IB and CTM360.
Choosing a containment control under an uptime constraint
Constraint: The servers had to stay online.
To cut the active command-and-control channel and the XMRig mining traffic, I used a host-based firewall with default-deny egress and an explicit allow-list of business-required ports. Enabling Microsoft Defender was the obvious alternative, but it would have blocked legitimate production processes. The underlying access vector was then remediated.
What is not published
Client identity, host names, file hashes, network details, and the specifics of the access vector are deliberately left out.
What I took from it
- A known-good host is one of the most useful tools in an investigation. Masquerading works on names; it rarely survives a comparison of paths.
- Containment is a design decision. The best control is the one that stops the threat without stopping the business.