VEIL#DROP: How Attackers Are Hiding Malware Inside Google's Blogger
Securonix researchers have been tracking a multi-stage malware campaign that weaponises Google's Blogger platform to sneak an infostealer past corporate defences. They're calling it VEIL#DROP, and it's a fairly nasty piece of work.
The attack starts with a JavaScript file dressed up to look like a PDF, something like transcript.pdf.js. A victim runs it, Windows Script Host fires up, and PowerShell launches with execution policy restrictions already bypassed. From there, things get creative.
The PowerShell stage reaches out to a Blogger page controlled by the attackers. Using Google's own infrastructure as a payload host is a deliberate choice: reputation-based filtering tends to give blogspot.com a free pass because it's a legitimate Google service. The downloaded content then quietly runs the actual infection while flashing a genuine Google page at the user to sell the illusion that a PDF just opened. Nothing to see here.
What ends up on the machine is PureLogs Stealer, a .NET infostealer sold as a subscription service by a threat actor going by PureCoder. It harvests credentials, session tokens, and assorted sensitive data from compromised systems. Classic MaaS operation.
The loader component is where the technical effort really shows. After XOR-decrypting an embedded payload, it builds the next-stage Blogger URL dynamically at runtime by inserting a random number of forward slashes into the address. This breaks static URL signatures and makes indicator-based blocking largely useless. On top of that, placeholder values in the reconstructed script get swapped out with randomly generated strings on every execution, defeating file hash detection and script-based signatures in one move.
The final payload runs entirely in memory. No files dropped, no disk artifacts. It loads a .NET assembly using reflective code loading, which keeps the whole thing invisible to tools watching the filesystem.
If memory execution is blocked, the loader falls back to a cascade of Microsoft-signed binaries: regsvcs.exe, installutil.exe, msbuild.exe, and aspnet_compiler.exe. These are trusted, already present on Windows systems, and unlikely to raise flags. The loader doesn't commit to any single living-off-the-land binary either. It tries them in sequence until one works, which makes blocking any individual method largely pointless.
The researchers note that a stealer compromise rarely stays contained to one machine. The stolen credentials and session data become the entry point for deeper access, lateral movement, and potentially cloud infrastructure breaches.
Putting it bluntly: this campaign combines trusted cloud hosting, fileless execution, runtime polymorphism, and LOLBin abuse into a coherent package specifically designed to avoid the defences most organisations actually have deployed. It's not particularly novel in any one technique, but the combination and the operational discipline behind it make it worth taking seriously.