Key Takeaways
- The VEIL#DROP campaign uses a multi‑stage attack chain that begins with a malicious JavaScript file masquerading as a PDF (e.g., transcript.pdf.js) and relies on social engineering or drive‑by compromises for initial delivery.
- A PowerShell loader, launched via Windows Script Host with execution‑policy bypasses, fetches a next‑stage payload from a Blogger subdomain, leveraging Google’s trusted infrastructure to evade reputation‑based defenses.
- The loader employs XOR‑obfuscation, dynamic URL generation (inserting random forward slashes), and runtime mutation to create unique, polymorphic scripts that avoid static signatures and file‑hash detection.
- Execution is performed entirely in memory using reflective .NET loading; if blocked, the malware falls back to living‑off‑the‑land (LotL) binaries such as regsvcs.exe, installutil.exe, msbuild.exe, or aspnet_compiler.exe.
- The final payload is PureLogs Stealer, a .NET‑based information thief that harvests credentials, browser data, cryptocurrency wallets, and other sensitive information, enabling further lateral movement, persistence, and potential cloud‑infrastructure compromise.
- The combination of trusted cloud services, fileless techniques, polymorphism, and LotL abuse demonstrates a sophisticated effort to bypass traditional AV, reduce forensic artifacts, and maintain stealth throughout the infection lifecycle.
Overview of VEIL#DROP
Securonix researchers have identified a novel malware delivery chain dubbed VEIL#DROP, which blends social engineering, abused legitimate web services, and advanced evasion tactics to deploy the PureLogs information stealer. The campaign’s hallmark is its reliance on multi‑stage, fileless execution that minimizes artifacts on disk while maximizing stealth. By leveraging Google’s Blogger platform as a staging ground and employing a cascade of living‑off‑the‑land binaries, the attackers can blend malicious activity with normal web traffic, making detection challenging for conventional security tools.
Initial Infection Vector
The infection chain typically starts with a spear‑phishing email or a drive‑by compromise that delivers a deceptively named JavaScript file—often styled as transcript.pdf.js—to the victim. When the user opens the file, Windows Script Host (wscript.exe) executes it, bypassing typical user‑level warnings because the file appears benign. This initial script acts as a dropper, invoking PowerShell with execution‑policy bypass flags (‑ExecutionPolicy Bypass) to allow unrestricted script execution regardless of system policies.
PowerShell Stager and Blogger Hosted Payload
Once PowerShell is launched, its primary role is to retrieve a secondary payload hosted on a Blogger subdomain (e.g., htlwub00klocate.blogspot[.]com). By using Google’s trusted domain, the attackers sidestep URL‑reputation filters that might otherwise block unknown or malicious hosts. The downloaded PowerShell snippet is designed to display a innocuous web page—such as Google’s homepage—to give the impression that a PDF document has opened, while the malicious workflow proceeds silently in the background.
Dynamic URL Generation and Runtime Mutation
To thwart static signature‑based defenses, the PowerShell loader employs XOR decryption on an embedded blob, after which it constructs a unique Blogger URL for each infection attempt. This is achieved by inserting a random number of forward slashes into the base URL string (e.g., https://thehackernews.com///…), thereby producing a distinct URL each time and evading URL‑based blocking mechanisms. Furthermore, the loader performs runtime mutation: placeholder values within the script are replaced with randomly generated strings and values during execution, altering the script’s appearance and hash on every run. This polymorphism defeats signature‑based scanners that rely on static patterns or file hashes.
Fileless Execution and Reflective .NET Loading
After mutation, the reconstructed script is executed entirely in memory, leaving no trace on the filesystem. It functions as a loader that decodes and runs the core malware component—a .NET assembly—using reflective code loading. Reflective loading allows the .NET payload to be instantiated directly from a byte array in memory, bypassing the need to write the assembly to disk and thus avoiding typical file‑based detection methods such as antivirus scans or endpoint detection and response (EDR) file monitoring.
Living‑off‑the‑Land Fallback Mechanisms
Should security controls prevent direct reflective loading (e.g., due to constrained .NET runtime or aggressive memory protections), the loader incorporates a fallback chain that leverages legitimate, Microsoft‑signed binaries. It attempts to execute the recovered .NET assembly via regsvcs.exe, installutil.exe, msbuild.exe, or aspnet_compiler.exe in sequence until one succeeds. Because these binaries are trusted, signed by Microsoft, and commonly present on Windows systems, their use makes the malicious activity blend with normal administrative or development tasks, further reducing the likelihood of raising alerts.
Impact of PureLogs Stealer
The ultimate payload, PureLogs Stealer, is a .NET‑based information harvester capable of exfiltrating a broad spectrum of sensitive data, including:
- Stored credentials from web browsers, email clients, and FTP tools
- Cryptocurrency wallet files and private keys
- Autofill data, cookies, and session tokens
- System information, running processes, and network configuration
Beyond immediate data theft, the harvested information serves as a foothold for deeper intrusion. Attackers can use stolen credentials to move laterally across the network, establish persistence via scheduled tasks or service modifications, and even pivot to cloud environments if the compromised host holds access tokens or API keys. Consequently, a single endpoint infection can precipitate a full‑scale breach of an organization’s digital assets.
Evasion Techniques Summary
VEIL#DROP exemplifies a modern, multi‑layered evasion strategy:
- Social Engineering & Masquerading – Uses PDF‑like filenames to trick users into executing JavaScript.
- Trusted Infrastructure Abuse – Hosts payloads on Blogger (google.com) to bypass reputation filters.
- Obfuscation – Employs XOR encryption and dynamic key derivation to hide payloads.
- Dynamic & Polymorphic Code – Generates unique URLs and mutates script content at runtime to evade static signatures.
- Fileless Execution – Runs entirely in memory, avoiding disk‑based artifacts.
- Reflective .NET Loading – Loads the malicious assembly without writing it to disk.
- Living‑off‑the‑Land (LotL) – Falls back to legitimate Microsoft binaries, blending with normal system activity.
- Process Tampering – Attempts to terminate wscript.exe and drop the initial dropper file to reduce forensic traces.
By combining these tactics, the attackers significantly lower the probability of detection by conventional antivirus, URL filters, and endpoint protection platforms, while maintaining a low operational footprint throughout the infection lifecycle. Organizations should therefore prioritize behavioral monitoring, anomaly detection in PowerShell usage, strict application control, and vigilant inspection of outbound connections to trusted cloud services as part of a defense‑in‑depth strategy against threats like VEIL#DROP.