RC4 In-Place Section Decryption

Malware encrypts one or more PE sections (commonly .text, .data, and the import table) with RC4 at build time, then decrypts them in-place at runtime using a hardcoded or derived key. This hides code and imports from static analysis tools until execution.

Detection / Fingerprint

• High-entropy sections (7.8–8.0) in .text or .data
• Section names null-filled or randomized (anti-signature)
• VirtualProtect calls early in entry to change section permissions to RWX before decryption
• Key-scheduling algorithm (KSA) followed by pseudo-random generation (PRGA) loops in entry code
• Absence of meaningful strings in .text before runtime

Implementation Patterns Observed

In the SilverFox RC4 loader variant (139329dc9), the .text section (0x22C00 bytes, entropy 7.998) is decrypted with a 28-byte key derived from XOR-obfuscated API strings. The stub uses PEB-walking to resolve VirtualProtect before decrypting, ensuring zero static imports are needed for the decryptor itself.^[pefile.txt:95] ^[r2:fcn.14002b8a0]

Reproduce on Your Own VMs

TODO: Add C reproducer using OpenSSL RC4_set_key / RC4 to encrypt a dummy PE section, then decrypt at runtime with VirtualProtect + in-place XOR.

Defensive Countermeasures

• Memory dumping at entry-point + first API call to capture decrypted code
• Entropy-based detection on .text sections > 7.5
• Emulator-based unpacking with RC4 KSA/PRGA pattern recognition

Pages Where Observed

• silverfox RC4 loader variant (139329dc9)
• unclassified-dotnet-crypter-loader (AES-GZip, not RC4, but same in-place section decryption concept)