The Log4j vulnerability that came to light at the end of the year can undoubtedly be considered a major event in the security community. Honeypot and botnet are our bread and butter, and we have been concerned about which botnets would be exploiting this since the vulnerability was made public. This morning we got the first answers, our Anglerfish and Apacket honeypots have caught 2 waves of attacks using the Log4j vulnerability to form botnets, and a quick sample analysis showed that they were used to form Muhstik and Mirai botnets respectively, both targeting Linux devices.

Sample Analysis


This wave propagates a new variant of miria, which has made the following changes compared to the initial code.

  1. table_init/table_lock_val/table_unlock_val and other mirai-specific configuration management functions have been removed.

  2. The attack_init function is also discarded, and the ddos attack function is called directly by the command processing function.

Also, a uy top-level domain is chosen for its C2 domain name, which is also rare.


Muhstik, a botnet we disclosed in 2018, is a variant of Tsunami that borrows from the Mirai code. In this captured sample, we note that the new Muhstik variant adds a backdoor module, ldm, which has the ability to add an SSH backdoor public key with the following installed backdoor public key.

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQBtGZHLQlMLkrONMAChDVPZf+9gNG5s2rdTMBkOp6P7mKIQ/OkbgiozmZ3syhELI4L0M1TmJiRbbrIta8662z4WAKhXpiU22llfwrkN0m8yKJApd8lDzvvdBw+ShzJr+WaEWX7uW3WCe5NCxGxc6AU7c2vmuLlO0B203pIGVIbV1xJmj6MXrdZpNy7QRo9zStWmgmVY4GR4v26R3XDOn1gshuQ6PgUqgewQ+AlslLVuekdH23sLQfejXyJShcoFI6BbH67YTcoh4G/TuQdGe8lIeAAmp7lzzHMyu+2iSNoFFCeF48JSA2YZvssFOsGuAtV/9uPNQoi9EyvgM2mGDgJ

After the public key is added to the ~/.ssh/authorized_keys file, the attacker can directly log into the remote server without password authentication.

Considering the special vulnerability mechanism of log4j2, Muhstik takes a blunt approach to spread the payload aimlessly knowing that there will be vulnerable machines, and in order to know who has been infected, Muhstik adopts TOR network for its reporting mechanism.

Before accessing the TOR network, Muhstik queries relay.l33t-ppl.inf through some publicly available DoH services(see the list beflow). During this process, a number of DNS requests are generated. Note: The following domains are not C2 domains but DoH service providers, depends on the situation, readers might be able to use the list to crosscheck their network for possible infections if they are not expect DoH usage on their network.

When it is not possible to report infect information directly from the TOR network, Muhstik will try to use TOR's public mapped domains, the list of relevant domains is as follows

Muhstik's ELF sample has the following codes.:

We can see that the sample supports DDoS and backdoor commands. The C2 of the sample is stored in a mirai-style configuration with the following configuration information in plain text.:

 [0x02]: "listening tun0\x00", size=15
 [0x03]: ""\x1f\x90"listening tun0\x00"l", size=30
 [0x04]: "\x1f\x90", size=2
 [0x05]: "\x00", size=22
 [0x06]: "\x00", size=22
 [0x07]: "\x00", size=22
 [0x08]: "\x00", size=22
 [0x0a]: "/proc/\x00", size=7
 [0x0c]: "/exe\x00", size=5
 [0x0d]: "/status\x00", size=8
 [0x0e]: "/fd\x00", size=4
 [0x0f]: "\x58\x4D\x4E\x4E\x43\x50\x46\x22\x00", size=33
 [0x10]: "zollard\x00", size=8
 [0x11]: "muhstik-11052018\x00", size=17
 [0x12]: "\x02^nL\x0b\x1a\x06_nL\x02\x0f\x00", size=13
 [0x13]: "eth1\x00", size=5
 [0x14]: "lan0\x00", size=5
 [0x15]: "-\x00", size=2
 [0x16]: "eth0\x00", size=5
 [0x17]: "inet0\x00", size=6
 [0x18]: "lano\x00", size=5
 [0x19]: "\x00", size=22
 [0x1a]: "\x00", size=22
 [0x1b]: "d4cf8e4ab26f7fd15ef7df9f7937493d\x00", size=33
 [0x1c]: "\x00", size=22
 [0x1d]: "\x00", size=14
 [0x1e]: "\x00", size=14
 [0x1f]: "\x00", size=14
 [0x20]: "\x00", size=14
 [0x21]: "\x00", size=14
 [0x22]: "\x00", size=22
 [0x23]: "\x00", size=22

The is C2, which resolves to The author registered a domain starting with log perhaps intentionally to fit the Log4j vulnerability.


Considering the huge impact of the Log4j vulnerability, we expect more botnets to support it to spread. We will keep an eye on this and will share new observations here.

Contact us

Readers are always welcomed to reach us on Twitter or email us to netlab at 360 dot cn.