Operation QUICSILVER: Reconstructing and Testing the VHD-Delivered Backdoor

Executive summary

Operation QUICSILVER is a reported espionage campaign that used diplomatic and regional-cooperation themes to target Myanmar-related organizations. Its delivery chain is notable for placing a disguised shortcut, a decoy PDF, a small FTP command script, and two payload fragments inside a virtual hard disk. The script joins the fragments into Windowsupdate.exe and starts the reconstructed backdoor.

We examined a seven-file indicator corpus inside a restored, isolated Windows malware-analysis VM. Static inspection reproduced the published payload byte for byte. The reconstructed file was 7,046,656 bytes and its SHA-256 was:

cd147efe37003399e174951927e5fe727a4481756b116f0204a14a64cc62b059

That value exactly matches the Windowsupdate.exe indicator published by Seqrite. In one direct-payload runtime case, the executable started as a 64-bit High-integrity process and created a SystemIn shortcut in the current user's Startup folder. MalwareINFO Pro reported THREATS OR SUSPICIOUS MATCHES FOUND and displayed seven Zero-Day findings, while also showing unavailable hash-database coverage and degraded real-time memory protection.

Those limitations matter. This article does not turn one heuristic result into a confirmed verdict, does not claim that every published network behavior was reproduced, and does not attribute the campaign independently.

Reporting and attribution

Seqrite's primary technical report describes April, June, and July 2026 campaign waves using Holiday Notice, Training Announcement, and ACMECS-related lures. Seqrite assesses a China nexus with moderate confidence and describes the payload as a Go 1.20 backdoor named QUICAgent.

The Hacker News provides a useful secondary overview of the same research. We treat it as secondary coverage rather than independent technical corroboration. Campaign history, victimology, attribution, C2 design, encryption details, and command capabilities in this article remain credited publisher reporting unless explicitly labeled as our lab observation.

Lab scope and safety boundary

The original archive was preserved unchanged on the host. Its SHA-256 was:

446c09e3ced078f3f70460bac61b665ba60863d9e39c67bcf066ff962f328f17

All extraction, reconstruction, and execution occurred only in a disposable VMware guest restored to a named analysis snapshot. Shared folders, drag-and-drop, clipboard integration, and automatic network connection were disabled before sample work. The virtual NIC remained disconnected throughout runtime observation.

We opened the VHD as an archive for static inspection; we did not mount it. We executed only the independently reconstructed payload. The original VHD/LNK infection chain was not activated, no real C2 was contacted, no attacker commands were emulated, and no sample or evidence was uploaded to an external service.

Reconstructing the delivery chain

The archive contained seven SHA-256-named members. Hash verification matched every member name. Two members were dynamically expanding VHD files of 14,716,928 bytes. The file mapped by the publisher to TrainingAnnouncement.jpg contained:

• a 1,911-byte Windows Shell Link presented as TrainingAnnouncement.pdf.lnk;
• a 106,591-byte PDF 1.7 decoy;
• a concealed underscore-directory chain;
• a 214-byte FTP command script; and
• two payload fragments named header.doc and body.doc.

The script directly showed the intended local chain: open the decoy PDF, concatenate header.doc and body.doc in binary mode into %LOCALAPPDATA%\Windowsupdate.exe, start the result, and quit.

Both fragments were exactly 3,523,328 bytes. Joining header.doc first and body.doc second produced the expected 7,046,656-byte executable and exact published SHA-256. This was a strong identity check: our reconstructed bytes were not merely similar to the reported payload; they were identical under SHA-256.

VHD
  -> PDF-looking LNK
  -> ftp.exe -s:
  -> decoy PDF + copy /b of header.doc and body.doc
  -> Windowsupdate.exe
  -> Startup persistence + resolver retry/failover activity

Supplemental disk and shortcut forensics

The analyst also supplied a separate, non-execution static-forensics handoff for review. We did not repeat every low-level measurement during our MalwareINFO VM session, so the additional findings in this section remain attributed to that supplemental review rather than being presented as our independent runtime observations.

That review reports that the Training and ACMECS containers have the same 14,716,928-byte size, dynamic-VHD structure, FAT12 filesystem, PDF volume label, VHD UUID, disk GUID, partition GUID, and January 13, 2026 creation timestamp. A byte-level comparison found 99.9650878% identical bytes, with only 5,138 differing bytes across 28 of 28,744 512-byte blocks. Recycle Bin metadata in the ACMECS variant reportedly referenced a deleted E:\_\TrainingAnnouncement.pdf entry dated June 26, 2026.

Taken together, those facts strongly support a clone-and-edit lure template rather than two independently constructed disk images. They do not, by themselves, identify the template author.

The same supplemental parsing gives the Training shortcut a target of %SystemRoot%\System32\ftp.exe, a scripted -s: argument pointing into the nested underscore path, a PDF icon, and a minimized/inactive show mode. It also reports builder hostname desktop-stv6gg and Chinese-language volume-label metadata meaning “My Disk.” These are useful cluster artifacts, but they can be copied, reused, or planted; they are not proof of an operator's nationality.

One delivery gap also remains important. The content mapped to TrainingAnnouncement.jpg is a VHD, but an ordinary .jpg double-click does not inherently mount a VHD. The supplied artifacts do not establish whether the original name had a hidden .vhd extension, whether a delivery mechanism renamed it, whether the victim was instructed to attach it, or whether another intermediate step existed.

Static findings and classifier ambiguity

The reconstructed payload was a 64-bit Windows GUI executable. ExeInfo showed a conventional PE entry point in .text and no overlay. The separate HolidayNotice.pdf.exe sample was also a 64-bit Windows GUI executable and was classified by the tool as Go 1.20.

For the exact reconstructed Windowsupdate.exe, ExeInfo labeled the compiler as MinGW-w64/GCC. That classification is not necessarily mutually exclusive with the stronger Go evidence: the heuristic may reflect native/CGO-related characteristics, while recovered Go build metadata and Go-specific symbols provide stronger evidence for the application's primary implementation. The supplemental metadata identifies go1.20, module agent, compiler gc, trimmed paths, CGO enabled, and target windows/amd64.

The supplemental review parsed the reconstruction as PE32+ x86-64 with 12 sections, image base 0x140000000, entry-point RVA 0x10F6, a zero PE timestamp, no Authenticode signature, no Rich header, and no observed overlay. It measured overall entropy at approximately 6.256 bits per byte. These properties do not resemble a conventionally high-entropy packed executable.

Dependency records include quic-go v0.40.1, qpack v0.4.0, qtls-go1-20 v0.4.1, and Go crypto, network, system, and text modules. This makes QUIC/HTTP/3 capability stronger static evidence than a generic protocol string alone.

We also reviewed the saved IDA database supplied under the case folder. The 149,189,917-byte windowsupdate.exe.i64 file had SHA-256 16ea388124846c36d9104a01d6920d6df1557db4a9d925e451e3426aafaf73c7. A bounded string query recovered 75 distinct main.* names, including main.NewAgent, main.resolveServerURLs, main.antiDebugObfuscation, main.addToStartupFolder, main.rc4Encrypt, main.rc4Decrypt, Agent.executeCommand, Agent.sendHeartbeatWithRetry, Agent.uploadFile, Agent.downloadFile, and Agent.listDirectory. The supplemental inventory adds host collection, heartbeat and failover, working-directory management, chunked transfer, COM launch, and vectored-exception-handling names. These are static reverse-engineering evidence; they do not prove that every function ran.

The C2 evidence requires provenance separation:

• The supplemental artifact recovery found appupdate[.]0cmds20cj2cdf8[.]workers[.]dev/A3cmf0q9ASCion and regupdate[.]eamakfu49dc28wa[.]workers[.]dev/vere0zme82cad.
• Seqrite publishes appupdate[.]0cmds20cj2cdf8[.]workers[.]dev/A3cmf0q9ASCion and regupdate[.]eamakfu49dc28wa[.]workers[.]dev/vere0zme82cadre.
• register[.]mediumser[.]com was not reported as a hardcoded payload string in the supplemental review. Seqrite observed it being returned dynamically by a Worker.
• 38[.]60[.]244[.]141 and 104[.]64[.]211[.]22 are historical/runtime infrastructure, not interchangeable embedded strings.
• UDP/443 traffic is supported by the QUIC dependency and Seqrite's dynamic capture, but it was not observable on our disconnected interface.

Artifact discrepancy: Seqrite's published article shows the second Worker path ending in /vere0zme82cadre, while the supplemental artifact recovery reports /vere0zme82cad. We preserve both values with provenance rather than silently normalizing the difference.

The supplemental disassembly also reports that the RC4 key is assembled at runtime from four little-endian immediate constants rather than stored as one full plaintext string. Reassembled, those constants yield Seqrite's published MySecretEncryptionKey2025!@#$% value. This explains why a strings-only rule for the complete key may miss the artifact. It does not make passive QUIC traffic decryptable: the outer QUIC/TLS session would still require session secrets or process-level pre-encryption/post-decryption capture.

Finally, the supplemental certificate extraction identifies a self-signed ECDSA P-384 CA with subject and issuer C=US, O=RAT System, CN=RAT CA, serial 1, and CA basic constraints. The correct interpretation is attacker-controlled private-CA trust, not immutable leaf-certificate pinning: a controller could present different leaf certificates signed by the embedded CA.

Direct MalwareINFO runtime observations

The retained case contains three separate executions: Process Monitor PID 644, Deep API Trace PID 3556, and Process Capture PID 6704. They share the exact executable SHA-256, but we do not merge their events into one process history.

PID 644: direct Process Monitor run

The exact reconstructed file was launched from the guest analysis directory. Process Monitor recorded image name windowsupdate.exe, parent PID 3656, 64-bit architecture, High integrity, an August 25, 2026 18:33:30 guest-local start time, and the exact image and command-line path.

The process remained active until it was manually ended. The run exceeded the intended 90-second ceiling during the observation handoff and lasted approximately 11 minutes; we record this as a lab-procedure deviation. Once the exact PID was established, Task Manager ended PID 644 and a follow-up search showed no matching process.

The late-applied Process Monitor filter retained 29 displayed events, including thread creation and exit, process exit, file close, and registry access categories. Several registry paths were truncated in the visible table, so we do not infer specific registry modifications from them.

PID 3556: debugger-conditioned Deep API Trace

The saved Deep API Trace package binds PID 3556, process-start ticks 639232581720487685, and the exact payload SHA-256. It ran from 12:36:15Z to 12:38:25Z through the x64 DeepNative collector using worker protocol api-trace-worker-deep-v6.

The chronology matters. The malware called IsDebuggerPresent, which returned true under the debugger-based collector at sequence 689. The analyst then approved a memory-only override. Subsequent affected records are marked AnalystModified, so the persistence and resolver behavior below is debugger-conditioned rather than pristine, unmodified execution. We do not claim what the malware would have done without that intervention.

The trace recorded a 287-byte WriteFile to %TEMP%\create_lnk_4021289944.ps1, creation of hidden powershell.exe -WindowStyle Hidden -ExecutionPolicy Bypass -File ... as child PID 4264, and deletion of the script. The separate PID 6704 memory handoff recovered a 287-byte PowerShell script body as strong cross-run corroboration. The exact script body and the traced 287-byte WriteFile came from different process instances, so they are not presented as same-run evidence.

Repeated DnsQueryEx and GetAddrInfoW activity targeted both Worker hosts. The retained stream contains 92 DnsQueryEx observations and 46 GetAddrInfoW observations, split evenly across the two hostnames. All 46 captured GetAddrInfoW results returned 11001 (WSAHOST_NOT_FOUND), even though the export's generic result field labels those rows Success; the numeric return value is the more specific evidence. The trace never progressed to a confirmed successful resolution or C2 session.

Successive same-host lookups formed an approximately 5.2-second resolver retry/failover loop. That is an offline pre-C2 observation under unresolved-host conditions. It is distinct from Seqrite's reported five-second C2 heartbeat and does not reproduce beacon traffic.

Two datagram sockets were opened and closed, but no retained send, recv, WSASend, WSARecv, QUIC session, or successful C2 exchange was established. The trace also observed memory allocation/protection and thread-control APIs, but no continuous allocate-write-protect-execute chain. Common Go runtime activity and debugger instrumentation are plausible contributors, so these calls are not labeled injection.

Startup persistence observed

The direct PID 644 run created a new SystemIn shortcut in:

%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup

Explorer reported a modified time matching the initial execution minute and a size of 1,009 bytes. Shortcut properties identified the target as the exact windowsupdate.exe analysis path. This is direct lab evidence of Startup-folder persistence and matches the persistence technique described by Seqrite. Because we ran the payload from the analysis directory rather than %LOCALAPPDATA%, the shortcut correctly pointed to the actual executed copy.

Disconnected-interface result

Wireshark captured on the guest Ethernet interface during the run and stopped with No packets captured. The virtual NIC was deliberately disconnected, so zero captured frames are expected. This does not validate or refute Seqrite's reporting that QUICAgent resolves infrastructure through Cloudflare Workers and communicates over QUIC on UDP port 443. It demonstrates only that our disconnected interface observed no traffic.

What we did not reproduce

Our lab did not reproduce:

• the original delivery-to-VHD-mount step;
• dynamic LNK -> ftp.exe execution;
• a successful Worker HTTP response;
• register[.]mediumser[.]com resolution;
• a successful QUIC/HTTP/3 C2 connection;
• RC4-encrypted beacon traffic;
• attacker tasking;
• shell command execution from the C2;
• file upload or download through the C2;
• exfiltration; or
• named-group attribution.

These behaviors remain publisher-reported or statically supported where noted. Their absence from an intentionally disconnected, debugger-conditioned lab run is unavailable evidence, not a benign verdict.

MalwareINFO telemetry and analysis limitations

Deep Trace coverage and source-health reconciliation

The Deep Trace package retained 1,996 ordered events. Its derived views classified 1,632 as exact API calls and attributed all 1,632 to call sites; six of ten dynamic-import-resolution sequences were fully attributed. Coverage was incomplete: 26 events were dropped, the final collector drain reported a gap, and several configured exports remained unavailable.

Source-health metadata reported several Guard sources as NotStarted, even though 132 Guard Network records, 4 Guard File records, and 1 Guard Process record were present in the retained event stream. We therefore treat this as a reporting/state-reconciliation inconsistency rather than evidence that those sources produced no telemetry. Guard Registry and Sysmon had no equivalent retained records in this package.

The trace retains AlertOnly authority with no automatic containment. Its behavior model produced Low Observed Risk at 7/100 with evidence confidence 69/100; this is a feature-local behavior score, not a malware probability or family verdict. All four required high-level behavior chains remained incomplete, and the reconstruction contained no malware findings or ATT&CK ledger entries.

Explorer scan interpretation

We used Explorer Scan with Malware INFO on the exact reconstructed payload. The scan completed one file in 12 seconds and displayed:

• THREATS OR SUSPICIOUS MATCHES FOUND;
• hash databases: unavailable;
• HEX signatures: 0 match(es), with one rule loaded;
• YARA: 0 match(es), with 15 rules loaded;
• Zero-Day: 7 finding(s), with one eligible file; and
• findings: Zero-Day Observed (49).

The application simultaneously showed Real-time Protection: Memory Degraded. No file was unreadable or skipped, and we did not invoke quarantine, deletion, process termination, or another response.

This is partial/degraded analysis coverage, not full-stack detection validation. The parenthetical 49 is exact UI evidence, not malware probability, confidence, severity, independent confirmation, or response authorization. The normal Explorer Scan's 0 YARA matches must also remain separate from the supplied case handoff's failed isolated Payload Analysis YARA worker enrichment; a worker failure is unavailable coverage, not a valid negative detection.

Process Capture and Payload Analysis boundaries

The separate PID 6704 Process Capture manifest reports a completed 47,041,125-byte full user-mode dump with SHA-256 b1ad45f6ea736d0b3bc5014842822311c39f79faec4dea7ae4b89fbce08da3b0. The dump inventory contained 22 loaded images, seven threads, 332 memory regions, 227 committed regions, and 41 executable regions. It reported zero private executable regions; that inventory value does not prove that injection never occurred.

Payload Analysis produced 77,022 evidence records in six verified chunks. It streamed and hashed the complete dump while retaining the first 16,777,216 bytes for bounded static inspection. Its seven capability findings were analyst-review hypotheses derived from strings and API-name inventory, not observed calls. The package retained zero runtime-observed API calls, no joinable API timeline, an empty process-identity list, partial static retention, and a resource-limit warning. It therefore kept the dump as runtime context only, set finalCisoEligible to false, and refused exact call-site-to-dump attribution. Final CISO was not run.

The Payload Analysis network assessment recovered the same two Worker hostnames but did not claim successful communication or probable exfiltration. This is cross-run corroboration only; it must not be fused with PID 3556 without a verified session binding.

Holiday branch and deleted-artifact context

The supplemental handoff treats HolidayNotice.pdf.exe as a related but distinct branch. It reports Go 1.20 and the same QUIC library family, while assigning www[.]maui-cocktailbar[.]com specifically to the Holiday sample rather than to the reconstructed Training/ACMECS payload. It also reports an embedded one-page Belgian–Myanmar holiday-calendar PDF at offset 0x410840, recovered size 287,438 bytes, and SHA-256 7b95b2170a3e943f6a96e78f69d32f4f6245fe0084dd4d14303061abd1ec51de. We did not execute or independently extract that branch during this VM case.

The deleted VHD artifacts reportedly include documents themed around BIMSTEC, ASEAN/UN activity, Myanmar–Malaysia developments, diplomatic activity, China-related briefings, and virtual training. Their presence is consistent with a lure-development or staging workspace, but their precise provenance cannot be established from these containers alone. They should not be described as documents stolen from victims without additional evidence.

One deleted revision reportedly contains a Chinese note stating that portions of the document may have been AI-generated, with the note removed in a later revision. The defensible inference is limited: it suggests possible AI-assisted lure drafting. It does not show that AI wrote the malware, operated the campaign, or reveals the operator's nationality.

There is also a date discrepancy worth preserving. Seqrite's prose says the ceremony was scheduled for Saturday, July 3, 2026. The supplemental artifact reading says the Burmese decoy itself states Friday, and July 3, 2026 was in fact a Friday. This appears to be an editorial discrepancy in the public report, not a change to the malware analysis.

Detection opportunities

The most useful detections combine execution context, artifact identity, and follow-on behavior. A single filename, API name, or QUIC connection is not sufficient by itself.

Additional controls include inspecting file type by content rather than extension, alerting on scripted ftp.exe use, monitoring per-user Startup shortcut creation, and reviewing outbound UDP/443 or Worker-host resolution in context. Broadly blocking QUIC can create substantial false positives; correlation with the delivery chain, exact payload identity, and persistence behavior is stronger.

Observed-versus-reported ATT&CK context

These mappings organize evidence; they do not independently increase confidence, severity, malware score, or response authority.

Indicators of compromise

Hashes are presented exactly because they are inert identifiers. Network indicators are defanged.

Publisher-reported network indicators:

• register[.]mediumser[.]com
• 38[.]60[.]244[.]141
• 104[.]64[.]211[.]22
• maui-cocktailbar[.]com
• appupdate[.]0cmds20cj2cdf8[.]workers[.]dev/A3cmf0q9ASCion
• regupdate[.]eamakfu49dc28wa[.]workers[.]dev/vere0zme82cadre

Supplemental artifact-recovered resolver URLs:

• appupdate[.]0cmds20cj2cdf8[.]workers[.]dev/A3cmf0q9ASCion
• regupdate[.]eamakfu49dc28wa[.]workers[.]dev/vere0zme82cad

Conclusion

The strongest conclusion from this lab is narrow but useful: the supplied corpus reconstructed to the exact published payload, that payload executed as PID 644, and it created SystemIn Startup persistence. A separate, debugger-conditioned MalwareINFO Deep Trace of PID 3556 recorded the transient PowerShell persistence script and repeated resolver attempts for both embedded Worker hosts; all 46 captured GetAddrInfoW results returned 11001, and no successful C2 session was retained. The separate PID 6704 capture added bounded memory corroboration without creating a verified cross-session API binding.

Supplemental static forensics add strong evidence of a clone-and-edit VHD lure template, precise shortcut mechanics, Go/QUIC dependencies, and distinct infrastructure branches. The MalwareINFO Pro Explorer scan surfaced suspicious Zero-Day evidence, but hash databases were unavailable and real-time memory protection was degraded, so its coverage was partial/degraded rather than full-stack validation.

Successful Worker responses, QUIC/HTTP/3 C2, RC4-encrypted beaconing, attacker tasking, command execution, transfer or exfiltration, the original delivery-to-mount step, and named-group attribution were not reproduced. The artifacts support technical linkage to the operational or builder cluster described by Seqrite, but they do not independently identify a named threat group.