Doki – Undetected Backdoor New to the Ngrok Botnet Campaign


Friday, July 31st, 2020 |

Doki is a fully undetected backdoor for Linux that, despite being uploaded to VirusTotal in January of 2020, has managed to remain undetected for over six months. It utilizes the Dynamic (Dyn) DNS service and a unique Domain Generation Algorithm (DGA) based on the Dogecoin cryptocurrency blockchain in order to find its Command and Control (C2) server in real time.

The backdoor is multi-threaded and uses the embedTLS library for cryptographic functions and network communications and when executed, the malware will create a separate thread in order to handle all C2 communications. The first stage is generating a C2 domain to communicate with by using its unique DGA. In order to craft the C2 address, Doki performs the following four steps:

  1. Query dogechain.info API, a Dogecoin cryptocurrency block explorer, for the value that was sent out (spent) from a hardcoded wallet address that is controlled by the attacker. The query format is: https://dogechain.info/api/v1/address/sent/{address}
  2. Perform SHA256 on the value returned under “sent
  3. Save the first 12 characters from the hex-string representation of the SHA256 value, to be used as the subdomain.
  4. Construct the full address by appending the subdomain to ddns.net. An example domain would be: 6d77335c4f23[.]ddns[.]net

Using this technique, the attacker controls which address the malware will contact by transferring a specific amount of Dogecoin from their wallet. Since only the attacker has control over their wallet, only they can control when and how much currency to transfer, thus allowing them to switch the domain to meet their needs. Thanks to the immutable and decentralized nature of the blockchain, this method provides a strong layer of protection against law enforcements agencies attempting to disrupt the infrastructure of the backdoor and against security products attempting to filter malicious domains. It’s important to note that once the domain is generated by the malware, a result of “46927e019820” is ignored, which is generated when no Dogecoin was transferred from the wallet (“0.000000”.) If this domain is generated, the malware will exit without continuing further.

Next, the malware contacts its generated C2 domain via HTTPS and downloads a shell script using the URL <c2_address>/update.sh and saving the returned data as /tmp/update.sh. It will then resolve the current process’s PID and path to be used as script arguments, and proceeds to execute the script by running: /bin/sh -c ./update.sh <process_id> <process_path>.  The main thread of the malware then reads from STDIN, expecting to receive binary data from the shell script. The arguments are passed to the script in order to allow it to communicate with the malware in this way and receive code to execute. If data is received via STDIN, the malware saves itself as a file under /tmp, choosing its name randomly from a predefined list of Linux kernel modules. While this deception method is very basic, it is not commonly seen in Linux malware, which typically do not disguise themselves as system files. Finally, the malware proceeds to fork so the child process executes the file and the main process loops to repeat the malware’s logic flow.

The Doki malware is used part of the ongoing Ngrok Botnet campaign that has been ongoing for over two years at this point. The campaign itself is rather effective and is capable of infecting any misconfigured Docker API server in a matter of hours after it is first configured. This attack is very dangerous due to the fact that the attacker uses ‘container escape’ techniques to gain full control of the victim’s infrastructure. Researchers at Intezer claim that it takes only a few hours from when a new, misconfigured Docker server is configured online to become infected by the Ngrok campaign.

To help prevent against this type of attack, security experts suggest that both companies and individuals who own container servers in the cloud immediately fix configuration issues to prevent exposure. This includes, but is not limited to checking for exposed ports, verifying the existence of no foreign or unknown containers among the existing containers, and monitoring for excessive use of resources.


Sources:


IOCs:

  • 4aadb47706f0fe1734ee514e79c93eed65e1a0a9f61b63f3e7b6367bd9a3e63b
  • 6d77335c4f23[.]ddns[.]net
Share this: