Malware News SpankRAT Exploits Windows Explorer Processes for Stealth and Delayed Detection

Brownie2019

Level 23
Thread author
Verified
Well-known
Forum Veteran
Mar 9, 2019
973
4,709
2,168
Germany
A newly identified two-component Remote Access Trojan (RAT) toolkit built in Rust, dubbed SpankRAT, is being used by threat actors to abuse legitimate Windows processes, bypass reputation-based security controls, and maintain persistent access to compromised environments while largely evading detection on VirusTotal.

Researchers at ANY.RUN has identified and analyzed the SpankRAT toolkit, flagging it as a significant stealth threat due to its ability to route C2 traffic through trusted system processes.
Because malicious network activity originates from legitimate Windows binaries, the toolkit can evade reputation-based detection controls and be deprioritized during triage, drastically reducing SOC visibility and increasing the risk of missed compromise.

The SpankLoader: First Stage of Attack
Read more:
 
Read more:
This is a good example of why “trusted process = trusted activity” is a dangerous assumption.

What stands out technically

  • If the report is accurate, the main strength of this RAT is not just the malware itself, but the way it hides its network activity behind legitimate Windows processes.
  • That can reduce visibility for defenders who rely too heavily on process reputation, signed binaries, or basic allowlisting logic.
  • A Rust-based implementation is also notable because Rust malware has become more common in recent years, partly because it can be portable, harder to reverse quickly in some cases, and less familiar to some analysts than older commodity malware families.

Why this matters for defenders

  • Process reputation alone is not enough. A legitimate Windows binary making unusual outbound connections should still be investigated.
  • SOC triage needs to correlate more than just “is the process signed?” It should also look at parent-child process chains, command-line arguments, loaded modules, persistence mechanisms, and destination infrastructure.
  • If C2 traffic is blended into normal-looking system activity, network detection and behavioral baselining become more important than simple static indicators.

Practical detection ideas

  • Monitor legitimate Windows processes for unexpected external connections, especially if those processes do not normally communicate with the internet in that environment.
  • Review unusual parent-child relationships involving system binaries.
  • Check for persistence via scheduled tasks, Run keys, services, WMI, or startup folder abuse.
  • Use EDR telemetry to look for process injection, hollowing, or suspicious handle/module activity if your tooling supports that level of visibility.
  • Hunt for systems where signed Microsoft binaries show rare or first-seen network behavior.

A caution on the article

I would treat the news write-up as a secondary source, not as final proof of every claim. For technical confidence, the strongest reference is the original research from ANY.RUN or additional independent analysis. Detection claims such as “largely evading detection on VirusTotal” can also change quickly over time, so they should not be treated as permanent facts.

Bottom line

If this campaign analysis holds up, the real lesson is that defenders need behavior-based detection instead of trusting process reputation by default. Legitimate binaries can still be part of malicious execution chains, and that is exactly the kind of activity that can slip past shallow triage.
 
From the article, it follows that the infection chain is as follows:
SpankLoader ---> PowerShell (C2 command execution) ---> DLL payload downloaded/converted/injected into benign Explorer process ---> ...

As in many such attacks, the above PowerShell C2 command execution uses advanced PowerShell functionality that is blocked in Constrained Language Mode. In this way, the attack could be fully mitigated (to support AV), even after the successful execution of the initial first-stage loader (SpankLoader).
Another effective mitigation could be blocking the outbound connections of PowerShell.