highStealer

XWorm v6.4 via Go Loader and ScrubCrypt: A 13-Month Multi-RAT Operator Who Forgot to Move

PublishedMarch 12, 2026

Threat Actors:ProfileAssessmentTimelineregisters domain-based C2

stealerxwormsocial-engineeringcredential-theftc2apt

TL;DR: A 3.5MB executable tagged as XWorm on MalwareBazaar turned out to be something considerably more interesting than a standard .NET RAT -- it is a Go-based loader compiled from a temp file on a Windows ADMINISTRATOR account that drops a ScrubCrypt-obfuscated batch script, which in turn extracts and detonates XWorm v6.4. The three-stage chain (Go binary to PowerShell to ScrubCrypt batch to .NET RAT) is designed to defeat detection pipelines that focus on .NET loaders, and it largely succeeds. But the operator behind it has been running the same C2 IP -- 204[.]10[.]160[.]190 on a Heymman Servers VPS in Canada -- for over 13 months across at least two RAT families (Remcos, then XWorm), with exposed RDP, SMB, and WinRM on the C2 box, and a server still vulnerable to CVE-2020-0796. The sophistication is in the delivery. The discipline is not.

A Go Binary That Should Not Exist

XWorm is a .NET RAT. Its builder outputs .NET executables. Its ecosystem -- loaders, crypters, stagers -- overwhelmingly lives in the .NET and PowerShell world. So when a 3.5MB PE64 console application tagged as XWorm appeared on MalwareBazaar on March 9, 2026, the first question was not "what does it do" but "why is it compiled in Go?"

The answer, after pulling the binary apart, is that someone has built -- or acquired -- a Go-based loader framework that wraps commodity RAT payloads in a language that most Windows-focused detection stacks are not optimized for. .NET analysis tools like dnSpy and ILSpy are useless here. YARA rules hunting for .NET metadata will never fire. The Go runtime itself brings 3MB of legitimate library code along for the ride, diluting any malicious signal in entropy and string analysis. It is a simple but effective evasion strategy: deliver the payload in a language the defenders are not expecting.

And the build artifacts tell us something else. The source was compiled from C:\Users\ADMINI~1\AppData\Local\Temp\2\tmpsjk5pxof.go -- a temporary file with a random name, on a machine logged in as ADMINISTRATOR. This is not a developer carefully managing source code. This is an automated builder: feed in a payload, get back an obfuscated Go executable, delete the source. The function names confirm it -- main.V0RItosZlbN, main.VRanbd8cq28RGC, main.bmH5hXGEvhxg -- random strings that survive compilation as Go symbols but carry no semantic meaning.

Attribute	Value
SHA-256	`109b233024348f26571c086aa6aae6eeedb062a704b4a23e0d87dd2234659103`
MD5	`1ca66f5770cff04b03e200aab601cdb8`
SHA-1	`f6ac1b40817dae7058cfec365974e03ea68538e9`
Imphash	`d42595b695fc008ef2c56aabd8efd68e`
File Type	PE32+ executable (console) x86-64
Size	3,564,544 bytes (3.5 MB)
Language	Go 1.25.6
Build Path	`C:\Users\ADMINI~1\AppData\Local\Temp\2\tmpsjk5pxof.go`
Compilation	Timestamp zeroed (anti-forensics)
Signed	No

The zeroed compilation timestamp is a deliberate anti-forensic choice. Go binaries normally carry a build timestamp that can place them in a campaign timeline. This operator -- or more likely, the builder tool they are using -- strips that before output.

Stage 1: The Go Loader Unpacks

When executed, the Go binary performs a straightforward but effective two-step:

Decodes a base64-encoded blob embedded in the binary
Writes the result -- a ScrubCrypt batch script -- to %temp%
Launches it via hidden PowerShell

The execution command tells you everything about the operator's priorities:

cd %temp% & powershell.exe -WindowStyle Hidden -ExecutionPolicy Bypass -Command "Start-Process -FilePath ..."

-WindowStyle Hidden prevents any visible window. -ExecutionPolicy Bypass disables PowerShell script controls. The cd %temp% ensures the batch script runs from a writable location where temporary files are expected and often ignored by monitoring.

But the Go binary is not just a dumb dropper. The import table reveals capabilities that go well beyond file writing:

crypto/aes, crypto/tls, crypto/rsa, crypto/x509 -- encrypted communications
archive/zip, archive/tar -- archive handling (payload extraction?)
main.memoryStatusEx -- memory enumeration, likely for sandbox detection
syscall.CreateProcessAsUser -- process creation with alternate tokens
syscall.RegOpenKeyExW -- registry access

Not all of these capabilities are exercised in this sample's execution path. Some may be vestigial -- artifacts of a general-purpose loader framework that supports features this particular payload does not need. But the sandbox detection via memoryStatusEx is almost certainly active: checking available RAM is a classic technique for identifying analysis environments, which typically allocate minimal memory to VMs.

Stage 2: ScrubCrypt Does What ScrubCrypt Does

The batch script dropped by the Go loader is a ScrubCrypt variant -- a commercially available crypter-as-a-service that has been a fixture in the commodity malware ecosystem since 2023. But this is not the ScrubCrypt you may have seen in previous reporting.

Attribute	Value
Size	231,880 bytes (27,439 text + 204,441 binary payload)
Lines	493
SET Variables	48 (random names, random values)
Obfuscation	Variable substitution, random labels, junk comments, mixed case

Earlier ScrubCrypt variants were identifiable by their use of certutil for base64 decoding, findstr for string extraction, and more +N for line skipping. This variant avoids all three. Instead, it uses a technique built around environment variable manipulation and self-referencing:

73+ unique environment variables assembled in a single command line
Self-reads via %~f0 -- the batch script reads its own file to extract the binary payload appended after the text section
Random-case commands -- sEt, GoTo, iF, ecHO -- to defeat case-sensitive string matching
Dead-code REM comments between every operational line, adding noise without changing behavior

The 204KB binary payload appended after the batch text is the encrypted XWorm .NET assembly. ScrubCrypt extracts it using its environment variable machinery, decrypts it, and loads it into memory.

This evolution matters for defenders. If your ScrubCrypt detection rules rely on certutil or findstr invocations, this variant walks right past them. The detection pivot should be behavioral: a batch script that reads its own file path via %~f0 while setting dozens of environment variables in rapid succession is not normal Windows behavior.

Stage 3: XWorm v6.4 Arrives

Once ScrubCrypt finishes its work, the final payload is a straightforward XWorm v6.4 .NET RAT. The configuration, extracted via sandbox analysis, is clean and readable:

Attribute	Value
Version	XWorm v6.4
C2 Host	`204[.]10[.]160[.]190`
C2 Port	`7003`
Protocol	TCP (custom XWorm protocol, AES-encrypted)
Mutex	`Cqu1F0NxohroKG5U`
Install Name	`USB.exe`
Encryption	AES (plain key)

XWorm v6.4 is commodity crimeware with a well-documented feature set: remote access, credential theft, keylogging, clipboard monitoring, and -- notably -- USB spreading. The USB.exe install name is not cosmetic. XWorm copies itself to removable media as USB.exe and creates autorun entries, turning every infected machine into a potential propagation vector for air-gapped or segmented networks.

The persistence mechanisms are standard for XWorm: startup folder entries, scheduled tasks, and registry run keys. The C2 protocol uses AES encryption over raw TCP on port 7003 -- a non-standard port that will stand out in network traffic analysis but may slip through firewalls that only inspect HTTP/HTTPS.

The Full Kill Chain

[INITIAL ACCESS]           [EXECUTION]                    [PERSISTENCE]          [C2]

Go Loader (3.5MB PE64)     PowerShell (hidden, bypass)    Startup Folder         XWorm C2
109b2330...                    |                          Scheduled Tasks        204.10.160.190:7003
    |                          v                          Registry Run Keys      AES-encrypted TCP
    |                     ScrubCrypt Batch (493 lines)         |
    +-- base64 decode         |                                |
    +-- write to %temp%       +-- 73+ env vars                 +-- USB.exe (removable media)
    +-- sandbox check         +-- self-read via %~f0
         (memoryStatusEx)     +-- extract 204KB payload
                              +-- decrypt & load .NET
                                    |
                                    v
                              XWorm v6.4 (.NET RAT)
                              Mutex: Cqu1F0NxohroKG5U

Three stages, three languages (Go, Batch/PowerShell, .NET), three different detection surfaces. A .NET-focused detection pipeline sees nothing until Stage 3. A Go-focused pipeline (rare in most SOCs) might catch Stage 1 but lacks context for what comes next. The ScrubCrypt batch sits in the gap between both -- too scripted for binary analysis, too obfuscated for simple string matching.

What Was Found vs. What Was Known

Aspect	Prior Reporting	Our Findings
Sample type	Tagged as XWorm .NET executable	Go-based loader with embedded ScrubCrypt batch
Delivery chain	Unknown	Go binary -> PowerShell -> ScrubCrypt -> XWorm .NET
C2	Not documented for this sample	`204[.]10[.]160[.]190:7003` (confirmed via campaign linking)
Actor history	Unknown	Same IP ran Remcos RAT since February 2025
Builder	Unknown	Automated Go builder (temp file compilation, obfuscated function names)
Campaign scope	Single sample	3+ related samples across Go, JavaScript, and VBS delivery formats
Infrastructure	Unknown	Heymman Servers VPS with exposed RDP/SMB/WinRM, vulnerable to CVE-2020-0796

The MalwareBazaar tag said "XWorm." The binary said "Go." The infrastructure said "13 months of uninterrupted operation." None of that was documented before this analysis.

Infrastructure: 13 Months on the Same IP

This is the part of the investigation where the operator's sophistication at the delivery layer collides head-on with their infrastructure discipline -- or lack of it.

The C2 server at 204[.]10[.]160[.]190 is a Windows VPS hosted by Heymman Servers Corporation in Thornhill, Ontario, Canada. It sits inside the 204[.]10[.]160[.]0/22 CIDR block (HEYMMAN-2), sub-allocated to DreamHosting, Inc.

Hosting Details

Attribute	Value
Provider	Heymman Servers Corporation
CIDR	`204[.]10[.]160[.]0/22` (HEYMMAN-2)
Sub-allocation	DreamHosting, Inc. (`204.10.160.0 - 204.10.160.63`)
Address	800 Steeles Ave W, #B10182, Thornhill, ON L4J 7L2, Canada
Abuse Contact	`contact@heymman[.]com`

The server exposes far more than it should:

Port	Service	Implication
135	RPC	Windows service enumeration
445	SMB	File sharing, lateral movement vector
3389	RDP	Remote desktop -- the operator's management interface
5357	WSDAPI	Web Services for Devices
5985	WinRM	PowerShell remoting
7003	XWorm C2	The payload's command and control channel

This is a C2 server with its management plane fully exposed to the internet. RDP, SMB, and WinRM are open. The server is reportedly vulnerable to CVE-2020-0796 (SMBGhost) -- a critical remote code execution vulnerability in SMBv3 that Microsoft patched in March 2020. Six years later, this server still has not been updated.

The adjacent IPs tell the same story:

IP	Ports	Notes
`204[.]10[.]160[.]189`	3389	Windows VPS, RDP exposed
`204[.]10[.]160[.]190`	135, 445, 3389, 5357, 5985, 7003	This C2 server
`204[.]10[.]160[.]191`	137, 3389, 5985	Windows VPS, end-of-life OS
`204[.]10[.]160[.]192`	3389, 5357, 5985	Windows VPS, RDP exposed

Four consecutive IPs, all Windows VPSes, all with RDP exposed. This looks like a hosting provider that provisions insecure-by-default Windows servers and an operator (or operators) who never bothered to lock them down. The .191 box is running an end-of-life Windows version -- the neighborhood is not improving.

The Timeline That Tells a Story

The most damaging finding is not a single sample but a timeline. Cross-referencing MalwareBazaar submissions and ThreatFox C2 reports against 204[.]10[.]160[.]190 reveals over a year of continuous malware operations:

Date	Malware	Port	Reference
2025-02-20	Remcos RAT (via GuLoader)	2404	`a32a27ce...`
2025-10-08	Remcos RAT (last seen)	2404	ThreatFox
2026-01-22	XWorm v6.4 + MassLogger	7003	`2310a8c9...`
2026-03-09	XWorm v6.4 (JS dropper)	7003	`c07ac71d...`
2026-03-09	XWorm v6.4 (Go loader)	7003	`109b2330...` this sample

February 2025: the operator deploys Remcos RAT, delivered via GuLoader, communicating on port 2404. Remcos is a well-known remote administration tool that straddles the line between legitimate use and cybercrime -- but delivered via GuLoader through a bulletproof hosting provider, there is no ambiguity here.

Remcos runs for eight months. Then, sometime between October 2025 and January 2026, the operator switches to XWorm v6.4 on port 7003. The IP stays the same. The hosting provider stays the same. Only the tool changes.

This is a pattern we see repeatedly in mid-tier cybercrime: operators upgrade their RAT tooling every 6-12 months, moving to whatever builder has the best feature-to-price ratio on underground forums, but they never rotate their infrastructure because renting new VPS boxes costs money and requires setup time. The C2 IP becomes a single thread that, once pulled, unravels the entire operation.

The addition of MassLogger alongside XWorm in January 2026 suggests the operator is running multiple infostealer campaigns simultaneously -- XWorm for persistent access and MassLogger for credential harvesting. Different tools, same server, same operator.

Campaign Scale: Not Just One Loader

The Go binary is not an isolated sample. Within 48 hours of its appearance, at least two other delivery formats targeting the same C2 infrastructure surfaced:

SHA-256	Type	Size	Date	Delivery Method
`109b233024...`	PE (Go)	3.5 MB	2026-03-09	Go loader (this analysis)
`c07ac71d6d...`	JavaScript	3.4 MB	2026-03-09	JS dropper (`CBMINV 14453.js`)
`2310a8c9c8...`	JavaScript	78 KB	2026-01-22	JS dropper (earlier campaign wave)
`a32a27ceef...`	PE	--	2025-02-20	GuLoader -> Remcos (same IP, different RAT)

The JavaScript dropper CBMINV 14453.js is particularly interesting. The filename follows a pattern consistent with invoice-themed social engineering ("CBMINV" = "CBM Invoice"?), and at 3.4MB it is suspiciously close in size to the Go loader. The January JavaScript sample at 78KB is much smaller -- suggesting the operator may have shifted to embedding the full ScrubCrypt payload inline rather than downloading it, trading stealth for reliability.

Three delivery formats (Go, JavaScript, VBS) targeting the same C2 within the same campaign window. This operator is not loyal to a single delivery mechanism -- they are testing multiple vectors in parallel, likely measuring which ones achieve the best execution rates against their target demographic.

Threat Actor Profile

Attribution Assessment

Confidence: MEDIUM
Motivation: Financial (credential theft, data exfiltration, persistent access)
Sophistication: Intermediate -- commodity RATs with a novel Go-based delivery chain
Persistence: 13+ months of continuous operation from the same infrastructure

The Contradictions

This operator's profile is a case study in uneven tradecraft.

What they do well:

Built or acquired a Go-based loader framework that bypasses .NET-focused detection
Use ScrubCrypt variants that avoid known detection signatures
Deploy multiple delivery formats in parallel (Go, JS, VBS)
Employ sandbox detection via memory enumeration
Zero compilation timestamps to frustrate forensic timelining

What they do poorly:

Same C2 IP for 13+ months with no rotation
Build path exposes ADMINISTRATOR account and temp file naming (tmpsjk5pxof.go)
C2 server has RDP, SMB, and WinRM exposed to the internet
C2 server is vulnerable to CVE-2020-0796 -- a six-year-old critical vulnerability
Adjacent IPs in the same /24 show the same sloppy configuration

The build path is the most operationally useful leak. The tmpsjk5pxof.go filename is characteristic of Python's tempfile module (the tmp prefix followed by random characters). If the builder is a Python tool that generates Go source, compiles it, and deletes the source, then the temp file naming convention becomes a fingerprint for identifying other samples produced by the same builder -- even if the output binaries look different.

MITRE ATT&CK Mapping

Tactic	Technique	ID	Implementation
Execution	Command and Scripting Interpreter: PowerShell	T1059.001	Hidden PowerShell executes ScrubCrypt batch dropper
Execution	Command and Scripting Interpreter: Windows Command Shell	T1059.003	ScrubCrypt batch script with 493 lines of obfuscated commands
Defense Evasion	Obfuscated Files or Information	T1027	Three-layer obfuscation: Go -> base64 -> ScrubCrypt
Defense Evasion	Masquerading	T1036	Go binary disguised as generic executable; .NET RAT hidden inside batch
Defense Evasion	Deobfuscate/Decode Files or Information	T1140	Base64 decode of embedded batch; ScrubCrypt decryption of .NET payload
Defense Evasion	Virtualization/Sandbox Evasion: System Checks	T1497.001	`main.memoryStatusEx` for RAM-based sandbox detection
Persistence	Boot or Logon Autostart Execution: Registry Run Keys	T1547.001	XWorm persistence via startup, scheduled tasks, registry keys
Lateral Movement	Replication Through Removable Media	T1091	XWorm installs as `USB.exe` on removable drives
Command and Control	Application Layer Protocol	T1071	Custom AES-encrypted TCP protocol on port 7003
Collection	Input Capture: Keylogging	T1056.001	XWorm keylogger module
Collection	Clipboard Data	T1115	XWorm clipboard monitoring
Credential Access	Credentials from Password Stores	T1555	XWorm stealer capabilities
Discovery	System Information Discovery	T1082	Memory status enumeration for sandbox detection

Indicators of Compromise

File Indicators

# Go Loader (Stage 1) -- THIS SAMPLE
SHA256: 109b233024348f26571c086aa6aae6eeedb062a704b4a23e0d87dd2234659103
MD5:    1ca66f5770cff04b03e200aab601cdb8
SHA1:   f6ac1b40817dae7058cfec365974e03ea68538e9
Imphash: d42595b695fc008ef2c56aabd8efd68e

# Encrypted Inner Payload (extracted from ScrubCrypt)
SHA256: d671ba6b905fe06af35413065a09f73ffc6078f0716f07e410afee6f5806ad26

# Related JS Dropper (same C2, same day)
SHA256: c07ac71d6daf7d2fb45a66e96713770cf755c3e8b8f96a260d50ee5afa8aac1d

# Earlier XWorm JS Dropper (same C2, January 2026)
SHA256: 2310a8c9c8c8d27053e63afc6ab66e1b2143e36c9e347368850eab5ba7b9dacf

# Historical Remcos Sample (same C2 IP, February 2025)
SHA256: a32a27ceefc724f43ae4b66df898b2f659df2e5b1c7ce819d9667846093814e6

Network Indicators

# C2 IP (defanged)
204[.]10[.]160[.]190

# C2 Port
7003/tcp (XWorm, active since January 2026)
2404/tcp (Remcos, active February - October 2025)

# Adjacent infrastructure (same /24, same provider)
204[.]10[.]160[.]189
204[.]10[.]160[.]191
204[.]10[.]160[.]192

Behavioral Indicators

# XWorm Mutex
Cqu1F0NxohroKG5U

# XWorm Install Name (USB spreading)
USB.exe

# Go Builder Fingerprint
Build path: C:\Users\ADMINI~1\AppData\Local\Temp\2\tmpsjk5pxof.go
Build ID:   x-yGvYwiIJr76R_ZXNAA/pq8ji525ftmjH0kdh-39/lC9FQEN3P-FRauXaWhJ-/o-7TOPJfGdGg_ailDGVi

# Obfuscated Go Function Names
main.V0RItosZlbN
main.VRanbd8cq28RGC
main.Y9dgSZxw9Ie
main.ZPFxSmvHI2
main.bmH5hXGEvhxg
main.oh8uTMgA2DZb
main.rrKAIy6w

# Dropper Execution Pattern
cd %temp% & powershell.exe -WindowStyle Hidden -ExecutionPolicy Bypass -Command "Start-Process -FilePath ..."

Detection Guidance

Immediate (24-48 hours)

Block C2 IP 204[.]10[.]160[.]190 on all egress firewalls and proxy infrastructure
Deploy the imphash d42595b695fc008ef2c56aabd8efd68e to EDR and file scanning platforms
Search EDR telemetry for the mutex Cqu1F0NxohroKG5U via handle or named object queries
Hunt for Go binaries (PE64, large filesize, go.buildid section) spawning PowerShell with -WindowStyle Hidden from %temp%
Alert on any process named USB.exe appearing on removable media volumes

Short-term (1-2 weeks)

Search network logs for historical connections to 204[.]10[.]160[.]190 on any port -- connections to port 2404 would indicate Remcos compromise from an earlier campaign wave
Monitor PowerShell Script Block Logging for batch scripts using %~f0 self-referencing combined with rapid SET variable creation (ScrubCrypt behavioral pattern)
Deploy YARA rules keyed on the Go Build ID and obfuscated function name patterns
Review any hosts with scheduled tasks or startup entries referencing USB.exe

Medium-term (1-3 months)

Build behavioral detection for Go PE64 binaries that write .bat or .cmd files to %temp% and immediately execute them via PowerShell
Monitor the Heymman Servers 204[.]10[.]160[.]0/22 range for new C2 activity -- this operator has demonstrated loyalty to the provider
Track XWorm v6.4 delivery chain evolution -- the shift from JS to Go suggests the operator is actively experimenting with new loader frameworks
Consider DNS sinkholing if the actor registers domain-based C2 infrastructure (currently IP-only, but the Remcos-to-XWorm transition may coincide with a move to domains)

References

MalwareBazaar: 109b2330...
ThreatFox XWorm C2: IOC 1735722
ThreatFox Remcos C2: IOC 1428120
CAPE Sandbox: Analysis 56858
Triage (related sample): 260309-pvr36acs3v
Malpedia XWorm: win.xworm
Malpedia Remcos: win.remcos

Published by Breakglass Intelligence. Investigation conducted 2026-03-10. 3 stages dissected. 5 file hashes extracted. 13 months of C2 infrastructure mapped. 1 operator who built a Go loader but forgot to patch SMBGhost. Classification: TLP:CLEAR