Generative AI has been around for nearly a decade, strictly speaking, but the recent boom in this technology has inspired renewed interest in its possible applications to challenges facing the information security community. Finding these challenges entails searching through a very large haystack consisting of brand-new binaries, documents, domains and other artifacts that flood the web every day.
In this blog post, we provide a deep dive into Check Point’s ongoing use of such a model to sweep across this haystack, and routinely thwart malicious campaigns abusing the DNS protocol to communicate with C&C servers. We focus on one such campaign, of CoinLoader, and lay out its infrastructure as well as an in-depth technical analysis of its DNS tunnelling functionality.
Domain Name Server (DNS) protocol can be considered “the phonebook of the internet.” When you enter a website address (let’s say wikipedia.org) into your web browser’s address bar and press enter, your web browser sends a DNS request to its favorite DNS server, asking what IP addresses correspond to that domain. The IP address of this default DNS server is either supplied by the user’s network provider or specified manually by the user.
Under the hood, a typical DNS query rides on top of the UDP protocol (to jog your memory, whereas TCP deals with the issue of “did my peer really get that message?” using SYNs and ACKs, UDP deals with it using thoughts and prayers). A DNS packet, whether a query or a response, consists of a header and 4 main sections:
“DNS Tunneling” is the practice of abusing DNS, using it as a covert channel of communication such as between a malware and its C&C server. In this scenario, the malicious actor controls both the client and the server, giving them a lot of wiggle room with respect to what kind of query to make, and where to hide the “spicy” part of the response.
However, the scheme the actors choose is inherently subject to the limitations of the DNS protocol itself. For example:
If this all sounds too theoretical, one well-known malware that utilizes DNS tunneling is the high-profile SUNBURST backdoor, which was delivered to unsuspecting victims as part of the infamous 2020 SolarWinds hack. SUNBURST used DNS queries as a light recon channel, covertly transferring victim information encrypted as an identifier, and then used it as a subdomain in a DNS query. This subdomain was prepended to one of the four main domains:appsync-api.us-east-1[.]avsvmcloud[.]comappsync-api.us-east-2[.]avsvmcloud[.]comappsync-api.eu-west-1[.]avsvmcloud[.]comappsync-api.us-west-2[.]avsvmcloud[.]com
For example, the resulting fictitious FQDN looks like this:7cbtailjomqle1pjvr2d32i2voe60ce2[.]appsync-api[.]us-east-1[.]avsvmcloud[.]com.
Based on the information transferred over the DNS requests, the DNS server would return a CNAME record to targets of interest. The CNAME would point to a C&C server that communicates with the malware over HTTPS.
Can a determined defender, standing atop a network gateway, detect DNS tunneling? This is a surprisingly loaded question, because the definition of DNS tunneling is very broad, and some implementations are more difficult to detect than others. We list some points of interest below that are worth keeping in mind while analyzing activities suspected to be DNS tunneling.
We asked ourselves the following questions:
Answering those questions may not be easy, but luckily for us as researchers, a lot of them can be answered using public resources. Passive DNS is a very helpful tool in triaging a wide variety of threats but is extremely efficient when dealing with DNS tunneling. As DNS tunneling relies on the DNS protocol itself, passive DNS replications often document artifacts transferred with it. In some cases, it might even be possible to extract information related to the victims themselves.
As part of our ongoing interest in general DNS tunneling and malicious web traffic, this year we saw the introduction of DeepDNS, an artificial neural network that hunts and blocks campaigns that abuse DNS. DeepDNS is a Gated Recurrent Unit Autoencoder (GRU-AE) that is trained on the vast amount of DNS traffic routinely available to Check Point as part of the telemetry. The DeepDNS conclusions drawn are automatically pushed to Check Point ThreatCloud.
This document is certainly not a treatise on the inner workings of AI, but we still felt you would be well served by a very simplified explanation of what a “Gated Recurrent Unit Autoencoder” is, at least in broad strokes.
To begin with, an autoencoder is an artificial neural network, meaning, it is a virtual brain that begins its life as a blank slate. During its training phase, it is given an input — the output is then observed, and changes to the brain’s parameters that would make the output more desirable are determined using calculus, then applied (this is a fancy way of saying that you close your eyes, imagine that the wrongness of the output as a function of the brain parameters is a mountain, then go as quickly down the mountain as you can until you cannot go further down). This process repeats until the virtual brain’s actual output sufficiently resembles the desired output. If this whole description sounds alien to you, consider that it is not so conceptually different from what you do when you repeatedly shout “NO!! NO!! LEAVE THAT ALONE!!!” at your three-year-old.
Artificial neural networks have a surprising capacity to learn all sorts of functions (this is even theoretically proven). One such function is simply “map this text to some short representation (code), then change the code back to a text so that the final text resembles the initial text as much as possible.” A neural network that’s been trained to learn this kind of function is called an autoencoder. An autoencoder can function as a generative model: obtain a novel point in code space in some way (by picking at random or just mixing some known points together), and if the model has learned a good representation of the data, decoding this point will result in novel text. As this isn’t technically part of an autoencoder’s specification, the literature appears divided on how correct it is to refer to it as a generative model, as opposed to a model with generative capacity (have fun with this Google search); but “model with generative capacity” did not fit so neatly into the main title, so here we are.
One other use case for autoencoders, which is relevant here, is that of anomaly detection. Applying some mathematical intuition will lead you to the conclusion that “typical” input will be compressed and reconstructed by the autoencoder with relative success, whereas compression and reconstruction of “atypical” input is more likely to introduce errors. This is basically for the same reason that if I say “the quick brown fox jumps over the lazy dog” then five minutes later ask you to repeat that sentence, you will probably succeed, but the same is not true for “the abstruse purple platypus confounds the prolific cheetah”.
DeepDNS works on this same principle. Using deep inspection of subdomain names which are further broken down into smaller constituent parts, it uses the encode-decode process that it learned to render its judgment on the simple question, “how normal does this set of queries look?” If the reconstruction sufficiently fails, DeepDNS concludes that the answer is “not normal enough”, and delivers a malicious verdict. This approach is elegant in its simplicity, if you ignore the part where training the model involves colorful floating surfaces and a bunch of partial derivatives.
Now that we’ve covered the theory, it’s time to put it into practice. Knowing how DeepDNS works at the black box level (and even some of its inner workings thanks to the section above), it is natural to ask what it can find if we make it search for anomalies across our available telemetry. We did just that and ran DeepDNS on our sample. Among the many results that it flagged as anomalous, one previously unknown cluster of domains caught our eye in particular:
A closer look at the infrastructure connected with these domains suggests they are part of a DNS backup channel used for CoinLoader infections.
Coinloader was first described in this extensive report by Avira, but we could not find prior documentation describing this specific feature. Samples were found in an archive, typically a rar or a zip, containing several files. While the names varied, what you see below is more or less representative of the file structure in each sample.
The executable (ZD_1.4.24.17 in the image) is always some legitimate tool which is used for DLL sideloading. The main malicious logic is in the sideloaded DLL (here AppleVersions.dll). Upon being loaded, it goes through several layers of unpacking, including a well-obfuscated check that its parent process was launched from inside the Z-1-36-81 directory (again, the directory name varies from sample to sample) that is buried inside some complex control flow structures.
Once unpacking is complete, the malicious logic is visible. This final stage still contains several anti-analysis features, such as junk code; encrypted stack strings that are decrypted on-the-fly using a simple substitution cipher; and indirect calls that are resolved using a homebrew function table, in which the register points at what is passed to each function in ecx. This is then copied to a random register each time, which is used to implement the calls.
While the junk code is best ignored and the obfuscated strings are best dealt with by dynamically executing the code and observing the decoder output, the resolution of the function calls in the IDA database requires a dedicated script. To see such a script, go to Appendix A.
The traffic capture generated by one such sample seemed promising:
So we set out to perform a technical analysis of this feature.
The function get_c2_domain receives an enum argument (here passed in the register edx). The values 0, 1, 2 and 3 cause the function to decrypt and return, respectively, each of the malware’s hardcoded C&C domain names — in this case rqmetrixa.info, rqmetrixb.info, rqmetrixc.info, rqmetrixd.info (we were honestly disappointed not to find some piece of logic appending a letter to rqmetrix but these were all hardcoded as-is).
Finally, if this enum value equals 4 (above annotated as GET_DOMAIN_DNS_TUNNEL_BACKUP), the malware resorts to a backup plan, and attempts to obtain a domain name by conferring with a different server, rqmetrixsdn.info, via the TXT DNS tunneling query as seen in the traffic capture.
The FQDN is created by taking one of the hardcoded domains and prepending to it hexlify(md5(timestamp)). In the image below we show it as a code block to filter out junk instructions.
The timestamp md5 is obtained using SystemFileToFileTime (then converted into a timestamp using additional WinAPI functions). Once the server responds, its response is fed to an inline BASE64 decoder. The result is interpreted as a C&C domain to check in with, similar to the SUNBURST setup that we mentioned earlier. The check-in format, which is the output of the string_decoder deobfuscation handler, is visible below.
DNS tunneling is what you might call an “old-school” technique. It originated in a security landscape created by the advent of the first firewalls, and the drawing of simplistic boundaries: who initiated a connection? With whom? On what port? Using what protocol? Therefore allow, or deny. The industry has since greatly evolved and the benefits of DNS tunneling have become less clear-cut. DNS is no longer some “covert channel” where no security solution would think to look; and conversely, attackers have refined their understanding of how to effectively communicate using HTTP and hide in plain sight, using a variety of techniques such as steganography and encryption.
Still, DNS tunneling is clearly not dead. Whether because it less obviously jumps out at the human eye, or because malware authors simply figure the technique is worth a try if straightforward HTTP communication has failed — or for other reasons — modern malware is not shy to engage in this practice. As defenders, we are naturally interested in ways of catching it in the act. In this post, we explained how it is possible to model DNS tunnels as anomalies and hunt them from an unusual perspective, as demonstrated with DeepDNS. This hunt has led us to evidence of a number of actors currently using the technique, including state-sponsored cybercriminals and even hacktivists. As an example, we performed a technical analysis of a Coinlander sample and its tunneling protocol that DeepDNS sniffed out as anomalous. Other than its natural interest to us as threat hunters, this also served as a nice proof-of-concept for DeepDNS’s capabilities.
While academia carries the torch of pushing scientific boundaries and proving what is possible, it often falls to industry to implement academic ideas at scale, and usher them along the path from promising whitepaper to surviving impact with the messy real world. While we continuously work to apply ANNs to security at that level of maturity, the frontier is far from exhausted. With the recent surge of interest in ANNs and their applications, we can only expect more and more artificial brains to be making real-world security decisions, and it is our responsibility as an industry that they do so with skill and accountability.
So, in that spirit, let this article be a testament to that time when we said “Oh, model, you say that’s DNS tunneling? Let our analysts and reverse-engineers double-check you on that”.
CoinLoader Samples
a05144d7254b419d3a09787e280b4be3
84548cf16e26979ff9a3fa2b3f854f34
CoinLoader Infrastructure
candatamsnsdn[.]info
candatamsna[.]info
candatamsnb[.]info
candatamsnc[.]info
candatamsnd[.]info
mapdatamsnsdn[.]info
mapdatamsna[.]info
mapdatamsnb[.]info
mapdatamsnc[.]info
mapdatamsnd[.]info
rqmetrixsdn[.]info
rqmetrixa[.]info
rqmetrixb[.]info
rqmetrixc[.]info
rqmetrixd[.]info
Check Point Threat Emulation and Harmony Endpoint provide comprehensive coverage of attack tactics and is protecting against the type of attacks and threats described in this report.
Check Point Harmony Endpoint:
APT.Win.Coinloader.B
APT.Win.Coinloader.C
Check Point Threat Emulation:
APT.Wins.Coinloader.A
APT.Wins.Coinloader.D
(Requires function table ripped from memory — sample function table included below.)
Sample function table:
Subscribe for cpr blogs, news and more
Subscribe Now
© 1994- Check Point Software Technologies LTD. All rights reserved.
Property of CheckPoint.com
Privacy Policy
BFSI uses cookies on this site. We use cookies to enable faster and easier experience for you. By continuing to visit this website you agree to our use of cookies.
About The Author
More Stories
Anatomy of a Scam
Climate and Environmental Sustainability Within the IETF and IRTF
From Commitments to Practice: Internet Society’s Priorities for WSIS+20 Implementation