Novel fake CAPTCHA chain delivering Amatera Stealer

Last updated: October 7, 2026

Key Takeaways

• A fake CAPTCHA (ClickFix-style) lure tricks users into running a command themselves, so the attack starts with user action rather than an exploited vulnerability.
• The campaign hides inside trusted components and services, including a signed Microsoft script, a public Google Calendar, and image files, to avoid drawing attention.
• Multiple execution gates mean the chain only runs on enterprise-managed Windows and quietly stalls in sandboxes, making it harder to detect and analyze.
• The payload, Amatera Stealer (formerly ACRStealer), is familiar. The delivery chain built around it is what makes this campaign notable.
• The defenses that matter most: restrict the Run dialog, enable PowerShell logging, and watch for suspicious script-host process lineage.

How the Amatera Fake CAPTCHA Campaign Works

The Blackpoint Cyber Security Operations Center (SOC) has identified a new Fake CAPTCHA campaign that leverages a signed Microsoft Application Virtualization (App-V) script, SyncAppvPublishingServer.vbs, as a LOLBIN to proxy execution through a legitimate Windows component. Instead of launching PowerShell directly, the attacker uses this script to control how execution begins and to avoid more common, easily recognized execution paths.

Execution Gates Control the Attack Flow

Early stages are designed to validate execution order and user behavior rather than exploit a vulnerability. Progression is gated on conditions established during the initial interaction, and when those expectations are not met, execution quietly stalls. This reinforces that the delivery flow itself is a core part of the attack, not just a means to reach the final payload.

A Delivery Chain Built to Stay Hidden

As the chain progresses through several additional in-memory stages, it makes two notable pivots. First, it pulls live configuration from a public Google Calendar file, an example of attackers living off someone else’s infrastructure to keep delivery logic flexible. Later, it uses PNG-based steganography to deliver an encrypted payload hidden inside an image, which is extracted and executed entirely in memory.

What Is Amatera Stealer?

Amatera Stealer, formerly known as ACRStealer, is an information-stealing malware family designed to collect sensitive information from compromised systems. In this campaign, it serves as the final payload after the earlier stages have established the conditions for execution and delivered the encrypted malware.

The payload itself is not the most notable part of this campaign. The delivery chain surrounding it combines signed Microsoft components, user-based execution gates, third-party infrastructure, and in-memory execution to make the activity harder to detect and analyze.

Key Findings: The Amatera Fake CAPTCHA Campaign

• The campaign uses a Fake CAPTCHA lure, proxying execution through the signed App-V script SyncAppvPublishingServer.vbs.
• Early stages verify user interaction and execution order using environment and clipboard state, stalling execution when those checks fail.
• Subsequent PowerShell stages rely on alias and wildcard abuse to dynamically resolve sensitive cmdlets at runtime.
• Configuration for later stages is pulled from a public Google Calendar (.ics) file, allowing delivery logic to be updated without redeploying earlier stages.
• Payload delivery later in the chain uses PNG-based steganography, with encrypted PowerShell content embedded inside image files.
• The embedded payload is extracted, decrypted, and decompressed entirely in memory before execution transitions from PowerShell into native shellcode.
• The final payload delivered is Amatera Stealer, an information-stealing malware family commonly used to harvest browser data and credentials.

The Amatera Fake CAPTCHA Kill Chain at a Glance

The full chain, from the fake CAPTCHA prompt to Amatera’s C2, is summarized below before each stage is broken down.

Stage 1: Initial Access via Fake CAPTCHA & a Signed App-V Script

The chain starts with a fake CAPTCHA prompt that tricks the user into running a command, then hides execution inside a trusted Microsoft script.

The Fake CAPTCHA Lure

The infection chain begins with a Fake CAPTCHA social engineering prompt, a technique that has become increasingly common over the past year. The user is instructed to manually paste and execute a command via the Run dialog, framed as a required step to complete a human verification check (Figure 2).

Abusing SyncAppvPublishingServer.vbs as a LOLBIN

Instead of invoking PowerShell directly, the supplied command abuses SyncAppvPublishingServer.vbs, a signed Microsoft script associated with Application Virtualization (App-V). Under normal conditions, this script is used to publish and manage virtualized enterprise applications. In this campaign, it serves as a LOLBIN, allowing the attacker to proxy PowerShell execution through a trusted Microsoft component.

Execution is initiated via wscript.exe, altering the process ancestry from the more common and detection-friendly explorer.exe → powershell.exe chain. Instead, execution flows through wscript.exe and an App-V publishing script (Figure 3), which can fly under the radar as legitimate activity on systems where App-V components are present.

Why the Chain Only Runs on Enterprise Windows

App-V components are not universally available. App-V is built into modern Enterprise and Education editions of Windows 10 and Windows 11, as well as modern Windows Server versions, but is not present on standard Home or Pro installations.

On systems where App-V is absent or not enabled, the command fails outright, and the infection chain does not progress. This is significant for two reasons: it disrupts execution in many sandbox and security research environments that lack App-V components, and it naturally filters out lower-value, single-user hosts in favor of enterprise-managed systems.

The Execution Gate and Alias/Wildcard Obfuscation

As part of the initial execution, the command sets a temporary environment variable named ALLUSERSPROFILE_X to a short opaque value. By itself, this variable is meaningless; however, it becomes important later when it acts as a marker proving the user executed the command manually — an execution gate.

The embedded PowerShell logic avoids obvious strings by reconstructing functionality at runtime using aliases and wildcard resolution. Rather than calling sensitive cmdlets directly, the script resolves them indirectly:

• gal is an alias for Get-Alias, and gal i*x retrieves the alias matching iex, which resolves to Invoke-Expression.
• gcm is an alias for Get-Command, and gcm *stM* resolves to Invoke-RestMethod through wildcard matching.

Once reconstructed, the logic retrieves a remote script hosted on attacker-controlled infrastructure and executes it entirely in memory, transitioning from user-assisted interaction into a fully automated loader chain.

Hiding the Loader in Noise (herf54)

The returned script, called herf54, contains no instantly readable PowerShell logic (Figure 4). Instead, it consists of thousands of variables with cmdlet-looking names, each storing a short base64-encoded fragment. These names exist solely to mislead static inspection.

At runtime, these fragments are assembled into an ordered array, concatenated into a single base64 string, decoded, and executed in memory using ScriptBlock.Create. This stage’s sole purpose is to reconstruct and execute the next loader while burying it under an avalanche of noise.

A Custom HTTPS Routine and a Clipboard-Based Gate

The decoded loader implements its own HTTPS fetch routine using System.Net.Sockets.TcpClient and System.Net.Security.SslStream. Instead of relying on Invoke-WebRequest or Invoke-RestMethod, it manually constructs an HTTP GET request, writes it directly to a TLS stream, and extracts the response body by splitting on the HTTP header delimiter (Figure 5). This sidesteps telemetry and detections commonly associated with standard PowerShell networking cmdlets.

Once this function is defined, the loader immediately enforces an execution gate tied to clipboard contents (Figure 6). The clipboard access resolves to Get-Clipboard, and the script searches for a marker matching $env:ALLUSERSPROFILE_X=’…’. If that marker is not present, the script displays decoy messages using WScript.Shell.Popup() and then stalls by entering an infinite wait state via ManualResetEvent().WaitOne().

This inhibits analysis in sandboxes that detonate the script without simulating the expected clipboard state: they do not fail or exit cleanly; they simply wait indefinitely. Only when the expected marker is present does execution continue.

Stage 2: Pulling Live Config From a Public Google Calendar

With the gate satisfied, the loader fetches its next-stage configuration from a trusted third-party service, so the attacker can update delivery without redeploying earlier stages.

Reading Configuration From an .ics File

The loader pulls configuration data from a public Google Calendar (.ics) file (Figure 7). This mirrors a broader pattern across modern malware families — campaigns that abuse Steam profiles, social platforms, or blockchain-based dead drops — where trusted third-party services host live configuration. By externalizing configuration this way, the actor can rotate infrastructure or adjust delivery parameters without redeploying earlier stages, reducing operational friction and extending the lifespan of the initial infection vector.

Although presented as a calendar object, an .ics file is just plain text. The loader fetches it using its custom HTTPS routine and parses the contents manually rather than relying on calendar-specific libraries.

It scans for a VEVENT entry with a SUMMARY value of povvv, using this as a selector so the calendar can contain decoy entries without disrupting execution. After base64-decoding the matching DESCRIPTION field, it resolves to a pipe-delimited config string with three values:

• t = sec-t2[.]fainerkern[.]ru
• p = svc-int-api-identity-token-issuer-v2-mn[.]in[.]net
• pu = 8f0b3df4e0aadf775c9bc934f53b2d17

Per-Victim Subdomain Generation

Each value influences the next stage. The loader first issues a request to hxxps[://]<t>/<clipboard-token>, discarding the response. This acts as an additional execution gate, again tying progression to the clipboard-derived token from the initial Fake CAPTCHA interaction and ensuring later stages only proceed when the earlier user-driven steps occurred as intended.

From there, the loader constructs a victim-specific subdomain: it gathers environment-derived values, concatenates them, hashes the result with MD5, and truncates to the first eight hexadecimal characters (Figure 8), producing a URL of hxxps[://]<md5-subdomain>.<p>/<pu>.

The loader then assembles another PowerShell stage on the fly. iex is reconstructed at runtime by extracting characters from $env:ComSpec, again avoiding high-risk strings. The resulting downloader is Unicode-encoded, base64-encoded, and executed via WMI using Win32_Process.Create, spawning a hidden 32-bit PowerShell instance — a clean execution boundary between the earlier loader and the next stage.

XOR-Decrypting the Next Loader

The returned script introduces no immediate network activity. It functions as another transitional loader: it reconstructs a large embedded base64 payload, decodes it at runtime, and applies a repeating XOR to recover the underlying PowerShell source. The XOR key is the string AMSI_RESULT_NOT_DETECTED (Figure 9).

The routine is intentionally lightweight but enough to frustrate static inspection. Once decrypted, the recovered PowerShell is executed in memory via a dynamically generated script block.

Stage 3: PNG Steganography and In-Memory Payload Delivery

The next payload is hidden inside an ordinary-looking image and reassembled entirely in memory.

Fetching the Image via Native WinINet APIs

This stage hides an encrypted, compressed PowerShell payload inside a benign-looking PNG that is retrieved and processed entirely in memory (Figure 10).

Rather than downloading a script directly, it resolves native WinINet APIs at runtime to fetch image content in a way that resembles legitimate browser behavior. The loader dynamically loads wininet.dll and resolves InternetOpenA, InternetOpenUrlA, InternetReadFile, and InternetCloseHandle via LoadLibraryA and GetProcAddress, invoking them through dynamically constructed delegates — avoiding native PowerShell networking functions and bypassing many script-focused logging mechanisms.

The script attempts to retrieve the PNG (Figure 11) from three CDN-hosted URLs, stopping once one returns data. The same image was hosted across three public platforms for redundancy:

• gcdnb[.]pbrd[.]co
• iili[.]io
• s6[.]imgcdn[.]dev

Extracting the Payload With LSB Steganography

Once retrieved, the loader uses System.Drawing to build a bitmap object and access the raw pixel buffer, extracting an embedded payload using Least Significant Bit (LSB) steganography — hiding data in the lowest-order bits of pixel values without noticeably altering the image (Figure 12).

The loader reads the initial 64 least significant bits to reconstruct an integer specifying the exact payload length, then sequentially rebuilds each payload byte from eight individual pixel LSBs until that length is reached. This length-driven extraction is fully deterministic and avoids the pattern matching typically associated with heuristic steganographic detection.

Decrypt, Decompress, and Execute

The recovered byte stream is decrypted using a repeating XOR (Figure 13). The key is derived by XOR-combining two embedded 32-byte arrays, producing the fixed ASCII key s8YUKQ0CqUd6HNwGSRDZ%Qpux1N9MKHh. While lightweight, this prevents direct inspection while preserving the PNG’s visual and structural integrity.

The decrypted data is GZip-decompressed in memory and interpreted as UTF-8 PowerShell, then executed via Invoke-Expression, continuing into the next stage.

The Final In-Memory Loader and Shellcode Handoff

The final-stage script performs no network retrieval or environmental checks; it is a self-contained transformation layer that prepares execution entirely in memory (Figure 14). It initializes a 32-byte rolling key and a large embedded encrypted array, then runs a byte-level normalization step, subtracting a fixed constant, to force runtime evaluation.

A second, rolling-XOR pass follows, where each byte is XORed with a position-dependent key that mutates as decryption progresses — making reliable static recovery impractical without emulating the full routine.

The script then trims padding, decodes the remaining bytes as UTF-8, and executes the result in memory. That decrypted script repeats the same process with a second embedded blob, this time recovering raw shellcode rather than PowerShell.

From here, execution transitions fully out of PowerShell. The shellcode is staged using native Windows system calls — NtAllocateVirtualMemory to allocate executable memory and NtProtectVirtualMemory to update page permissions — before execution is transferred to the shellcode entry point via a newly created thread. This shellcode is a native loader responsible for mapping and executing the final payload.

Stage 4: Amatera Stealer Payload & C2 Behavior

The shellcode loader ultimately maps and executes a Windows PE payload identified as Amatera Stealer, a modular information-stealing malware family. Previously tracked under the ACRStealer name, Amatera has continued to evolve through frequent updates and is commonly delivered through multistage loader chains that favor in-memory execution and limit static artifacts.

Hardcoded C2 & Host-Header Spoofing

After execution, the payload establishes outbound C2 by connecting directly to a hardcoded IP address, 212.34.138[.]4, while supplying a spoofed HTTP Host header.

This decouples the network destination from the hostname presented at the application layer, so some monitoring tools record the connection under the Host header value rather than the raw IP — surfacing C2 traffic as an apparently legitimate domain. Historically, Amatera samples have impersonated high-traffic domains such as microsoft.com, google.com, and facebook.com to reduce scrutiny during routine triage.

In this case, the payload instead supplies cdn[.]extreme[REDACTED]videos[.]com as the Host header. This is unusual and somewhat self-defeating: rather than a high-reputation domain, the chosen hostname is conspicuous and likely draws more attention than it deflects, arguably undermining the purpose of Host-header spoofing.

Evading Standard Networking Libraries

Beyond Host-header spoofing, the network stack deliberately avoids standard Windows networking libraries. Rather than WinHTTP or WinINet, the malware performs socket operations through a WoW64 syscall to NtDeviceIoControl, targeting the \\Device\\Afd\\Endpoint interface.

This repeatedly observed Amatera technique lets it interact directly with the Windows networking stack while bypassing many user-mode API hooks used by EDR and network inspection tooling.

Layered Encryption Over TLS

Although the payload communicates over TLS, the encrypted channel is treated as transport rather than a security boundary. All C2 traffic is additionally encrypted at the application layer using Windows SSPI APIs — AcquireCredentialsHandleA, InitializeSecurityContextA, EncryptMessage, and DecryptMessage.

This layered model, recurring across the Amatera family, ensures request and response contents stay opaque even if TLS is intercepted.

Server-Defined C2 Routing (GetEndpoints)

The payload issues an encrypted GetEndpoints request as an initial coordination step with the C2. The response provides short identifier keys — such as a, b, c, g, m, o, w, and err — each mapped to a server-supplied endpoint path.

These pairs are kept in memory and used to route subsequent communications, letting the malware rely on server-provided paths rather than embedding fixed URLs. Subsequent requests use HTTP POST with binary payloads, keeping configuration retrieval, host registration, and tasking inside encrypted request bodies rather than URL parameters.

These behaviors align with what has been documented for Amatera Stealer — its registration and tracking, configuration-driven behavior, and tasking all reflect its modular execution model. Notably, the string GETWELL is embedded within the malware, a marker repeatedly observed across Amatera campaigns and widely regarded as a reliable indicator of the family.

How to Defend Against Fake CAPTCHA (ClickFix) Attacks

• Restrict access to the Windows Run dialog via Group Policy to prevent Fake CAPTCHA–style command execution.
• Remove App-V components where they are not required, to eliminate abuse via SyncAppvPublishingServer.vbs. Blackpoint’s Managed Application Control can block unauthorized binaries from executing.
• Educate users to recognize Fake CAPTCHA lures and avoid executing commands from pop-ups or unexpected prompts.
• Enable comprehensive PowerShell logging and monitor for alias-heavy, wildcard-based, or dynamically constructed execution patterns.
• Monitor for suspicious process lineage involving script hosts and PowerShell, such as explorer.exe → wscript.exe → powershell.exe → powershell.exe.
• Alert on PowerShell execution originating from App-V scripts such as SyncAppvPublishingServer.vbs.
• Monitor for outbound connections where the requested Host header or TLS SNI does not align with the resolved IP address.

Amatera Stealer Indicators of Compromise (IOCs)

What the Amatera Stealer Campaign Means for MSPs & Defenders

What makes this campaign interesting isn’t any single trick, but how carefully everything is thought out when chained together. Each stage reinforces the last, using manual user interaction, clipboard validation, and live config from a trusted third-party service, so the flow only progresses when it unfolds almost exactly as the attacker expects, making both automated detonation and casual analysis significantly harder.

The reliance on Google Calendar and public image CDNs reflects a growing tendency to “live off someone else’s infrastructure,” letting attackers externalize configuration and staging. Combined with in-memory execution and steganographic delivery, this design favors operational control and longevity, adapting without exposing new static artifacts.

Why the Delivery Chain Matters More Than the Payload

In the end, all this complexity delivers a familiar result: Amatera Stealer, operating with layered encryption, evasive networking, and modular tasking. The payload isn’t especially novel, but the delivery strategy around it is engineered to survive long enough to matter.

As fake CAPTCHA lures and user-assisted execution keep thriving, defenders increasingly have to look beyond what ran and focus on how and why it ran at all. Understanding those paths, and the trust relationships they abuse, is becoming as important as detecting the malware at the end.

As this campaign shows, stopping modern intrusions means looking beyond the final payload to how execution began. See what 24/7 detection and response looks like in your clients’ environments.

Request a Demo →

Appendix

1. Microsoft Application Virtualization