Breaking Dridex Malware

### Overview Presented at the FIRST Conference 2021 by Gustavo and Felipe Dominguez of Immunity (part of Appgate), this presentation explores the internal mechanisms of the Dridex banking trojan—focusing specifically on the Dridex loader. The researchers outline Dridex's modular architecture, unpack the loader, decrypt internal strings and command-and-control (C2) configurations, automate IOC extraction using Python, and exploit weaknesses in the malware's dynamic Windows API resolution routine to create an effective host vaccine.

### Key Topics - **Dridex Architecture and Infection Chain**: Delivery typically starts via an infected Microsoft Office file that drops or executes the Dridex loader. The loader communicates with C2 infrastructure to download the main bot (handling keylogging, web injections) and additional modules such as VNC or a SOCKS proxy. - **Unpacking the Loader**: Dridex loaders utilize custom packers where the payload is decrypted into memory without touching disk. Monitoring `VirtualAlloc` and `VirtualProtect` calls or using tools like Hollows Hunter enables analysts to dump the unpacked executable. - **Encrypted Strings and C2 Infrastructure**: Binary strings reside encrypted in the `.rdata` section using RC4, where the first 40 bytes serve as the key. C2 commands are stored as CRC32 hashes (e.g., the command string `bot`). In recent variants, C2 IP addresses and the botnet ID are held as structured byte arrays within the `.data` section, and initial check-ins transmit encrypted system reconnaissance data (computer name, installed software list, botnet ID). - **Automated Analysis Toolkit**: The authors developed the Python-based "Dridex Analysis Toolkit" alongside an IDA script. The toolkit parses PE headers, unmaps memory dumps to disk, extracts C2 IPs, and decrypts RC4 strings and network communication keys. - **Dynamic API Resolution**: To conceal API calls from the PE import table, Dridex resolves Windows APIs at runtime by computing CRC32 hashes of loaded DLL names and exported functions via the Process Environment Block (`PEB` -> `LDR_DATA`). If a required library is not yet loaded, Dridex searches the system directory (such as `SysWOW64`) and loads it using `ntdll!LdrLoadDll`. - **Developing a Vaccine via CRC32 Hash Collision**: Because Dridex identifies DLLs solely by 32-bit CRC32 checksums without verifying signatures or full paths, it is vulnerable to hash collisions. By brute-forcing a matching uppercase filename ending in `.dll` (targeting a library loaded by the malware, such as `shell32.dll`), researchers constructed a surrogate DLL exporting identical API names. Placing this collided DLL into `SysWOW64` forces Dridex to load the custom implant instead of the genuine library, triggering code that halts the thread and cleanly exits the process.

### Technical Details - **String Encryption**: RC4 with a 40-byte prepended key stored in `.rdata`. - **Network & C2 Protocol**: Command strings identified by CRC32; initial telemetry encrypted using RC4 keys stored in decrypted string blobs. - **Dynamic Loader Weakness**: Dridex traverses `SysWOW64` comparing uppercase candidate DLL file names against hardcoded 32-bit CRC32 values. - **Vaccine Implementation**: Brute-forced custom DLL matching the CRC32 of `shell32.dll` with matching exported API names in `exports.def`, placed in the DLL search path to intercept loading, alert, and terminate execution.

### Takeaways While not an overarching silver bullet across future malware variants or instances where target libraries are already pre-loaded into memory, deploying host-level vaccines against weak API hashing algorithms provides an effective containment and remediation tactic during incident response. In addition, automating the extraction of C2 servers, botnet IDs, and RC4 keys enables defenders to feed blacklists and accelerate triage without relying on manual dynamic analysis.