VEIL#DROP: A PowerShell Loader Hidden Behind Blogger Pages

The VEIL#DROP campaign, documented by Securonix in early July 2026, illustrates a trend that has become central among threat actors: abusing trusted cloud infrastructure to host malicious payloads. Here, it is Google's Blogspot pages, the Blogger platform, that serve as a distribution relay. The goal is simple: make malicious traffic look like legitimate web traffic and evade domain-reputation-based security controls. A flow to blogspot.com raises no suspicion.

This chain, designed entirely for in-memory execution, ends in the deployment of the PureLogs stealer. It is representative of what office endpoints face today: no malicious binary written to disk up front, only scripts and legitimate system binaries turned against their purpose.

The infection chain, step by step

It all begins with a deceptively named JavaScript file, masquerading as a document, such as transcript.pdf.js. The double extension hides the file's true nature: the user thinks they are opening a PDF, they launch a script. This script runs via Windows Script Host, technique T1059.007 (JavaScript), and launches PowerShell with execution policy bypasses enabled, T1059.001.

PowerShell then retrieves the following stages from attacker-controlled Blogspot pages, abusing Google's trusted infrastructure, technique T1102 (Web Service). The initial Blogspot-hosted payload downloads a decoy document to avoid suspicion, wipes evidence of execution, terminates selected processes, and decrypts embedded content using a custom XOR routine. The whole aims to leave no persistent artifact on disk.

The fallback to signed Microsoft LOLBins

The most instructive aspect for detection is the fallback behavior. If direct in-memory execution is blocked, VEIL#DROP falls back on signed Microsoft binaries to launch the malware using living-off-the-land techniques. The binaries used include RegSvcs, InstallUtil, MSBuild, and aspnet_compiler, all tracked under T1218 (System Binary Proxy Execution). These legitimate executables, present on any Windows host with the .NET framework, are repurposed to run arbitrary code.

This fallback is a boon for the defender, because it creates a stable detection point. These binaries have no legitimate reason to be launched from a PowerShell process spawned by a user script, nor to load code from a temporary path.

title: .NET LOLBin launched from PowerShell (VEIL#DROP-style fallback)
id: 6d3f1a82-4b09-4e57-8c2a-1f7e0b5d9c34
status: experimental
description: >
  Detects RegSvcs, InstallUtil, MSBuild, or aspnet_compiler launched by PowerShell,
  the living-off-the-land fallback pattern seen in VEIL#DROP.
references:
  - https://www.securonix.com/blog/veildrop-blogspot-hosted-powershell-loader/
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    ParentImage|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
    Image|endswith:
      - '\RegSvcs.exe'
      - '\InstallUtil.exe'
      - '\MSBuild.exe'
      - '\aspnet_compiler.exe'
  condition: selection
falsepositives:
  - .NET development environments, to document and exclude precisely
level: high
tags:
  - attack.defense_evasion
  - attack.t1218
  - attack.execution

Detect the entry point: a script launching PowerShell

Upstream of the fallback, the chain presents another strong signal: a script file, wscript or cscript, that launches PowerShell. This is a rare sequence in legitimate office use and typical of scripted-attachment infection chains. A Sigma rule on this pattern, correlated with an outbound connection to blogspot.com from the PowerShell process, surfaces exactly the VEIL#DROP lure. Watching PowerShell connections to free hosting platforms, when they match no business use, is a valuable behavioral indicator.

What PureLogs steals and why it matters

Once active, the PureLogs stealer collects browser credentials, cookies, autofill data, cryptocurrency wallet information, and system details. The most concerning point concerns stolen session cookies: they allow bypassing multi-factor authentication by hijacking active user sessions. In other words, a successful cookie theft can grant access to MFA-protected services without ever knowing the password or the second factor. Stolen credentials then feed underground marketplaces to facilitate broader intrusions.

The measures that break the chain

Several controls sharply reduce the risk. Associating .js and .vbs files by default with a text editor rather than Windows Script Host neutralizes the most common entry point. Restricting PowerShell to the accounts that need it, and enabling its detailed logging, gives the rules above the visibility they need. Finally, an application control policy that restricts execution of .NET binaries like MSBuild or InstallUtil outside development contexts closes the fallback path.

Detecting a chain that combines scripts, trusted cloud abuse, and LOLBins requires rules built on behavioral sequences, not file signatures. That is what the ThreatClaw Sigma feed provides: rules that target the execution context, from the initial script to the fallback binary, tested before release to stay operable over time.