Breadcrumb navigation

ChamelDoH Implant: Tunnelling or DNS-over-HTTPS (DoH)?

NEC Security Blog

Sep 20, 2024

Dr. Sareena K P, Dr. Manikantan Srinivasan NEC Corporation India Pvt. Ltd.
Toshiki Takeuchi NEC Corporation

NEC Cyber Intelligence Group usually collects and analyzes cyber threat information and delivers to our customer or colleague. If we discover new threats or techniques that are not listed in MITRE ATT&CK, we report the findings to MITRE. As part of our activities, we also analyze malware. This article shows analysis of ChamelDoH malware.

ChamelGang, a sophisticated threat actor based in China has developed a robust and stealthy toolset for Linux intrusions new window[1]. A notable toolkit in its arsenal is ChamelDoH, a C++ implant built to communicate via DNS-over-HTTP (DoH) tunnelling. Exploiting the widely popular Domain name system (DNS) and public DNS providers coupled with encrypted traffic enables covert communications, while thwarting defense techniques such as enterprise-wide blocking and interception.

Stairwell Threat Research teams identified a total of 10 samples of ChamelDoH new window[1]. While the report new window[1] present the analysis and indicators of ChamelDoH and its variants, including its capabilities, we attempt to understand the extent of covert communication over DNS, if it is exploiting DNS tunnelling or DNS-over-HTTPS (DoH). We also map ChamelDoH behaviour to MITRE Tactics & Techniques. Finally, we analyse possible countermeasures and policy considerations to prevent/detect ChamelDoH.

In this report, we present our analysis based on the ChamelDoH sample (SHA256 92c9fd3f81da141460a8e9c65b544425f2553fa828636daeab8f3f4f23191c5b, trojan.chameldoh/uselvff23).

Key findings. Below are the key findings from our study.

  1. ChamelDoH does not encrypt the DNS packet as in the traditional DNS-over-HTTPS (DoH). It encrypts only the subdomain field. Basically, it is performing DNS-tunnelling and not DoH, at least in its beacon messages.
  2. ChamelDoH masquerades as the legitimate systemd-logind service.
  3. An analysis of countermeasures and policy considerations.

Table of Contents

1. Exploiting DNS for Covert Communication

In this Section, we first discuss the working of DNS and ways in which adversaries can abuse DNS to create covert communication channels.

Domain Name System (DNS) is an instrumental protocol in communication enabling computers to translate human-friendly domains names (e.g. reddit[.]com) to their corresponding computer-friendly IP addresses. To achieve this, computers send a DNS query with the domain name to a resolver which in-turn request the remote name-server to resolve the name to an IP address. Figure 1 illustrates an example when a user wants to visit a subdomain in reddit[.]com namely subdomain[.]reddit[.]com. The DNS client sends a Type A DNS request to the public DNS resolvers such as Google or CloudFlare. To resolve the query the public DNS resolver forwards the query to the respective name-server of reddit[.]com as shown in the Figure 1. The name-server in-turn sends the response containing the IP address of subdomain[.]reddit[.]com.

Figure 1 DNS resolving with name-servers

While Type A record is the most basic record used to map a domain/subdomain to its corresponding IP address, DNS supports other records. A TXT DNS record is used to store text-based data, which can be include additional details for various purposes. An example use-case of TXT records includes verification of ownership of a domain.

Why abuse DNS? DNS is often exploited to exfiltrate data and create covert communication channels. Being fundamental to the operation of Internet, DNS packets are rarely blocked and in most cases are not subject to deep scrutinization. This offers diverse opportunities for adversaries to overload DNS packets to carry sensitive information. Following sections describe different techniques for establishing covert communication channels over DNS.

1.1 DNS Tunneling

In DNS Tunnelling, adversaries overload the fields in the DNS requests and responses presented in Figure 1. Adversaries employ an attack-infrastructure and register a name-server for their command and control (C2) operations as seen in Figure 2. The malware implanted at the victim (ChamelDoH in this example) encodes the message of interest to the C2 in the subdomain field of the DNS query. As seen in Figure 2, the malware sends a DNS query to resolve <important message>.C2example[.]com. The public DNS resolver does not process or verify the subdomain field carrying the <important message> in the DNS query. Accordingly, the public DNS resolver forwards the DNS request to the name-server registered by the threat actors. The malicious name-server can now retrieve and process the <important_message>. Finally, the name-server crafts a DNS response which includes additional commands and instructions for the malware.

Obfuscation. To obfuscate the communications via the DNS queries, the malware typically encrypt/encode the message (i.e. the subdomain field <important_message> in the query in Figure 2).

zoomLarger view
Figure 2. DNS Tunneling ( as observed in ChamelDoH). The message is encoded and obfuscated. However, the domain name is observable.

Further, as the DNS protocol has restrictions on possible characters that can be carried in DNS packets, the message in encoded in base64 before transmission. In the case of ChamelDoH implant, the malware encrypts the messages in AES 128 and encodes in base64 new window[1]. As observed in Figure 2, the message is encoded before transmission. However, the domain name is not obfuscated and is observable at network perimeters.

Use of TXT records in DNS Query. Adversaries typically overload the DNS records to carry the information between the C2 server and the target. ChamelDoH employs the DNS TXT records, which offers a convenient carrier for infiltrating data into the target, unlike the commonly used host record type A. This is primarily because, the response options, which are overloaded to carry C2 messages are limited in type A records as compared to TXT records. For type A record, the response is either NO_ERROR along with the IP address of the requested domain, or NX_DOMAIN for non-existent domains. In contrast, TXT records are designed to carry descriptive text including contact names, phone numbers and other service details in response to DNS queries. The status in the response is set as NO_ERROR, and the message is appended to the response, which the malware implant can process. Consequently, DNS TXT records are relatively popular among adversaries for DNS tunnelling and is employed in ChamelDoH for the C2 communication.

1.2 DNS over HTTPS (DoH)

In recent times, enterprises are increasingly adopting DNS over HTTPS (DoH) protocol to enhance user privacy and to prevent eavesdropping and man-in-the-middle attacks that manipulate DNS data. The DoH protocol encrypts DNS communication between the DNS client and the DoH-based DNS resolvers (e.g. Google) using the HTTPS protocol.

a

zoomLarger view
Figure 3. Working of DNS-over-HTTP. Presence of DNS packets are completely obfuscated in DoH. Thus, the domain names are not visible at the network perimeters

Figure 3 illustrates the working of DoH, with an example DNS query to the name-server reddit[.]com. The DNS client first sets up an HTTPS connection with the public DNS resolver (Step A in Figure 3). To resolve the sub-domain subdomain[.]reddit[.]com, the client encrypts the query in HTTPS protocol before transmission (Step B in Figure 3). The resolver receives the query, decrypts it, and forwards the request in plain-text to the name-server of reddit[.]com to resolve the sub-domain (Step C in Figure 3). Finally, the response from the name-server is encapsulated in the HTTPS protocol by the DNS resolver and sent to the client (Step D in Figure 3). As observed in Figure 3, the DNS packets are completely obfuscated in DoH. They are carried as HTTPS packets. Hence, at the network perimeters, it is impossible to identify the presence of DNS packets unless sophisticated Encrypted Traffic Analysis (ETA) techniques are adopted.

2. ChamelDoH adopts DNS Tunnelling

During our network analysis, we observed periodic communication from the ChamelDoH implant to the DoH servers (8.8.8.8, 1.1.1.1 and 8.8.4.4). These communications were spaced at 600 seconds. As the C2 servers contacted by ChamelDoH are not available at the time of writing, we are unable to observe subsequent communication with the C2.

zoomLarger view
Figure 4. Network Communication from the DoH implant

Inspecting the beacon packets indicate that the C2 messages are tunnelled i.e. encrypted and encoded in the subdomain field of the DNS requests ( as explained in Section 1.1). The DNS packets are not encrypted entirely as in the typical DNS over HTTPS (DoH) protocol. As observed in Figure 5, the DNS packets are transmitted as plain DNS. Consequently, the domain name ( ) is visible on the wire. In contrast, in a typical DNS over HTTPS, the entire DNS packets are encrypted as seen in an example in Figure 6. As observed in Figure 6, the client (target machine) establishes a HTTPS communication with the DNS provider, and performs the TLS handshake. Following this, the DNS packets are completely encrypted and thus obfuscated at the network perimeters (Refer to Section 1.2).

Figure 5. DNS Packets from ChamelDoH. As observed, the domain name is observable on the wire.
zoomLarger view
Figure 6. DNS Packets in a typical DNS over HTTPS. The entire DNS packet contents are obfuscated as encrypted application data

3. Modus Operandi

In this Section, we first describe the modus operandi of the malware and discuss the masquerading behaviour observed in the analysis. Figure 7 describes the modus operandi of the malware.

  1. The malware first forks a child process masquerading the name of the legitimate login service /lib/systemd/systemd-logind (Refer to Section 3.1)
  2. ChamelDoH performs reconnaissance to gather data about the target.
  3. ChamelDoH retrieves the nameserver and DoH provider information from the DoH configuration.
  4. The data to be sent is encoded into the subdomain field of a DNS TXT query (Refer to Section 1.1 for details). Before crafting the DNS TXT query, the data is first encrypted, following which the encrypted data is encoded in new window[1]. The encoded data is sent in the subdomain field of the DNS TXT requests.
  5. The malware runs continually to receive the commands from the adversary, perform the requested operation and send the response back to the adversary on the DoH tunnel new window[1].
  6. On receiving response from the DNS server, the malware decrypts the data, decodes the command and performs the requested operation new window[1].
  7. The malware sends the results of the task execution to the C2. Finally, it waits for the configured duration, before checking for the next command from the C2 new window[1].

Multiple instances. The malware does not check if another instance of it is running, as verified by running multiple instances of the implant on the machine. Thus, the adversaries can have multiple instances of ChamelDoH running at the victim new window[1].

Figure 7. The modus-operandi of the malware

3.1 Masquerading

Figure 8 shows the process tree when the malware is executed and the corresponding process name. As observed it masquerades as a legitimate login service (/lib/systemd/systemd-logind). Figure 9 shows the main function of ChamelDoH implant. On execution, the malware first forks a child process while masquerading its name as the /lib/systemd/systemd-logind service. This enables the malware to evade detection. Interestingly, in the child process, the malware calls the close system call with process ID from 1 to 1024 as argument. This is probably an attempt to introduce sleep before calling the main ChamelDoH functionality.

Figure 8. The process tree and the process created
Figure 9. Malware forks a child process masquerading its name as a legitimate service.

3.2 Plain text configuration of the ChamelDoH

As mentioned in report of Stairwell, C2 addresses of the ChamelDoH are the described in JSON format. This configuration is plain text in the implant.

4. Countermeasures

In this Section, we first discuss the challenges in preventing DNS-based exfiltration. Further, we discuss few mechanisms to detect ChamelDoH, and DNS-over-HTTPS. Finally, we discuss few policy considerations that can enable enterprises to prevent such exfiltration attacks.

4.1 Challenges in Preventing/Detecting DNS-based exfiltration

Challenges in preventing and detecting DoH are two-fold. Being indispensable for Internet communications, organizational firewalls never block DNS packets, making it popular among adversaries to create covert channels. Compounding the issue, DoH adds a layer of obfuscation, where in the DNS requests are encrypted, with the use of HTTPS protocol. Consequently, enterprises cannot intercept these packets at network perimeters for inspection. Further, employing popular and legitimate DNS/DoH providers dissuades enterprises from implementation of enterprise-wide blanket blocking of DoH providers.

4.2 Detecting ChamelDoH

In the case of ChamelDoH, as observed from the network behaviour, entire DNS packets are not encrypted. The message alone is encrypted in the sub-domain field, where as the domain names are carried as plain text on the wire (Refer to Figure 5). This provides ample opportunities for detecting such exfiltration based on different artefacts as listed below.

4.2.1 Domain names.

The domain names used in such attacks can be blocked based on a block-list or banned-list generated based on the reputation of these domains. For instance, the presence of on the wire can be easily identified and red-flagged. However, such blanket blocking has potential challenges as listed below new window[2].

Exploiting popular and widely-used domains. While blocking using domain names seems light-weight and straight forward, recent research have shown how popular and widely-used domains can be exploited to carry sensitive communications in DNS queries for their subdomains new window[2].

Encrypted DNS packets. Unlike DNS-over-HTTPS (DoH), ChamelDoH does not encrypt the entire DNS packet in HTTPS as observed in our analysis. However, if ChamelDoH were to encrypt DNS packets in HTTPS, then it can easily foil defences that block domains based on reputation.

4.2.2 DNS query rate and format

A high rate of TXT record lookups over a period of time is also indicative of exfiltration attempts. Further, DNS queries containing unusually longer and strange subdomain fields can be detected for scrutiny. Such rules can be based on the type and length of inbound and outbound DNS packets.

4.3 Encrypted traffic analysis to detect DoH

In scenarios, wherein the entire DNS packets are encrypted as in a typical DoH communication (example in Figure 6), the countermeasures specified in Section 5.2 would not help. Research have shown the potential of machine learning (ML) and deep learning (DL) based solutions to detect DoH tunneling [3].

However, identifying malicious communications inside a DoH tunnel is still a challenge. Research have shown how encrypted traffic analytics can be employed to identify intents of users by fingerprinting webpages visited by the user on otherwise encrypted traffic [4]. Such techniques have largely relied on side-channel features of the encrypted traffic such as size of the embedded objects. Such techniques could be explored and extended to identify malicious communications in a DoH tunnel.

4.4 Policy considerations

In-house resolvers versus Public resolvers. Employing in-house resolvers enables enterprises to prevent DoH based exfiltration attempts. However, the policy of migrating to public DNS resolvers is primarily driven by the operational cost, reliability, privacy, and security benefits offered by the public resolvers. Thus, a policy decision between in-house DNS resolvers or public resolvers offers a trade-off for enterprises to evaluate the benefits versus the security risks.

5. Conclusion

In this blog, we analysed the ChamelDoH implant to assess the mechanism it uses to exfiltrate data. Unlike DNS-over-HTTPS (DoH) mechanism based on which the implant was named, ChamelDoH employs DNS Tunnelling wherein the entire DNS packet is not encrypted. Further, we describe the modus operandi, and the countermeasures to detect ChamelDoH and policy considerations to prevent ChamelDoH.

References:

  • [3]
    Mengqi Zhan, Yang Li, Guangxi Yu, Bo Li, Weiping Wang, Detecting DNS over HTTPS based data exfiltration, Computer Networks, Volume 209, 2022
  • [4]
    G. Mitra, P. K. Vairam, S. Saha, N. Chandrachoodan and V. Kamakoti, "Snoopy: A Webpage Fingerprinting Framework With Finite Query Model for Mass-Surveillance," in IEEE Transactions on Dependable and Secure Computing

Appendix

MITRE ATT&CK Mappings

Following are the different ATT&CK techniques observed for the ChamelDoH implant during our analysis.

Table 1 MITRE ATT&CK techniques of ChamelDoH Implant

Resource Development Execution Persistence Defense Evasion Discovery Command & Control (C2) Exfiltration
Acquire Infrastructures- Domains (T1583.001)     Masquerading: Match Legitimate Name or Location
(T1036.005)
File and Directory Discovery (T1083) Application Layer Protocol: Web Protocols (T1071.001) Exfiltration over C2 Channel (T1041)
Acquire Infrastructures- Server (T1583.001)     Indicator Removal: File Deletion (T1070.004) System Information Discovery (T1082) Application Layer Protocol: DNS(T1071.004)  
Develop Capabilities: Malware (T1587.001)       System Process  Discovery (T1057) Data encoding: Standard Encoding (T1132.001)  
        System Network Configuration Discovery: Internet Connections Discovery (T1016.001) Encrypted Channel: Symmetric Cryptography (T1573.001)  
        System Network Connections Discovery (T1049) Protocol Tunnelling (T1572)  
        System Owner/User Discovery (T1033)    
        System Time Discovery (T1124)    
        Process Discovery (T1057)    

Resource Development.

  • T1583.001 Acquire Infrastructure-Domains
    ChamelGang has registered multiple domains for use as C2 domains new window[1].
  • T1583.004 Acquire Infrastructure-Server
    ChamelGang has acquired multiple servers (nameservers) for some of their operations new window[1].
  • T1587.001 Develop Capabilities: Malware
    ChamelGang has developed toolsets for Linux intrusions, one of which is ChamelDoH new window[1].

Defense Evasion.

  • T1036.005: Masquerading: Match Legitimate Name or Location
    The malware forks a child process giving it the name of the legitimate system login service /lib/systemd/systemd-login.
  • T1070.004: Indicator removal: File Deletion
    ChamelDoH supports commands to delete files. Here we assume that the threat actor can delete the implant file to evade defense mechanisms.

Command and Control (C2).

  • T1071.001: Application Layer Protocol: Web Protocols
    ChamelDoH exploits DNS over HTTPS for command and control communications.
  • T1071.004: Application Layer Protocol: DNS
    ChamelDoH encodes the data using base64 encoding in the subdomain field of DNS requests to attacker-controlled name servers.
  • T1132.001: Data Encoding: Standard Encoding
    ChamelDoH encodes its C2 communications as subdomains of the malicious nameserver and issues
    TXT requests for the generated domain. The C2 communications are base64 encoded and encrypted using AES128 to form the subdomain field of the DNS requests.
  • T1573.001: Encrypted Channel: Symmetric Cryptography
    ChamelDoH encrypts its C2 communications using AES128.
  • T1572: Protocol Tunnelling
    ChamelDoH communicates to the name-server via DNS-over-HTTPS tunnelling.

Discovery.

  • T1082: System Information Discovery
    The implant collects the host name, system version, system type information using different system calls.
  • T1033: System Owner /User Discovery
    Invokes whoami command to enumerate the user information.
  • T1057: Process Discovery
    ChamelGang has the ability to enumerate the processes and collect the process ID of the ChamelDoH process.
  • T1049: System Network Connections Discovery
    ChamelGang scans the interfaces in the system.
  • T1016.001: System Network Configuration Discovery: Internet Connections Discovery
    ChamelGang scans the interfaces in the system and identifies IP addresses that are not 127.0.0.1.
  • T1083: File and Directory Discovery
    ChamelDoH collects the present working directory as well as the absolute path of the ChamelDoH process to send to the C2 server.

Exfiltration.

  • T1041: Exfiltration over C2 Channel
    ChamelDoH has the capability to read files and upload them to the server.

Profile

Toshiki Takeuchi, CISSP, RISS(Registered Information Security Specialist)
Security Engineering Center, Risk Hunting Analysis Group

Toshiki Takeuchi is engaged in incident response and penetration testing.
His pastime is malware analysis. He holds GIAC(GPEN) and medal of SANS SEC560.

Profile

Dr.Manikantan Srinivasan, CISSP
NEC Open networks Solution and Services (NOSS) Delivery Unit, NEC Corporation India Pvt Ltd.

Dr Manikantan is involved in AI/ML aided 5G and beyond related research, O-RAN alliance architecture based secure 5G solution development, Telecom Security, 3GPP standardization initiatives and Cyber Threat Intelligence related research. He is a NEC Delegate to O-RAN WG11 - Security Working Group and contributes to O-RAN Security standardization. Dr. Manikantan has 24+ years of Industry experience in domain of Communication Networks, Mobile Cellular Networks and Security.

Dr. Manikantan has made several contributions to MITRE ATT&CK since 2021.

Profile

Dr. Sareena Karapoola
Digital Platform Delivery Unit (DPDU), NEC Corporation India Pvt Ltd.

Dr. Sareena is involved in malware analysis, detection engineering, and cyber threat intelligence-related research. Dr. Sareena earned her direct Ph.D. in Computer Science from the Indian Institute of Technology Madras in 2022 in cyber security. Her other research interests include novel AI-based detection and mitigation strategies, real-world testbeds, and labeled datasets for security research. Dr. Sareena has 10+ years of industry experience in embedded products and system software, including smart card readers and access control terminals.