GorillaBot: Technical Analysis and Code Similarities with Mirai

Editor’s note: The current article is authored by Mohamed Talaat, a cybersecurity researcher and malware analyst. You can find Mohamed on X and LinkedIn. 

In this article, we’re diving into GorillaBot, a newly discovered botnet built on Mirai’s code. It’s been spotted launching hundreds of thousands of attacks across the globe, and it’s got some interesting tricks up its sleeve.  

We’ll walk through how it talks to its command-and-control (C2) servers, how it receives instructions, and the methods it uses to carry out attacks.  

Overview 

“GorillaBot” is a newly discovered Mirai-based botnet that has been actively targeting systems in over 100 countries. According to the NSFOCUS Global Threat Hunting team, the botnet issued more than 300,000 attack commands between September 4 and September 27. 

This malware variant poses a serious cyber threat, affecting a wide range of industries — including telecommunications, financial institutions, and even the education sector — prompting an urgent need for response and mitigation. 

Key Takeaways 

• GorillaBot is a Mirai-based botnet that reuses core logic while adding custom encryption and evasion techniques. 

• It targets a wide range of industries and has launched over 300,000 attacks across more than 100 countries. 

• The botnet uses raw TCP sockets and a custom XTEA-like cipher for secure C2 communication. 

• GorillaBot includes anti-debugging and anti-analysis checks, exiting immediately in containerized or honeypot environments. 

• The malware authenticates to its C2 server using a SHA-256-based token generated from a hardcoded array and server-provided value. 

• Attack commands are encoded and hashed, then passed to a Mirai-style attack_parse function for execution. 

Technical Analysis  

In this section, we will examine the technical details of GorillaBot, focusing on its C2 communication protocol and how it receives information about its targets and the attack methods it’s instructed to use. 

Anti-Debugging  

Before proceeding with its main activity, GorillaBot performs checks to detect the presence of debugging tools. One of its first actions is to read the /proc/self/status file and inspect the TracerPid field. This field indicates whether the process is being traced – a value of 0 means it’s not, while a non-zero value suggests a debugger is attached. 

Learn more about evasion in malware

Another technique that “GorillaBot” uses to detect debuggers is to register a callback function that will pause and then exit upon receiving a SIGTRAP signal. 

Environment check  

GorillaBot is highly selective about the environment it runs in. It first ensures that it is operating on a legitimate target machine rather than inside a honeypot or container. To do this, it performs several checks for system-level artifacts that may not be present in those scenarios. 

The code shows that it initially checks for access to the “/proc” file system – a virtual file system that provides user-space processes with information about the kernel and running processes.  

In a typical Linux environment, the presence of the “/proc” file system is expected. If it’s missing, GorillaBot assumes it is being analyzed in a honeypot and exits immediately. 

GorillaBot uses another check to detect Kubernetes containerization by examining a specific file in the “/proc” directory, namely “/proc/1/cgroup.” It looks for the string “kubepods.” If this string is found, GorillaBot recognizes that it is running in a container and terminates its execution to avoid detection. 

Encryption & Decryption Algorithms  

One of the more intriguing features of this Mirai-based botnet is its use of encryption and decryption techniques to obscure key strings and hide internal configuration data.

Researchers observed that GorillaBot uses a simple Caesar cipher with a shift of 3 to decrypt specific strings. In addition, it employs a custom block cipher – which we’ll examine later in this article – to decrypt more complex internal configurations. These methods help the malware avoid static detection and make reverse engineering more difficult. 

Network Communication  

Initial C2 Communication  

Like many other Mirai-based botnets, GorillaBot uses raw TCP sockets for command-and-control (C2) communication, rather than higher-level protocols like HTTP or HTTPS.  

Learn to analyze malware’s network traffic

The process begins with the malware establishing a connection to its C2 server – the server’s IP address is decrypted at runtime using what appears to be a custom implementation of the XTEA (Extended Tiny Encryption Algorithm).  

The cipher closely resembles TEA or XTEA, employing a 128-bit (16-byte) hardcoded key for both encryption and decryption. 

During each iteration of the algorithm, a delta value is subtracted from the sum. 

The function begins by calculating the length of the provided data. It does this by iterating until it encounters the first NULL character.  

Once the length is known, it proceeds to pack the key. Since the key is given as a serialized sequence of bytes, it must be organized into an array of four 32-bit words before the function can perform either encryption or decryption. 

After the key is prepared and the data length calculated, the function checks a mode parameter to decide whether to encrypt or decrypt. It then enters a loop to iterate over the data for either process.

GorillaBot authentication mechanism with the C2 server   

After successfully connecting to the C2 server, the malware initiates the authentication process to identify itself to the server.  

This process begins with the malware sending a 1-byte TCP probe packet to the C2 server. In response, the server replies with a 4-byte TCP packet that includes a “magic” 4-byte value. This value is then used to generate the bot ID for the authentication process. 

View analysis in ANY.RUN’s Interactive Sandbox

The process begins with a returned 4-byte magic value, which is combined with a 32-byte encrypted array to generate the bot ID or authentication token.  

A key aspect of this process is the method used to combine the 32-byte array with the 4-byte magic value to create the token.  

The same cipher previously described is applied to decrypt the 32-byte hardcoded array. Once decrypted, the data is copied into a separate buffer and concatenated with the 4-byte magic value. 

The combined data is then hashed using SHA-256 before being sent back to the command and control (C2) server as the identification token. 

In the screenshot below, you can see the generated SHA-256 token, which is created by combining the 4-byte magic value received from the C2 server with the decrypted 32-byte hardcoded array. 

The C2 (Command and Control) communication process continues after the C2 server authenticates the botnet.  

In response, the server sends a packet that appears to be a flag, labeled “01,” to confirm the bot’s authenticity. On the C2 server side, most likely a list of hashes representing botnet IDs, such as SHA-256, is maintained. This list is used to verify the received ID, ensuring that the connection is from a legitimate bot instance rather than an unauthorized source attempting to interact with the C2 infrastructure. 

In the screenshot above, after successfully sending the SHA-256 hash (bot ID), the bot receives a 1-byte response. This response is checked against “01,” which indicates successful authentication. Following this, the bot replies with a 4-byte packet containing the bytes “00 00 00 01.” This is likely the bot acknowledging receipt of the flag packet. 

After, GorillaBot exhibits behavior similar to the original Mirai bot. The malware calculates the length of a provided 32-byte ID buffer and sends this length to the command and control (C2) server. Once the length is successfully sent, the malware transmits the actual ID buffer to the server. 

The code snippet above is taken from the leaked Mirai source and includes a check for the number of arguments. If a second argument is provided, it is copied to “id_buf,” which has a length of exactly 32 bytes.  

This behavior is consistent with that observed in the Mirai-based variant “GorillaBot.” During its initial communication with the command-and-control (C2) server, GorillaBot first sends the length of the buffer, followed by the buffer itself – mirroring the original Mirai implementation. 

The screenshot below summarizes the initial C2 communication, validating the connection to ensure it comes from the intended source. This is crucial so that only authenticated connections receive attack commands. 

Processing Attack Commands  

Once the bot has been authenticated, the next stage in the C2 communication process involves receiving a packet containing attack target information – essentially, instructions to initiate an attack. 

In the example screenshot below, we can see that the first step taken is to read the length of the packet. This confirms the malware’s ability to retrieve data over the socket from the command and control (C2) server.  

After successfully reading the length, the malware proceeds with execution. It reads the expected length of the attack packet, then uses that length to read the corresponding number of bytes from the C2 server, which constitutes the attack packet. 

Attack Command packet structure  

Below is the structure of the received attack packet along with the corresponding packet capture bytes. The time gap in receiving the length of the entire packet (highlighted in red in the capture) and the actual attack packet is minimal. As a result, it may seem as if they were concatenated into one packet and received simultaneously; however, they were actually received separately. 

The packet structure is quite simple. First, there is a 32-byte hash of the entire received packet, referred to as SHA-256 (highlighted in yellow). Following this, the encoded bytes represent the attack command (highlighted in blue), which will be decoded using the same Caesar shift cipher mentioned earlier before being parsed. 

Struct attack_pkt { 

uint16_t expected_pkt_length; 

char encoded_cmd_sha256_hash[SHA256_BLOCK_SIZE]; 

char encoded_cmd[ENCODED_CMD_LENGTH]; 

};

Once the integrity of the encoded attack command is verified, it is decoded and passed to “attack_parse.” This function is responsible for extracting target information, determining the specific attack method, and then handing off control to the appropriate attack function for execution.

The “attack_parse” function closely resembles the original Mirai code, as it processes the provided buffer containing the attack command in a similar manner. Notably, it supports attack commands both with and without options, just like the original Mirai. 

Conclusion 

GorillaBot may not reinvent the wheel, but it’s a strong reminder that old code can still pack a punch when reused in clever ways. By building on Mirai’s foundation and adding its own tweaks to communication, encryption, and evasion techniques, GorillaBot proves that legacy malware lives on and evolves. 

To better understand threats like GorillaBot, the use of malware analysis tools like ANY.RUN’s Interactive Sandbox is important. It lets you dive into live malware behavior: from unpacking encrypted payloads to monitoring C2 communication in real time. 

Curious to see it in action? Try ANY.RUN now to explore malware samples like GorillaBot hands-on and uncover the tactics they use during attacks to strengthen your defenses. 

About ANY.RUN

ANY.RUN helps more than 500,000 cybersecurity professionals worldwide. Our interactive sandbox simplifies malware analysis of threats that target both Windows and Linux systems. Our threat intelligence products, TI Lookup, YARA Search, and Feeds, help you find IOCs or files to learn more about the threats and respond to incidents faster.

Request free trial of ANY.RUN’s services → 

Indicators Of Compromise  

Hashes 

b482c95223df33f43b7cfd6a0d95a44cc25698bf752c4e716acbc1ac54195b55 (View sandbox analysis)  

IP Addresses and Domains  

http://193[.]143[.]1[.]70 (C2 server) 

193[.]143[.]1[.]59 (C2 server) 

The post GorillaBot: Technical Analysis and Code Similarities with Mirai appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More