Configs

Dridex is configured with configuration files. These files specify, among other things, which website urls should be redirected and where. The targets of the redirects are also listed in section redirects. Now and then, the config files also deliver new supernodes. Those are separately listed in the supernodes section.

The configuration files can also deliver executables. Those are listed in section modules. The modules blocks originally contained full binaries. I replaced them with hashes. All modules in Dridex are identified by crc32 checksums, when known, the "name" matching the CRC32 is also listed. Neither the hashes, nor name are part of the config delivered by Dridex.

In version 3 of Dridex, the configuration files where delivered in XML format with descriptive tag and attribute names. In the current version 4, the configuration is delivered in a binary format without the helpful textual hints as to what the fields do. I tried to replicate the format from v3 as good as possible, but not all fields might be named appropriately.

Only config files from the last 90 days are shown.

Network

Redirect Servers

Traffic to the targeted websites is redirected to servers controlled by the Dridex operators. The following table shows servers from the config files of the last 180 days.

Supernodes

Supernodes are ordinary infected clients, that were "promoted" by Dridex to relay traffic of regular infected clients. The owners of the IPs are in no way related to the Dridex operation. Do not block these IP addresses, only use them to detect Dridex infections in your own network.

The supernodes from the last 100 days. The columns added and removed show the time whenthe supernodes appeared in and disappeared from a config file. The columns firstseen and lastseen show when the supernode last responded to a Dridex ping. These pings are encrypted by the Dridex network protocol, hence, responding clients arealmost certainly infected by Dridex.Those marked with "" were active with the last 3 days, i.e.,either responded to a ping or were seen in Dridex config. those with "" were inactive.

Modules

Dridex uses various modules:

• The loader module is used to infect the client. They use an infrastructure independent from the actual Dridex operation. Loaders are not listed here, as they are mostly delivered by email.
• The bot module is the core of Dridex v4. It is the only module found on regular clients, apart from traces of the loader. Bots are listed in section bots.
• Supernodes and clients that are otherwise interesting to the Dridex operators (e.g., clients in corporate networks), are equipped with additional modules. For example, the socks module is used to redirect traffic from other infected clients, the vnc module is used to inspect clients before upgrading them to supernodes, or to spy on corporate machines.

Bots

Dridex bots are distinguished by a version number and timestamp. For each version, there are often multiple different hashes and timestamps, which is a result of recompiling and repacking the modules.

Auxiliary Modules

The auxiliary modules are often off-the-shelf, legitimate binaries (e.g., VNC or the socks proxy). These modules are updated much less frequently than Dridex bots.

Dridex v4 uses CRC32 checksum in lieu of names. In some instance, the names behind the CRC checksums are known. In other cases, the names are missing. In these cases only the CRC32 checksum is shown.

Exports

Yara Rules

Snort Rules

CSV

CSV file of the bot MD5s, the supernodes of the last 100 days, and the redirects of the 180 days.