Environmental Entropy and SIDT-Keyed Payloads: Dissecting a Paranoiac Windows RAT (Part 2)

In Part 1, we examined how this sample combines layered Petite packing, environment-sensitive decryption, and continuous integrity checks to prevent stable analysis. The unpacking chain, the use of SIDT-derived key material, and repeated validation routines all contribute to execution paths that diverge across environments.

That analysis was produced by Zenyard Agent from reverse engineering artifacts without prior labeling or analyst-provided context, showing that both unpacking and payload reconstruction depend on execution state rather than static structure. As a result, static extraction and naive sandboxing can produce incomplete or incorrect representations of the payload.

In this part, we focus on how that design extends into cryptographic routines, protocol structure, and detection opportunities, with emphasis on behaviors that remain stable across executions despite environment-dependent obfuscation.

Cryptography and Key Derivation

The sample does not use recognizable library cryptography. Instead, it implements custom byte-wise transforms and derives key material from mutable runtime state.

During initialization, one key routine reads a 32-bit value, replaces it briefly under a LOCK operation, restores the original, and applies arithmetic adjustments before returning the result. Separate invocations generate distinct values for different stages.

Key constants observed in the sample include:

• 0xF5374200 in the transformation path
• 0x7F99CAC2 in an anti-debug predicate

Payload decryption proceeds in two stages. The first applies an additive transformation using key material stored deeper in the buffer. The second applies a rolling XOR whose state evolves during execution.

for each byte:
    buf[i] = buf[i] + key_stream[i + 0x61]

rolling_key = rolling_key ^ (rolling_key >> 8)

for each byte:
    buf[i] = buf[i] ^ rolling_key_byte

Incoming message decryption follows a simpler process, but still depends on execution state established earlier, including floating-point context.

C2 Protocol Design and Network Fingerprinting

The implant uses raw TCP with line-delimited messages and strips \r\n before dispatch. Messages are capped at 0x1000 bytes and split into four logical fields before being processed.

Session state is maintained across exchanges through internal structures that track message counters, session state, and buffer references. The design suggests a structured command protocol rather than simple payload delivery.

The most stable network characteristic is derived from beacon generation:

tag = ((runtime_value + 0x20F645EA) & 0xFFFFFF00) | 0x99

The low byte is forced to 0x99, which remains constant regardless of runtime variation. This provides a practical detection pivot even when payload content is encrypted.

The C2 address is not embedded in the binary and must be supplied at runtime using -I <host>. Static analysis therefore reveals protocol behavior but not infrastructure.

Attribution Considerations

There is insufficient evidence to attribute this sample to a known malware family or threat actor. While the filename contains references to known families, the implementation does not support a reliable match.

The combination of layered packing, runtime infrastructure injection, and extensive anti-analysis is consistent with bespoke tooling or heavily customized builds rather than commodity malware deployed in default form.

The most reliable conclusion concerns engineering approach. The sample reflects a deliberate emphasis on analysis resistance and operational flexibility.

Detection Opportunities

Detection should prioritize behavior and protocol characteristics over static indicators.

Network-level signals include:

• raw TCP communication with line-delimited messages
• four-field message structure
• maximum message size of 4096 bytes
• recurring tag values with a low byte of 0x99

Host-level and behavioral signals include:

• process execution with -I <host> argument
• empty Import Address Table with runtime API resolution
• user-mode SIDT execution
• deliberate INT 3 exceptions during early execution
• non-standard I/O port access
• repeated unpacking and memory modification behavior

In memory and CPU telemetry, additional signals include x87 state manipulation around decode routines, self-modifying writes outside image boundaries, and repeated validation of global state.

Conclusion  

The behaviors examined in this part reinforce that the sample is not designed to conceal functionality through static obfuscation alone, but to ensure that correct interpretation depends on execution context. Cryptographic routines derive key material from mutable runtime state, and protocol handling is tightly coupled to that same state. As a result, decrypted artifacts, message flows, and even intermediate values are products of a specific execution environment rather than fixed properties of the binary.

At the network level, the design separates protocol structure from infrastructure. The command-and-control endpoint is supplied at runtime, while communication behavior remains consistent across executions. This shifts detection away from infrastructure-based indicators toward protocol-level characteristics. The enforced 0x99 low byte in beacon generation, combined with structured message handling over raw TCP, provides a more stable basis for identification than domain or IP artifacts.

From a defensive perspective, the sample highlights the limits of approaches that rely on static extraction or isolated indicators. Reliable analysis requires visibility into execution semantics, including memory reconstruction, CPU state interaction, and protocol behavior. The most useful detection signals are those that survive environmental variation, including SIDT execution in user mode, runtime API resolution with minimal static imports, and invariant properties of the communication layer.

Appendix: Indicators of Compromise (IOC Table)