It’s not easy for the threat actors to roam inside the network undetected. But if they can do it, it’s really a lucky day for their hack team. They often try to break into computers undetected. Malware designed for monitoring or spying must operate undetected, but it is also likely to exfiltrate data or exchange messages with its command and control infrastructure, both of which could alert threat hunters to its presence.
DNS Tunneling, which hides messages inside ordinary-looking DNS requests, is one of the stealthy communication techniques used by malware to avoid detection.
DNS tunneling:
DNS Tunneling converts the Domain Name System (DNS) into a hacking tool. DNS, as we all know, is a massive Internet White Page or phone directory. DNS also has a simple protocol that allows administrators to query the database of a DNS server. Thus far, so good. Smart hackers realized they could communicate with a target computer invisibly by inserting commands and data into the DNS protocol. This concept is central to DNS Tunneling.
The Iranian Advanced Persistent Threat (APT) group APT34 recently launched an attack on the Jordanian government using its own innovative version of DNS Tunneling. The payload in the attack was a backdoor called Saitama, which was a finite state machine that communicated via DNS. In this blog, we will go over the methods that Saitama used to hide its DNS Tunneling.
Also Read: How DNS Tunneling works – Detection & Response
Saitama’s DNS tunneling:
Saitama’s DNS tunneling is formed by two major concerns: DNS traffic is still largely unencrypted, so messages must be hidden so their purpose isn’t obvious; and DNS records are frequently cached heavily, so identical messages must look different to reach the APT-controlled name servers.
Saitama’s messages:
Saitama’s domain lookups in the attack on the Jordanian foreign ministry used the following syntax:
domain = message, counter ‘.’ root domain
The root domain is always one of the interchangeable:
- uber-asia[.]com
- asiaworldremit[.]com
- joexpediagroup[.]com
Each lookup’s sub-domain consists of a message followed by a counter. The counter encodes the message and sends it to the command and control (C2) server with each lookup so that the C2 can decode it.
Also Read: DNS sinkholes to Prevent Malware? How did it work?
There are four types of messages that can be sent:
1. Establish contact
- Saitama begins its counter by selecting a random number between 0 and 46655 the first time it is executed. Our randomly generated counter in this example is 7805.
- The DNS lookup derived from that counter is:nbn4vxanrj.joexpediagroup.com
- The counter is encoded using a hard-coded base36 alphabet that the name server also uses. Each digit in base36 is represented by one of the 36 characters 0-9 and A-Z. The standard base36 code for alphabet 7805 is 60t (6 x 1296 + 0 x 36 + 30 x 1). However, 7805 is nrj in Saitama’s custom alphabet.
- The counter is also used to generate a custom alphabet, which will be used to encode the message through a simple substitution. The first message sent home is the command 0, base36-encoded to a, informing the server that it has a new victim, prefixed to the string haruto, resulting in aharuto.
- The message nbn4vxa is obtained by a simple substitution using the alphabet generated by the counter.
- The counter is decoded by the C2 name server using the shared, hard-coded alphabet, and the counter is then used to derive the alphabet used to encode aharuto.
- It responds to the contact request by providing an IP address containing an ID for Saitama to use in future communications. Saitama ignores the first three octets, which can be anything. The ID is contained in the final octet. In our example, we’ll use ID 203:75.99.87.203
Also Read: Threat Hunting using DNS logs – Soc Incident Response Procedure
2. Request a command
- Saitama, now that it has an ID from the C2 server, increases its counter to 7806 and indicates its readiness to receive a command as follows: The counter is used to create a new custom alphanumeric string that encodes the ID, 203, as ao. The counter is encoded to nrc using the malware’s hard-coded base36 alphabet, and one of Saitama’s three root domains is chosen at random, yielding:aonrc.uber-asia.com
- The C2 server responds to the request with the expected payload size for Saitama. Saitama will use this to calculate how many requests are required to retrieve the entire payload.
- The first octet of the IP address with which the C2 responds can be any number between 129 and 255, while the second, third, and fourth octets represent the first, second, and third bytes of the payload, respectively. The payload will be four bytes in this case. — 129.0.0.4
3. Obtain a command
- Saitama sends one or more RECEIVE requests to the server now that it knows the size of the payload it will receive. It starts at 7807 and increments its counter by one each time. Because some command names require more than the four bytes of information that an IP address can carry, this step may necessitate multiple requests. It has been instructed to retrieve four bytes of information in this case, so it will only need to make one request.
- The message from Saitama is made up of three parts: the digit 2, which indicates the RECEIVE command; the ID 203; and an offset, which indicates which part of the payload is required. These are base36-encoded individually and concatenated together. The message k7myyy is encoded using a custom base36 alphabet derived from counter 7807.
- The counter is encoded using nr6’s hard-coded alphabet, and one of Saitama’s three root domains is chosen at random, yielding:k7myyynr6.asiaworldremit.com
- Using two-digit integers, the C2 indicates which function it wishes to run. It can instruct Saitama to perform one of five different tasks:
- In this case, the C2 desires to execute the command ver via Saitama’s Cmd function. (The C2 indicated in the previous request that it would send Saitama a four-byte payload: one byte for 70 and three bytes for ver.)
- The C2 responds by using the first octet of the IP address to indicate the function it wishes to run, 70, and the remaining three octets to spell out the command name ver using the ASCII codepoints for the lowercase characters “v,” “e,” and “r”:70.118.101.114
4. Execute the command
- Saitama executes the command given to it and sends the output to the C2 server via one or more DNS requests. Each time, the counter is increased by one, starting at 7808 in our example. Multiple requests may be required in this step because some command names require more than the four bytes allowed by an IP address. — p6yqqqqp0b67gcj5c2r3gn3l9epztnrb.asiaworldremit.com
- The counter is encoded with nrb’s hard-coded alphabet, and one of Saitama’s three root domains is chosen at random.
- In this case, the message is divided into five parts: Digit 2 indicates the RECEIVE command; the ID 203; an offset indicating which part of the response is being sent; the buffer size; and a twelve-byte chunk of the output. These are base36-encoded individually and concatenated together. The message is encoded using a custom base36 alphabet derived from the counter 7808, giving us p6yqqqqp0b67gcj5c2r3gn3l9epzt.
Also Read: Latest IOCs – Threat Actor URLs , IP’s & Malware Hashes
Detection-IOCs:
Maldoc
- Confirmation Receive Document.xls
- 26884f872f4fae13da21fa2a24c24e963ee1eb66da47e270246d6d9dc7204c2b
Saitama backdoor
- update.exe
- e0872958b8d3824089e5e1cfab03d9d98d22b9bcb294463818d721380075a52d
C2s
- uber-asia[.]com
- asiaworldremit[.]com
- joexpediagroup[.]com
Source/Credits: https://blog.malwarebytes.com/threat-intelligence/2022/05/how-the-saitama-backdoor-uses-dns-tunnelling/
Hunting Queries
Splunk
(dest_host="uber-asia.com" OR dest_host="asiaworldremit.com" OR dest_host="joexpediagroup.com")
Qradar
SELECT UTF8(payload) from events where ("Hostname" = 'uber-asia.com' or "Hostname" = 'asiaworldremit.com' or "Hostname" = 'joexpediagroup.com')
SumoLogic
(host = "uber-asia.com" OR host = "asiaworldremit.com" OR host = "joexpediagroup.com")
LogPoint
destination.domain:("uber-asia.com" OR "asiaworldremit.com" OR "joexpediagroup.com")