【CyCraft Monthly Intelligence】Operation Dragon Weave: Spear-Phishing via Disguised Official Documents Targeting Taiwan and Czech Governments

‍

Threat and Impact

Operation Dragon Weave is a targeted cyber espionage campaign assessed with medium confidence to be associated with a China-based threat actor. Primarily targeting victims in Taiwan and the Czech Republic, the campaign meticulously utilizes spear-phishing baits disguised as official government or administrative documents. Apart from untargeted, mass-malware distribution, this operation is clearly engineered for specific targets, featuring localized filenames and bait content tailored to each geographic region.

Operation Dragon Weave impacts organizations across multiple high-value industries, including government and public sectors, research and academia, technology and software, as well as financial sectors. The profile of the observed victimology strongly indicates an intelligence-gathering objective: government agencies hold political and policy value, research institutions possess sensitive intellectual property, technology companies provide entry points into the broader software ecosystem, and financial institutions hold high-value economic intelligence.

The campaign leverages Microsoft Azure Blob Storage as a Dead-Drop C2 channel. By abusing widely trusted cloud services and communicating over HTTPS, the attackers effectively blend their malicious traffic with legitimate data streams, significantly complicating detection efforts. The final payload supports a wide range of post-compromise activities—including file exfiltration, command execution, process manipulation, network discovery, lateral movement, and in-memory execution. Consequently, affected organizations face severe risks of long-term unauthorized access, covert monitoring, and data breaches.

‍

Analyst Perspective

Utilizing legitimate cloud services as C2 nodes allows attackers to avoid detection and subsequent blocking by concealing their infrastructure, such as IPs and Domains. For enterprises, compromised endpoints appear to be merely connecting to normal cloud services, making it extremely difficult for IT personnel to recognize a breach in real time. Moreover, since the initial access is gained through spear-phishing, it is highly likely that the entire lifecycle of this operation remains completely invisible to the victims, indicating that the primary objective is the covert exfiltration of critical data.

Technical Details

Resource Development

Prior to the intrusion, the threat actor pre-stages cloud infrastructure to support the operation. The primary resource identified is a dedicated Azure Blob Storage account:

• note1ggbbhggdwa1[.]blob[.]core[.]windows[.]net
• Container Path: /note/ats/

The attackers embed a hardcoded Azure SAS token directly into the malware, granting read, write, delete, and upload permissions. This token is valid from March 19, 2026, to March 19, 2027. Such an extended lifespan indicates that the infrastructure is pre-deployed for long-term post-compromise persistence.

Initial Access

The threat actor gains initial access via a spear-phishing ZIP attachment containing:

• 計畫申請審查結果通知單.pdf.lnk (with the disguised filename: Project Application Results Notice)
• _計畫申請審查結果通知單.exe (the disguised filename is as above).

Both the file names and internal text are meticulously tailored to the targeted victims. The .pdf.lnk file utilizes a double extension technique to disguise itself as a standard PDF document, while the executable masquerades as an official document. These Taiwan- and Czech-themed lures heavily reinforce the social engineering efficacy of the campaign.

Execution

The operation supports two distinct execution paths:

Path A: LNK-Based Execution

If the victim clicks 計畫申請審查結果通知單.pdf.lnk, the shortcut triggers the following process chain: wscript.exe → empty.vbs → PowerShell (bypassing execution policies with a hidden window) → Profile.ps1. The primary actions of Profile.ps1 include:

1. Read the contents of 1.dat.
2. Decrypt it via XOR with the hardcoded key P@ssw0rd_am_2026.
3. Write the decrypted payload to disk as RuntimeBroker_update.exe.
4. Move UnityPlayer.dll and Com.dat to %TEMP%.
5. Execute RuntimeBroker_update.exe.
6. Open a lure PDF to distract the user.

Path B: Executable-Based Delivery

If the victim directly executes _計畫申請審查結果通知單.exe, the malware deploys a self-contained Rust dropper. Unlike Path A, this variant does not rely on external staged files inside the ZIP. Instead, it creates the %LOCALAPPDATA%\WebViewFixUtility and drops the following components:

• BrowserViewUtility.exe
• A malicious UnityPlayer.dll
• An encrypted configuration blob
• A lure PDF
• RuntimeBroker_update.exe

This path encapsulates the entire infection chain within a single executable before launching the identical next-stage binaries.

Defense Evasion

Obfuscation and Encrypted Staged Payloads: Multiple components are stored in encrypted or disguised states:

• 1.dat is an XOR-encrypted container housing RuntimeBroker_update.exe
• Com.dat stores the final payload in an encrypted format
• Lure files utilize misleading names and extensions
• The LNK file adopts a Microsoft Edge icon to appear harmless.

DLL Side-Loading: The malware abuses trusted application behaviors by leveraging RuntimeBroker_update.exe or BrowserViewUtility.exe to sideload the malicious UnityPlayer.dll, thereby avoiding the direct execution of an obviously malicious binary.

Sandbox Evasion: RUSTCLOAK conducts anti-analysis checks before decrypting the final payload. It retrieves the host system's computer name and compares it against a hardcoded blocklist of over 100 sandboxes and analyst hostnames. If matched, the loader terminates and stops execution immediately.

In-Memory Execution: RUSTCLOAK avoids traditional thread creation techniques. Instead, it leverages Windows fibers (VirtualAlloc, VirtualProtect, CreateFiberEx, SwitchToFiber) to execute payloads directly in memory, minimizing behaviors frequently monitored by security tools.

Discovery

AZUREVEIL supports several discovery capabilities to assist operators in mapping the victim's environment:

• List Directory contents
• Enumerate logical drives
• List running processes
• List named pipes
• Collect network adapter details (MAC address, IP address, and adapter type)
• Retrieve system uptime and general system information.

Lateral Movement

The final payload can move beyond the initially compromised system. Its command set includes:

• Port forwarding
• SOCKS proxy control
• TCP pivot connections
• UDP pivot connections
• Named pipe communication.

This demonstrates that the malware is engineered not only for endpoint compromise but also for internal pivoting and remote access within the victim network.

Data Collection

AZUREVEIL facilitates collection-oriented operations through its file and output handling functions. The agent can:

• List files and directories
• Read files
• Manage file transfers
• Capture the output of executed tasks.

Notably, it supports Beacon Object File (BOF) execution. The malware can receive a BOF from the C2 channel, load it entirely into memory, execute it within the current process context, and capture the output via a named pipe. This allows operators to perform highly flexible post-exploitation actions without dropping new tools to the disk.

Command and Control (C2)

The most defining technical characteristic of this campaign is its Dead-Drop C2 architecture utilizing Azure Blob Storage rather than the traditional server.

Azure Blob Dead-Drop Workflow

AZUREVEIL communicates with note1ggbbhggdwa1[.]blob[.]core[.]windows[.]net via HTTPS over port 443, enabling its traffic to blend seamlessly into normal enterprise cloud traffic. Instead of interacting directly with the operators, the malware and threat actors co-manage a shared blob container.

The workflow operates as follows:

1. The implant uploads a small, encrypted beacon (around 124 bytes).
2. Attackers place encrypted commands into the same container.
3. The implant fetches and decrypts these commands.
4. The implant executes the commands locally.
5. The implant uploads the results back to the container as an encrypted blob.

Blobs are named with the format: {agent_id}/{timestamp1}_{timestamp2}.bin

The observed agent ID is: 345831bc

This Dead-Drop model eliminates the need for conventional C2 servers and significantly complicates network-level detection, as all outbound traffic leads to a legitimate Microsoft cloud service.

Runtime API Resolution

AZUREVEIL further evades static detection by resolving approximately 87 Windows APIs at runtime using a djb2-based hashing mechanism. It dynamically loads functions from libraries including:

• wininet.dll
• Ws2_32.dll
• Advapi32.dll
• Iphlpapi.dll
• msvcrt.dll

Exfiltration

Exfiltration leverages the exact same Azure Blob Storage channel used for command and control. AZUREVEIL can:

• Upload stolen files to Azure Blob Storage
• Upload encrypted command execution results
• Exfiltrate BOF execution output back to the operator.

By executing C2 and data exfiltration through a single HTTPS cloud channel, the operation minimizes the number of suspicious destinations and ensures exfiltration traffic mirrors routine Azure activity.

Impact

While the campaign appears to be primarily espionage-oriented rather than destructive, the malware still retains capabilities that impact system and data integrity. Its command set allows operators to:

• Delete files
• Move files
• Rename files
• Download files from the C2 to the compromised host.

Even if disruption is not the primary objective, these actions can be actively leveraged to manipulate local data and operational workflows.

‍

Mitigation

Because "Operation Dragon Weave" does not exploit disclosed software vulnerabilities or patchable flaws, defending against it requires defensive controls acrossn email, endpoint, and network monitoring. It abuses user trust, Windows scripting and shortcut behaviors, DLL side-loading, and legitimate cloud infrastructure like Microsoft Azure Blob Storage.

Enhancing User Awareness and Email Security Controls

Organizations should strengthen defenses against spear-phishing attachments, particularly ZIP archives containing disguised files such as double-extension .pdf.lnk shortcuts or other suspicious executables. Users must be trained to treat compressed attachments, shortcut files, and executables masquerading as documents with high suspicion, especially when they claim to be official notifications. Email security controls should flag or quarantine archives containing combinations of LNK, VBS, PS1, DLL, DAT, and EXE files.

Restricting Script and Shortcut Abuse

This operation relies on a chained execution of wscript.exe, VBScript, and PowerShell, combined with bypassing execution policy and hidden execution. To reduce the attack surface, defenders should:

• Restrict or rigorously monitor the use of PowerShell and VBScript
• Alert on hidden PowerShell execution and execution-policy bypasses
• Restrict script interpreters on systems where they are not required for business operations
• Monitor for suspicious process chains, such as .lnk → wscript.exe → powershell.exe.

These configurations may impact administrative automation, logon scripts, and legacy applications that still depend on PowerShell or VBScript. Business dependencies should be validated before enforcing controls.

Preventing Execution from User-Writable Locations

The malware places staged files in locations such as %TEMP% and %LOCALAPPDATA%. Application control policies should block or restrict the execution of scripts, DLLs, and binaries from user-writable directories. This is particularly critical for files like RuntimeBroker_update.exe, BrowserViewUtility.exe, and UnityPlayer.dll, which initiate outside of normal installation paths. Organizations employing allowlisting should also review whether seemingly trusted binaries can be abused to load local malicious DLLs.

This measure may affect software updates, self-extracting installers, and internally developed tools that run from temporary or user profile folders.

Detecting and Blocking DLL Side-Loading Patterns

Monitoring for cases where legitimate executables load unexpected DLLs from the same working directory is vital in countering operations of similar campaigns. Because the infection chain relies on the side-loading of UnityPlayer.dll, security tools should alert when known binaries load DLLs from unusual user-space paths, temporary directories, or newly created folders. Behavioral detection is far more effective than simple file reputation checks in this scenario.

Hardening Cloud-Aware Network Monitoring

Since AZUREVEIL utilizes Azure Blob Storage over HTTPS as a Dead-Drop C2 channel, organizations must not assume that traffic to blob.core.windows.net is inherently benign. Defenders should:

• Monitor outbound connections to suspicious or previously unseen Azure storage accounts.
• Alert on repetitive PUT/GET/LIST/DELETE activities targeting the same blob container.
• Investigate patterns consisting of small, periodic encrypted uploads, command fetches, and results uploads.
• Proactively search the specific indicator: note1ggbbhggdwa1[.]blob[.]core[.]windows[.]net.

This may impact environments that legitimately use Azure Storage. Baseline tuning should focus on anomalous endpoints, processes, temporal patterns, and hosts that do not typically interact with Azure.

Strengthening Memory and Behavioral Detection

This operation employs layered decryption, in-memory loading, and Windows fibers to evade simpler file-based detection. Consequently, endpoint detection should focus on the following behaviors:

• Decrypte DAT payloads into executables.
• VirtualAlloc and VirtualProtect sequences immediately followed by execution behaviors.
• Fiber-based execution patterns.
• In-memory payload loading.
• Suspicious API resolution and post-exploitation behaviors such as shell execution, file exfiltration, proxy forwarding, and BOF-style in-memory module execution.

This is critical because the final payload supports full remote control, file theft, and lateral movement.

Leveraging Published Detection Rules and Indicators of Compromise (IOCs)

Seqrite has published detection names for components of this operation, including:

• Lnk.Trojan.50646.GC
• Trojan.Agent.S38943638
• Script.Trojan.50655.SL
• Script.Trojan.50650.SL

Organizations should utilize published file hashes, file names, and network indicators for retrospective hunting, blocking, and containment. If any of the listed artifacts are discovered, responders should assume the host is fully compromised and investigate for secondary payloads, credential compromise, and data exfiltration.

Incident Response Considerations

If a compromise is suspected, defenders should isolate the affected endpoints, preserve evidence where possible, review script execution logs, inspect %TEMP% and %LOCALAPPDATA% for staged artifacts, and analyze outbound Azure Storage traffic. Given the malware's capabilities for remote command execution, file transfer, and pivoting, incident response should not be confined to a single host but must extend to adjacent systems and user accounts.

Long-Term Improvements

This incident underscores the necessity for organizations to build layered defenses against the abuse of trusted services. Hardening user execution paths, restricting script abuse, enforcing application controls, and increasing cloud-aware detection of Azure Storage traffic represent the most effective long-term mitigations. Because threat actors do not rely on specific patchable vulnerabilities, future prevention must center on reducing phishing success rates, limiting execution capabilities, and improving visibility into endpoint and cloud-backed command-and-control behaviors.

‍

IoCs (Indicator of Compromise)

‍

Network Indicator

‍

Reference

• Operation Dragon Weave: Uncovering a China-Linked Campaign Targeting Czech Republic andTaiwan Using Azure Cloud C2（Seqrite）
• China-AlignedGroups Ramp Up Attacks: Dragon Weave Hits Czech Republic & Taiwan（The Hacker News）
• Silent Push UnearthsAdaptixC2's Ties to Russian Criminal Underworld, Tracks Threat ActorsHarnessing Open-Source Tool for Malicious Payloads（Silent Push)
• Insidethe attack chain: Threat activity targeting Azure Blob Storage（Microsoft Security Blog）