Veil#Drop Attacks: Blogspot Payload Delivery Explained

📅 July 7, 2026  |  🏷 News Analysis  |  Cyber Security, Information Security, Threat Management

A free blogging platform best known for hosting hobbyist recipe posts and travel diaries is now serving as a malware distribution network — and defenders are struggling to block it without collateral damage. Security researchers confirmed in late June 2026 that a previously undocumented campaign, internally designated Veil#Drop, has been systematically abusing Google’s Blogspot infrastructure to stage and deliver encrypted payloads against enterprise targets across North America and Western Europe. Because the traffic originates from *.blogspot.com domains — a subdomain space shared with millions of legitimate blogs — conventional domain-based blocking creates significant operational friction. The attackers, it turns out, planned for exactly that.

What Is Veil#Drop? Campaign Overview and Attribution Context

Veil#Drop was first flagged by threat intelligence teams at two independent firms simultaneously in early June 2026, with coordinated public disclosure arriving on June 28. The campaign’s name reflects its twin defining characteristics: the use of obfuscation layers (the “veil”) and the abuse of a trusted hosting platform to “drop” payloads rather than serving them from attacker-controlled infrastructure. As of the time of writing, attribution remains contested, though behavioral indicators — including tooling overlaps and victimology — show partial similarities to clusters previously tracked under the loose umbrella of TA4557, a financially motivated threat actor group known for targeting financial services and professional services firms.

Initial Access Vectors

The attack chain begins deceptively simply: a spear-phishing email carrying a macro-enabled Office document or a password-protected ZIP archive containing an LNK shortcut file. In analyzed samples, the lure documents mimicked payroll correction notices, legal subpoenas, and — with notable irony — IT security policy updates. Once a victim interacts with the initial file, a PowerShell stager executes. Rather than reaching out to a traditional command-and-control (C2) server or a bulletproof hosting provider, that stager makes a perfectly ordinary HTTPS GET request to a Blogspot URL. The HTML of the targeted blog post contains Base64-encoded payload strings embedded inside HTML comment tags — invisible to a casual reader, trivially parsed by a script.

Why Blogspot and Why Now

The choice of Blogspot is not accidental or improvised. Google’s infrastructure provides implicit trust: the platform uses valid TLS certificates issued by Google Trust Services, traffic to blogspot.com passes through Google’s CDN, and many organizations explicitly allowlist Google properties in proxy and firewall configurations. A 2025 report by Censys found that approximately 34% of enterprise security teams maintain hardcoded allowlist rules for Google-owned domains that are rarely reviewed after initial configuration. Veil#Drop weaponizes that administrative inertia directly.

Technical Breakdown: The Payload Delivery Mechanism

Understanding the mechanics of Veil#Drop requires walking through each stage carefully, because the campaign’s sophistication lies less in any single novel technique and more in how commodity methods are chained with unusual precision. Researchers from Securonix Threat Labs, one of the two firms involved in initial discovery, published a detailed breakdown showing four distinct stages between initial phishing and final payload execution.

Stage-by-Stage Execution Chain

Stage one is the lure document execution. Stage two is the PowerShell stager, which uses Invoke-WebRequest (or a .NET WebClient equivalent to evade basic PowerShell logging policies) to pull the Blogspot page. Stage three involves parsing the HTML response — the stager searches for a specific comment delimiter string and extracts the Base64 blob between it. That blob decodes to a secondary loader DLL. Stage four is execution of the loader via rundll32.exe or, in more recent variants, a signed binary proxy such as msiexec.exe to further frustrate endpoint detection. The final payload observed across incidents has been a customized variant of AsyncRAT with additional modules for credential harvesting and lateral movement preparation.

One particularly notable technical detail: the Blogspot posts used as staging grounds are not newly created accounts. Investigators found that several of the abused blogs had been dormant since 2014 or earlier — likely acquired through credential stuffing of leaked Google account databases — and had a plausible history of innocent content. The posts containing the hidden payloads were published within 48 hours of each campaign wave, and the Blogspot pages were taken down — by either the attackers or Google’s automated abuse systems — within an average of 72 hours of each wave’s launch. The narrow operational window is a deliberate design choice: it limits Google’s response time while ensuring the payload is available long enough to complete delivery to targeted machines.

Evasion Techniques and Anti-Analysis Measures

Beyond the trusted-platform staging, Veil#Drop incorporates several layered evasion techniques worth cataloguing. The Base64 payload within the Blogspot comment is additionally XOR-encrypted with a hardcoded four-byte key — trivially reversible once identified, but sufficient to defeat signature-based detection scanning HTML content. The stager performs sandbox detection checks, including system uptime verification (machines with uptime under four minutes are flagged as likely analysis environments) and screen resolution checks. Researchers also noted the stager querying the number of recently accessed files: fewer than twenty recent documents in shell history triggers an abort condition. These are not novel techniques, but their combination within a campaign that primarily relies on trust-based infrastructure evasion rather than zero-day exploitation speaks to a threat actor that understands operational risk management.

The Defender’s Dilemma: Blocking Without Blinding Yourself

The core challenge Veil#Drop poses to blue teams is not technical detection of the payload itself — modern EDR platforms catch AsyncRAT variants at the execution stage with reasonable reliability. The challenge is detecting and interrupting the payload retrieval stage without breaking legitimate business operations that depend on Google’s platforms. A 2024 Gartner survey found that 61% of enterprise SOC teams reported at least one significant business disruption caused by overbroad domain blocking within a twelve-month period. Blocking *.blogspot.com categorically would, for many organizations, also interrupt legitimate research access, marketing monitoring, and vendor communications.

Detection Opportunities at Each Stage

Despite that friction, defenders are not without options. The most actionable detection opportunity in the Veil#Drop chain is behavioral: PowerShell processes spawned by Office applications making outbound HTTPS connections to content-hosting platforms is a high-fidelity detection signal that does not require blocking any domain. Microsoft Defender for Endpoint, CrowdStrike Falcon, and SentinelOne all have pre-built behavioral rules covering parent-child process anomalies in the Office suite. The Securonix disclosure explicitly noted that all observed Veil#Drop incidents showed WINWORD.EXE or EXCEL.EXE as parent processes for powershell.exe — a pattern that organizations running attack surface reduction (ASR) rules in block mode would have caught at stage one.

At the network layer, DNS and proxy logs showing Office application user-agent strings retrieving HTML content from Blogspot — as opposed to a browser — provide a secondary detection layer. Security teams running a SIEM with proper user-agent parsing can write a relatively simple correlation rule: HTTP requests where the user-agent does not match a recognized browser pattern and the destination is a known personal publishing platform deserve automated triage. That rule will generate some false positives from legitimate scripted automation, but the volume is manageable.

The Role of Google’s Abuse Pipeline

It is worth examining how effectively Google’s own systems responded to Veil#Drop infrastructure. According to the joint researcher disclosure, Google’s Trust & Safety team was notified on June 12, 2026. By June 20, the majority of identified staging blogs had been suspended. That eight-day response window is broadly consistent with Google’s published abuse handling timelines for malware-related reports, but it represents a significant operational window for a campaign that appears to launch in coordinated waves of 24–48 hours per target cohort. Researchers are calling for a dedicated malware-staging abuse fast-track pathway at major hosting providers — similar to the expedited takedown processes that currently exist for phishing pages — that could compress that timeline to hours rather than days.

Broader Threat Landscape: Trusted-Platform Abuse as a Persistent Strategy

Veil#Drop is not an isolated innovation. It sits within a growing pattern of threat actors deliberately migrating payload staging and C2 communication onto platforms whose domains carry implicit organizational trust. GitHub has been used for C2 communication by APT groups including Lazarus and APT41. Discord’s CDN has been a recurring payload host since at least 2021, with over 1,600 malware samples linked to Discord CDN URLs catalogued by ESET researchers by the end of 2023. OneDrive, Dropbox, and Google Drive have all featured in campaigns precisely because they share the same trust inheritance problem: blocking them categorically causes business disruption that defenders cannot absorb.

Comparative Campaign Analysis

What distinguishes Veil#Drop from earlier trusted-platform abuse campaigns is the precision of the dormant account acquisition strategy. Most Discord CDN abuse involves newly created accounts or accounts created specifically for the campaign. Using decade-old Blogspot accounts with organic posting histories — however thin — represents a meaningful step toward making the staging infrastructure appear legitimate during the narrow window it needs to be operational. This is operationally similar to the GhostWriter campaign documented by Mandiant in 2021, which used compromised legitimate news websites rather than attacker-built infrastructure to host influence operation content, specifically because authentic domain history defeats many automated classification systems.

The implication for defenders is uncomfortable: if the trend toward hijacked dormant accounts continues, the categorical “newly created account” detection heuristic that many SOC teams apply to cloud storage and blogging platforms will become progressively less reliable. Domain age and organic posting history are not reliable indicators of trustworthiness when credential stuffing against leaked databases can cheaply acquire accounts with years of legitimate history.

Incident Response Considerations for Affected Organizations

For organizations that have already experienced a Veil#Drop intrusion — or suspect they may have based on the IoCs published in the June 28 disclosure — the incident response priorities differ somewhat from a conventional RAT infection scenario, because the trust-based delivery mechanism has specific forensic implications.

Forensic Artifacts and Threat Hunting Queries

The PowerShell stager in observed Veil#Drop samples writes a temporary DLL to the %TEMP% directory before loading it. The DLL filename follows a pattern of eight random alphanumeric characters followed by .tmp. Crucially, the stager also writes a scheduled task for persistence — the task name in analyzed samples has been a GUID-formatted string, which is unusual enough to be a meaningful hunting signal when combined with the parent process context. Threat hunters should query scheduled task creation events (Windows Event ID 4698) for GUID-format task names created within thirty minutes of any powershell.exe process that made an outbound connection to a content-hosting platform.

Network forensics should include a review of proxy and DNS logs for the 30-day period prior to detection, specifically looking for connections to *.blogspot.com from non-browser processes. The AsyncRAT final payload in Veil#Drop variants communicates over TCP port 6606 or 7707 to attacker-controlled infrastructure — distinct from the Blogspot staging — and C2 IP addresses from the June 28 disclosure should be checked against historical network flow data. If C2 communication is confirmed, the incident scope expands to credential harvesting assessment, since the observed AsyncRAT modules include a browser credential stealer targeting Chrome, Edge, and Firefox credential stores.

Key Takeaways

• Trusted platform staging is a deliberate, strategic choice: Veil#Drop abuses Blogspot specifically because Google’s infrastructure inherits organizational trust and survives categorical blocking restrictions that would stop traffic to attacker-owned domains instantly. Defenders must assume that any platform with implicit organizational allowlisting is a potential staging ground.
• Behavioral detection outperforms domain blocking here: The most reliable detection point is the anomalous parent-child process relationship — Office applications spawning PowerShell with outbound HTTPS connections — not the destination domain. Ensuring ASR rules and EDR behavioral policies are in block mode (not audit mode) closes the most accessible gap.
• Dormant account hijacking complicates infrastructure analysis: The use of decade-old Blogspot accounts with organic posting history defeats many age-based and activity-based domain reputation heuristics. Threat intelligence teams should reassess confidence levels assigned to domain-age scoring for shared hosting platforms.
• Google’s abuse response timeline creates an operational window: An eight-day takedown timeline for reported staging infrastructure is insufficient for the narrow-window deployment model Veil#Drop uses. Organizations should not rely on platform provider takedowns as a primary defense and should escalate coordinated disclosures through CERT channels in parallel with direct provider reporting.
• AsyncRAT deployment signals credential compromise scope: Any confirmed Veil#Drop infection should trigger immediate credential rotation for browser-stored passwords and SSO tokens, since the observed final payload includes browser credential harvesting capability that may have exfiltrated data before EDR detection.

Conclusion: Closing the Trust Gap Before the Next Campaign Wave

Veil#Drop is a technically modest campaign built on a strategically sophisticated premise: that defenders’ own allowlisting habits are a more exploitable vulnerability than any unpatched CVE. The campaign’s operators did not need a zero-day. They needed a Google account, a PowerShell stager, and a working knowledge of how enterprise proxy configurations handle traffic to Google-owned properties. That combination proved sufficient to reach enterprise networks across two continents through mid-2026.

The longer-term defensive answer is not to block Blogspot — it is to eliminate the architectural premise that any domain, regardless of ownership or reputation history, should receive blanket implicit trust that bypasses behavioral inspection. Zero-trust network architecture principles extend to egress traffic, not just lateral movement within a perimeter. If a PowerShell process is retrieving HTML from a blogging platform at 2:47 AM and parsing it programmatically, the domain’s ownership is irrelevant — the behavior is the signal.

Your immediate action items: Pull your current ASR rule configuration and verify that “Block all Office applications from creating child processes” is set to block, not audit. Run a threat hunt in your SIEM for GUID-format scheduled tasks created in the last 90 days alongside concurrent PowerShell outbound connections to content-hosting platforms. Submit your proxy logs against the Veil#Drop IoC list from the June 28 disclosure. And if you haven’t reviewed your organization’s Google-domain allowlist entries in the last twelve months, now is the time — because your attackers already know what’s on it.