DomainTools 101: Looking at Greenbug’s DNS Tunneling in ISMDoor with DomainTools Iris Investigate
Greenbug
The Greenbug group first reported by Symantec in 2017 has continued to operate and make use of its ISMDoor malware that uses AAAA records for C2 signalling—essentially using DNS for tunneling. DNS tunneling continues to be an effective technique as many companies do not monitor their DNS traffic for anomalies. Therefore, the ISMDoor malware has been active as recently as November 2019. While most of the domains used as C2s are sinkholed, this is a good opportunity to hunt for infrastructure used by ISMDoor and learn about how this malware works.
At DomainTools we have analyzed and mapped the coverage of all passive DNS providers in Iris Investigate to provide the most visibility and relevance possible into Internet infrastructure. Thanks to the specific fingerprints of the ISMDoor malware we can keep an eye on current activity and reference past activity through Iris Investigate by looking for AAAA records that return those expected results containing the static IPv6 response fingerprints. All of this is within a few pivots inside the Iris Investigate platform after we understand how ISMDoor works.
ISMDoor DNS Signaling
The way the Greenbug C2 signaling works is rather simple. Each bot in the network will generate a unique session ID when it needs to contact the C2 for a command. It will then reach out and query against the C2 domain with that session ID. The C2 domain’s nameserver will then respond with a static IPv6 address to acknowledge the session. A query and response pair looks like:
Notice this IPv6 address is outside the global unicast scope for valid addresses—one red flag to look for if one monitors their DNS. The bot then responds with an encoded message query that receives another static response from the C2 domain’s nameserver that looks like:
Once again, this is outside the IPv6 global unicast scope. The bot then sends along the total message count to the C2 nameserver that responds with another address which signals receipt with all space characters.
Next, the bot will then reach out and ask the C2 domain how many messages it should receive counting from 0. In response the attacker’s nameserver sends back an IPv6 address that is static except for the last 8 bytes which will indicate the number of messages the bot should expect to receive from the C2.
The bot then completes the transaction by requesting the messages as follows:
In addition to these initial message types, the bot and C2 domain will use encoded DNS queries to exfiltrate data and confirm receipt of the chunked apart messages as well as other command signaling. Since these messages vary—usually responses containing specific sequences to be resent and being end padded by nibbles of 2020—they are harder to look for in passive DNS. Luckily, the session establishment is easy enough to fingerprint that we should be able to look for that activity and the set up of new C2 domains.
Bringing It Into Iris Investigate
If we look at the session establishment of the ISMDoor malware we can see a couple of unique addresses that we could hunt for in passive DNS even if we do not know the specific C2 domain registered, namely:
a67d:db8:a2a1:7334:7654:4325:370:2aa3
a67d:db8:85a3:4325:7654:8a2a:370:7334
2020:2020:2020:2020:2020:2020:2020:2020
4f6b:2020:2020:2020:2020:2020:2020:2020
While the message number indicator may also be useful, it’s hard to query in bulk for those considering there are over four billion combinations. Iris can’t currently search for just the chunk of an IPv6 address in a AAAA record due to the limitations of providers, but perhaps that will be possible in the future. For now, though, we can pull in those static addresses and use them to hunt for new and old ISMDoor C2 domains.
By choosing to “Search By Response” and selecting a record type of “AAAA” with the first static address we will see a range of responses:
Click “Send Domain Results to Pivot Engine” in the bottom right of the page to take these found domains and create a query in the Iris Investigate Pivot Engine for further examination.
Before examining those domains, we can gather more by using the second address which results in an even larger volume of responses with varying messages and file transfers that were caught in passive DNS. We can actually decode a lot of these using a tool written by Dennis Schwarz of NETSCOUT that we can find on GitHub.
This time use the “Add As An OR Query” from the “Send Domain Results to Pivot Engine” dialog to make sure we include all of the domains. Lastly, by using the response of all spaces—a very anomalous DNS response— can get the most recently observed C2 domains for ISMDoor in passive DNS.
Now that we’ve found all of the C2 domains, let’s flip over to the “Pivot Engine” tab in Iris Investigate. We’ll notice that many of the older domains have been sinkholed, but we have a total of 19 domains to work with after querying passive DNS—a much larger start than when we just had a single C2 domain and a few odd IPv6 addresses. For the domains that haven’t yet been sinkholed we can see one winrepp[.]com being hosted on Digital Ocean.
If we pivot on that IP we can see another set of questionable domains—many classified by DomainTools Risk Score as a high likelihood for malware.
Grabbing another pivot point in Iris Investigate on one domain’s IP—this time outbrainsecupdater[.]com—we’ll unearth another 37 domains. From there, checking our new sets of domains in passive DNS we can confirm those that have been involved as an ISMDoor C2 at one point or another. For example the new domain microsoft-publisher[.]com stands out due to the captured AAAA query seen below:
From here a simple rinse and repeat will continue to reveal ISMDoor C2 domains as they crop up unless they change their tunneling techniques. Using these same techniques we can find other DNS tunneling malware in passive DNS such as Backdoor.Win32.CllEcker or Backdoor.Win32.Denis.
