Introduction: Context
DDoSia, an attack toolkit used to perpetrate Distributed Denial of Service (DDoS), has been created and utilized by the hacktivist nationalist group NoName057(16), which is supportive of Russia. This group primarily targets countries that have expressed criticism towards the Russian invasion of Ukraine.
The DDoSia project was initiated on Telegram in early 2022. The main Telegram channel of NoName057(16) attracted thousands of subscribers.
Originally developed in Python, DDoSia utilized CPU threads to simultaneously initiate multiple network requests. It initially relied on the HTTP protocol for Command & Control (C2) communication, with JSON configurations distributed by the C2 server.
In April 2023, Avast published an article that examined the network flow between DDoSia users and the C2. In response, the administrators of DDoSia released a new version of their sample the day after. This updated version introduced an additional security mechanism aimed at concealing the list of targets transmitted from the C2 to the users.
Cyberoo IRT analyzed the latest version of the tool, released during December 2023, to discover the decryption mechanism and extract the list of targets in the json file.
Compared with the previously analyzed versions, NoName057(16) has completely revised the authentication mechanism, making the analysis even more complex and introducing an additional encryption layer.
Analysis: execution and communication of the tool
Figure 1 – Execution of the tool
Upon execution of the malware, it initiates a POST request to the URL hxxp://[IP]/client/login in order to authenticate with the Command & Control (C2) server. In the cookie header there are 2 values; U and C, and in the body field a JSON file with the encrypted content.
Figure 2 – Capturing traffic during the login process
If authentication is successful (as in Figure 2), the server responds with an epoch.
Then, upon successful authentication, the client makes an additional call to retrieve the target list:
Figure 3 – GET call to retrieve the target list
The call differs only in 2 parts from the login call: User-Agent and Cookie, in which an additional “K” value appears with a base32-encoded string.
If the call is formatted correctly, the server responds with an encrypted JSON of variable length, depending on the number of targets targeted by the attacks (as in Figure 3).
The User-Agent used during the calls is taken randomly from a list within the executable.
Figure 4 – Non-exhaustive list of User-Agents
The encryption algorithm used during login and target recovery is AES-GCM.
Reverse Engineering of the executable file
The effort NoName057 expends in developing the client is high, and the result is clearly visible during reverse engineering of the binary.
Static analysis is difficult due to the nature of the binary (written in the Go language), and dynamic analysis, as well as step-by-step debugging, had to be added.
After the static analysis and debugging sessions, Cyberoo carped the information and steps needed to retrieve the target list. Below are all the steps to log in:
- Creation of the “Cookie” header with the 2 parameters U and C:
- U: Hash provided by NoName’s Telegram bot to perform authentication (contained in the client_id.txt file)
- C: GUID of the pc that is running the tool, obtained by reading the registry key “HKLM\SOFTWARE\Microsoft\Cryptography\Machine Guid + PID of the process
- Body JSON: the body that is sent is the result of AES-GCM encryption + base64 encoding of the result and formatting in JSON. The encryption key is obtained from the subtracted GUID of the first 10 characters + the pid + a final “0” (example: 630-4d81-a47f-3aa052407e33-21080).
The plain-text content of the body is a JSON with a variety of pc information, such as the name, execution timestamp, the last 27 characters of the client_id.txt hash, the full GUID, CPU numbers, operating system version, and architecture. In addition there is a “key” value containing 17 alphanumeric characters randomly generated during each execution.
No personal or identifiable data is present.
Steps to retrieve the target list:
- Creation of the exact same header used during authentication, with the addition of the “K” parameter, obtained by randomly generating a string of 260 alphanumeric characters, later encoded in base32.
- When called, the C2 response contains a JSON with the “date” field, containing a blob encoded in base64 and encrypted always in AES-GCM.
- The decryption key is the exact same one used during the initial encryption in the login phase.
Below is a description of how to retrieve the IV and TAG values needed to decrypt the data:
- IV calculation – nonce:
- Take the ciphertext, decode it in base64;
- Take the 24 first characters and convert them in bytes.
- TAG calculation:
- Take the ciphertext, decode it in base64;
- Take the 32 last characters convert them in bytes.
The ciphertext refers to the base64 converted data field value, with the exclusion of the first 24 characters (12 bytes) and the last 32 characters (16 bytes). By applying this modification, it becomes feasible to retrieve the plain text value of the data field.
Figure 5 – Deciphered target list
The decrypted data field contains the target full list.
Conclusion
The analysis of the DDoS tool highlights the significance of reverse engineering and threat intelligence in understanding its functionality, identifying potential vulnerabilities, and developing effective countermeasures.
After the tool analysis, Cyberoo wrote a private tool to have a real-time overview of the target list and provide intelligence to all its clients through the CSI platform.
