ChunkRift: Technical Analysis and Lineage of a Modular Win64 Backdoor

In this article

ChunkRift research artwork with disassembly, Windows, registry and memory motifs — Conceptual research artwork. Its decorative interface elements are not evidence of specific malware behavior; technical findings are documented below.

Key findings

A 2,450,944-byte x64 SmallDrop wrapper decrypts the 534,016-byte inner agent named ChunkRift.
Control selects from 64 deterministic DuckDNS candidates on TCP 406; module delivery uses a separate hard-coded HTTP service on TCP 408 in this build.
Modules are versioned in a Registry cache, then manually mapped into no-window cmd.exe processes.
Public August specimens support a common code lineage. No named operator is attributed.

The investigation began upstream of the executable. A ClickFix-style page asked a visitor to paste a command, and the chain ended in a modular Win64 backdoor. We named the recovered inner agent ChunkRift.

Delivery chain

From a pasted command to the inner agent

A fake Cloudflare/cashback verification page instructed the visitor to paste clipboard-delivered PowerShell.
soft-storage[.]top served a user-agent-dependent PowerShell stage. The stage cleared the clipboard and PowerShell history artifacts and contained a protection-weakening path when elevated.
It retrieved a Base64-encoded PE from 193.148.56[.]147/final_check?=8128133291/vc.
The decoded 2,450,944-byte x64 SmallDrop wrapper held AES-256-CBC-encrypted payload material.
Decryption recovered the 534,016-byte x64 ChunkRift inner agent.

The published inner-agent analysis was static. The inner agent was not executed.

Six-stage infection chain from ClickFix lure to PowerShell, SmallDrop, and ChunkRift — Figure 1. End-to-end static reconstruction of the observed campaign and recovered components. Select the figure to inspect it at full size.

ChunkRift delivery-chain artwork from the earlier article design conversation — **Original concept infographic.** The artwork labels a recovered PE as 3,267,928 bytes. The analyzed SmallDrop wrapper is 2,450,944 bytes and the inner agent is 534,016 bytes. The technical report figure and article text provide the verified details. Select the image to inspect it at full size.

Two-channel design

Control and module delivery are separate

ChunkRift profiles the host, derives a machine ID, parses tasks, and tracks task IDs to process IDs. It uses WebSocket tasking on TCP 406 and a separate HTTP service on TCP 408 for raw PE modules. The core can therefore remain stable while server-side module types and parameters change.

Component	Recovered role
Core implant	Host profiling, machine ID, task parsing and PID tracking
Control plane	WebSocket over TCP 406
Module plane	HTTP GET /task/<type> over TCP 408
Module cache	Versioned Registry-backed chunks
Execution layer	Custom x64 PE mapping in no-window cmd.exe hosts

Control plane on TCP 406 and module plane on TCP 408 with Registry cache and PE mapper — Figure 2. The core implant, controller candidate space, and separate module service. Select the figure to inspect it at full size.

ChunkRift architecture artwork from the earlier article design conversation — **Original concept infographic.** The 64 DuckDNS candidates are generated deterministically, not a hard-coded pool. The decorative Run-key panel and broad elevation label are not proven behavior of this core. The technical report figure and article text provide the verified details. Select the image to inspect it at full size.

Infrastructure

Sixty-four controller candidates, one configured module service

The control logic generates 64 candidate DuckDNS hostnames matching ^(?:lav|ini){6}\.duckdns\.org$. This reconstructable space is broader than any single hostname observed in one run. In the September build, the module repository is separately hard-coded at 45.91.202[.]146:408, requested with GET /task/<type>.

Static analysis exposes the full candidate space; it does not show that all 64 hosts were active. The full candidate list is included in the archival research package.

Core mechanics

How a task becomes a module process

Tasking, cache lookup, host-process creation, and custom PE mapping form one execution path. The recovered code starts C:\Windows\System32\cmd.exe with CREATE_SUSPENDED | CREATE_NO_WINDOW, resumes the initial thread, and maps the requested module into that process. It uses NtAllocateVirtualMemory, NtWriteVirtualMemory and NtCreateThreadEx; the mapper handles x64 relocations, imports, and TLS callbacks.

Internal execution flow

From controller task to module entry point

Implementation path reconstructed from the recovered core; a live module catalog was not observed.

01WebSocket taskThe core parses createtask and tracks task ID to PID.
02Resolve moduleVersioned cache lookup, or HTTP GET /task/<type> on TCP 408.
03Prepare hostStart cmd.exe with CREATE_SUSPENDED | CREATE_NO_WINDOW; resume its initial thread.
04Map PEAllocate and write remote memory; apply x64 relocations, imports and TLS callbacks.
05Start moduleNtCreateThreadEx transfers execution with the operator supplied parameter.
06Track lifecycleTask/PID association supports subsequent management, including closetask.

Figure 3. Static reconstruction of the core's task and process execution path. The steps depict code capability, not an observed execution of the inner agent.

ChunkRift internal execution artwork from the earlier article design conversation — **Original concept infographic.** The Registry cache is for module reuse; reboot persistence was not proven. The generic privilege labels in this concept image do not establish observed execution of those paths. The technical report figure and article text provide the verified details. Select the image to inspect it at full size.

Module system

Registry chunks and remote memory

Downloaded modules are split into versioned REG_BINARY chunks under HKCU\Software\WinRAR\Libs. Temporary chunks become finalized cache entries and can be reassembled for execution. The same task lifecycle connects that cache to a no-window host and an operator-controlled module parameter.

Module and memory lifecycle

A registry cache feeds a memory mapper

Two linked paths explain why a module may have no standalone executable on disk.

Store and retrieve

1HTTP response provides a raw PE module.
2Temporary versioned REG_BINARY chunks are written beneath HKCU\Software\WinRAR\Libs.
3*_tempchunk_* entries are promoted to finalized *_chunk_* cache entries.
4Chunks are reassembled for a later task.

Map and run

5No-window cmd.exe becomes the host process.
6Memory allocation and writes place the image in the remote process.
7The mapper resolves relocations and imports, handles TLS, then starts a remote thread.
8The core associates the task with its process ID.

Figure 4. Versioned module storage and the x64 memory execution path. This describes recovered implementation behavior; module payloads and downstream objectives were not observed.

ChunkRift module and memory lifecycle artwork from the earlier article design conversation — **Original concept infographic.** The image's HKLM Run key and explorer.exe/svchost.exe examples are illustrative. The recovered path uses HKCU\\Software\\WinRAR\\Libs and a no-window cmd.exe host; elevation invocation was not independently proven. The technical report figure and article text provide the verified details. Select the image to inspect it at full size.

Hunting only for a dropped secondary executable would miss this design. The Registry entries, process creation, remote memory writes and network request belong to the same chain.

Code lineage

How ChunkRift relates to Dacic labels

Public August 2026 specimens clustered as Generic.Dacic.18358 share an import hash and distinctive task/cache vocabulary with the September inner agent. Those implementation anchors support a very-high-confidence common code lineage independent of the label. Microsoft uses Dacic as a Defender family name; that naming is retained for discoverability, not treated as actor attribution.

Timeline of related August specimens and the observed September ChunkRift campaign — Figure 5. Public same-lineage specimens precede the September campaign. Named operator attribution remains unsupported. Select the figure to inspect it at full size.

Detection opportunities

Correlate the distinctive sequence

Investigate a pasted command as the beginning of a chain, including PowerShell staging and history clearing; retain centralized script, process and network telemetry.
Correlate TCP 406 with the generated DuckDNS namespace, WebSocket first-frame byte 0x82, and fixed client mask 12 34 56 78.
Look for the module service on TCP 408, GET /task/<type>, and an eight-character lowercase hexadecimal User-Agent.
Join HKCU\Software\WinRAR\Libs values matching *_tempchunk_* and *_chunk_* with no-window cmd.exe, remote writes and NtCreateThreadEx.

The recovered code includes a CMSTPLUA COM elevation implementation using CLSID {3E5FC7F9-9A51-4367-9063-A120244FBEC7}. Its invocation through the protected orchestration path was not independently proven.

Defanged indicators

Artifacts for investigation

Role	Indicator
Lure	captcha-fortnite-cashback[.]info
PowerShell stage	soft-storage[.]top
Payload retrieval	193.148.56[.]147
Module service	45.91.202[.]146:408
Control	TCP 406 / WebSocket; 64 candidate DuckDNS hosts
Controller cache	HKCU\Software\Microsoft\EventSystem, value System
Module cache	HKCU\Software\WinRAR\Libs

Full hashes and the 64-host candidate list are in the research record. These indicators describe the examined campaign and build.

Evidence boundary

Methodology and limits

The analysis used static reverse engineering of recovered components, inner-PE decryption, protocol reconstruction, registry-cache analysis, and custom-loader examination. It separates observed campaign artifacts, code-level implementation and inference.

No reboot-persistence mechanism was proven in the analyzed core. The live server-side module catalog was not observed, so downstream objectives cannot be inferred from this core alone. The inner agent was not executed, and no named threat actor is attributed.

Archival publication

Full technical report

ChunkRift: Technical Analysis and Lineage of a Modular Win64 Backdoor
WhatIsMyWebInfo Research. Version 1.0 · 20 September 2026 · Zenodo.

Read the report · DOI 10.5281/zenodo.22860703

Researcher: Josh Grant · ORCID 0009-0003-9022-4410