In my last blog we looked at data exfiltration using covert tunneling techniques, and reviewed some tools which may be used by an attacker or a penetration tester to create such tunnels. This time around we'll look at malware which uses DNS tunneling to allow communication which a remote command server operated by an attacker.
Tunneling may be used by malware to either exfiltrate data or to contact a command and control server under the control of the malware's distributors. Late last year, researchers identified a trojan named ALMA Communicator, which uses DNS tunneling exclusively for all C2 communications. We'll examine this example of how tunneling may be utilised by malware.
ALMA Communicator is a trojan which is disseminated via an Excel file. This Excel file additionally provides configuration settings and other resources for the trojan, and as such the trojan will not operate as a standalone executable.
We begin by examining the Excel file. Doing so displays following macros contained within the file:
Decoding the "Strings" as suggested above reveals the base64 encoded string Incompatible, which represents a Excel tab as we will see later.
Performing further static analysis of the file, we can see some strings of interest, such as those referencing DNS based communication and the creation of a scheduled task:
When opened, the Excel file will require that macros be allowed before its contents can be displayed. Once allowed, a worksheet will be displayed which is ostensibly about password policies.
Though this worksheet, Sheet1, is the only one visible within the workbook once loaded, there is in fact another sheet, Incompatible, which is hidden by default. This hidden sheet contains the code and content fragments which are merged to create the malicious files we will see later.
After the malicious code has been assembled and executed, the scheduled task mentioned previously is created and set to run at two minute intervals in perpetuity.
Following the path to the executable referenced in this new scheduled task, we find the staging area for the malware.
Looking at the SystemSyncs executable prior to execution, we can see that this file is the trojan itself, ALMA Communicator. We can see that it utilizes the dnsapi.dll library, in particular importing the DnsQuery_W and DnsFree functions. These will be used to create the tunnel.
Looking through the extracted strings, we can see the following character sequence, which seems to indicate that data will be encoded using base64.
Running the application through a debugger, we can see that these requests are generated using the DNSAPI function DnsQuery_W. Each invocation of this function uses the option
DNS_QUERY_BYPASS_CACHE (0x08), which should result in the system ignoring the local resolver cache so that the query will be sent on in search of an authoritative name server.
We can also see references to cryptographic functions, functions for taking snapshots of running processes and functions for opening and/or manipulating files or the Windows registry.
The other files in this folder are:
Pivoting to examine the traffic produced by the execution of ALMA Communicator, we can see DNS type A queries directed toward the prosalar domain noted previously. These initial DNS queries include an increasing numeric prefix, an ID value (derived from the product ID and user name in the current context) and the domain name. Of particular interest, in relation to the monitoring of DNS traffic, are the domain prosalar, and the preceding string 0-2D-2D (which is hardcoded into the application). These can be used as Indicators of Compromise (IoC) when analyzing traffic to detect this trojan, as seen in Corvil below.
Once the details needed for transmission and data collection have been provided to the infected machine, via returned DNS A records, subsequent DNS requests are used to transmit data from the client machine back to the C2 server in the form of hexadecimal bytes that form part of the third level domain in the request. These records will again be transmitted to the prosalar
When examining malware of this nature, as with the detection of DNS tunneling tools, it's important to be cognizant of the IoCs. These indicators may be based on the transmission of particular files or strings associated with a particular strain or malware family, or they may entail the detection of abnormal user/system behavior within the network, e.g. the use of non-standard DNS servers, a sudden burst of DNS traffic directed from one machine to a particular domain, etc.
Corvil Security Analytics enables our customers to detect these network-based symptoms of infection, and to investigate the cause of these symptoms. Our technology provides the means to identify anomalous activity or track down specific IoCs, helping you to secure your network and safeguard your data. If you are a Corvil client and would like to learn how we can help you secure your network, please contact your local Corvil representative.