Dynamic Detection of Malicious DDNS

 

This post was co-authored by Andrew Tsonchev.

Two weeks ago we briefly discussed the role of dynamic DNS (DDNS) in a Fiesta exploit pack campaign. Today we further analyze and explore the role of DDNS in the context of cyber attack proliferation and present the case for adding an operational play to the incident response and/or threat intelligence playbook to detect attack pre-cursors and attacks in progress.

 

 

Managements’ Bottom Line

There are over fifty DDNS providers that leverage over one thousand combined domains to offer free and fee-based accounts. DDNS is a useful service with numerous legitimate applications. One of the primary DDNS use cases involves enabling connections to networks that rely on dynamic IP address ranges. Dynamic IP addressing tends to be more ubiquitous on residential networks, thus when home Internet users wish to host a website or connect to their home Virtual Private Network (VPN), they often rely on a DDNS service. The service itself maps a new sub-domain (based on a list of existing domains owned by the DDNS provider) to the IP address currently provisioned by the Internet Service Provider (ISP) and automatically changes the IP address as lease times expire and the ISP assigns a new IP address to the residential customer.

The 2014 Cisco Annual Security Report addresses the need for a threat-centric detection model and we believe DDNS is a perfect example of benefiting from attacker methodology analysis. Like all good and useful Internet services, threat actors (across the motivation spectrum) have co-opted DDNS for nefarious purposes. In order to launch an attack that involves malicious code (malware) that maintains a persistent connection to a command and control (C2) server, or for data exfiltration from a victim network, an attacker must first configure basic Internet infrastructure and DNS is a primary consideration in the larger decision process.

Choices include: domain or IP address, register domains with a stolen credit card or compromise a legitimate registrar account and create new DNS records, or finally use a free DDNS service. Obviously forgoing a domain and hard coding traffic to an IP address reduces attack flexibility since the server may be quickly identified and disabled. Registering a domain with a stolen credit card is sub-optimal for longer duration attacks since the registrar will disable the domain and account once the card fraud is discovered. Compromising an existing registrar customer account is resource intensive and does not scale well for attacks requiring multiple domains.

Free DDNS services, by comparison, check all of the necessary attack boxes. Sub-domains can be quickly and easily generated and DNS records are trivially changed. For the remote access Trojan (RAT) crowd that are typically attempting to spy on female victims and running servers from home, DDNS is a natural fit. In fact, searching the web for tutorials on using freely available RATs like Black Shades, Dark Comet, or Poison Ivy returns results that all instruct RAT attackers to first create DDNS sub-domains in order to properly configure the RAT, specifically enabling a “back connect” to the attacker. Naturally, one segment of RAT users tend to be less technical, relying on tutorials and point and click interfaces to actually launch the RAT, which likely contributes significantly to the overall metrics of malicious DDNS use.

Speaking of metrics, let’s dig into the malicious DDNS numbers from our Internet vantage point. The following graph illustrates the Cloud Web Security (CWS) percentages of specific DDNS base domains that are blocked based on web reputation scores. As you can see the DDNS block rate average is nearly 20% while the average block rate for all other web traffic is less than 1%. There are also quite a few DDNS base domains that are blocked with almost 100% frequency (the reputation charts below exclude DDNS domains that are blocked 100% of the time).

 

 

 

 

 

 

 

 

 

 

Next up are the block statistics from anti-virus detection. Unfortunately there are fewer blocks overall, and the DDNS block rate average is greater than 0.2% as compared with the much lower 0.001% average block rate for all web traffic.

 

 

 

 

 

 

 

 

 

 

The top ten Kaspersky verdicts for DDNS domain blocks appear below and contain heavy emphasis around Java exploits and JavaScript redirection.

 

 

 

 

 

 

 

 

Last, the word cloud below depicts the top DDNS base domain offenders. The size of the word indicates total CWS traffic observed and the darker color indicates a higher percentage of web reputation blocks.

 

 

 

 

 

 

 

 

 

We have established that the CWS block rate for DDNS domains is on average substantially higher than for all other web traffic, but what do the corresponding malware numbers look like for the DDNS domains most abused by threat actors?

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The prolific use of DDNS specifically for malware campaigns represents a significant indicator of compromise (IoC) category. While legitimate DDNS use cases exist, implementing detection around DDNS traffic in the enterprise is crucial because it is a preferred threat actor tool. This operational alert is bound to generate noise in the form of false positives, but given the above metrics, this category is too important to ignore.

The Network Security Monitors’ Operational Insight

The malware counts per DDNS domain are informative, but obviously the hashes themselves are much more instructive so we include the specific SHA1 hashes corresponding to the malware (observed since 2009) for the top DDNS base domain counts above. VRT incorporated the following hashes into their detection cloud to provide coverage across multiple tools including ClamAV and FireAMP.

adultdns.net
servehttp.com
myvnc.com
redirectme.net
hopto.org
zapto.org
no-ip.info
no-ip.biz (zip file due to file size)
no-ip.org
sytes.net
adultdns.net-samples
Deeper inspection of a randomly selected sample from the DDNS malware set reveals TCP traffic from victim hosts back to fuewuwoekmcdd.myvnc.com, which at runtime, resolves to 91.148.217.229:13000 (Saudi Telecom DSL Pool).

SHA1: 62b018b011c563dc79831873f780f0abb5e9ccd3
MD5: da402e22e036c321410d2c0ec19876b2
File Type: PE32 executable for MS Windows (GUI) Intel 80386 32-bit
Packer: BobSoft Mini Delphi
Anti-Virus Detection Rate: 4 / 12 detection on January 31st, 2014
Anti-Virus Label: Trend Micro – “TSPY_SPATET.BMC”
Mutex: MSCTF.Shared.MUTEX.AJE
Mutex: MutexToProtectNamespace

Icon:

The sample creates multiple processes and modifies obligatory DLL files and registry keys as well as creating the following directories and running Project1.exe.

This sample shares the same mutex – MSCTF.Shared.MUTEX.AJE – as a sample we referenced in an earlier blog on point of sale malware as “POSCardStealer,” but that’s not surprising given that at least 3,971,033 samples use the mutex. The second mutex – MutexToProtectNamespace – links this sample to malware observed in 2012 and 2013, specifically sending traffic to the DDNS domain bbroman.myvnc.com, labeled in a separate instance by Ikarus as “Backdoor.Win32.Xtreme,” and in other instances successfully evading antivirus software altogether. At least 29,707 malware samples use the mutex – MutexToProtectNamespace – which makes it relatively distinct.

Two additional malware samples sending traffic to fuewuwoekmcdd.myvnc.com include:

SHA1: f85b3feee8c72e229800f804084e644445a19558
MD5: 8bfc9bac313f0d50a43a10f19b111bae
PE32 executable for MS Windows (GUI) Intel 80386 32-bit
Packer: PECompact v1.10b2
Anti-Virus Detection Rate: 7 / 12 detection on September 18th, 2013
Anti-Virus Label: Eset – “a variant of Win32/Injector.ACJQ trojan”
Destination Traffic: TCP –> 2.89.241.121:13000 (Saudi Telecom DSL Pool)

SHA1: a55f49caaba4dfd43239a3b18fa849098ddd032c
MD5: eae96bcf142f4076415956b3496e23c7
PE32 executable for MS Windows (GUI) Intel 80386 32-bit
Packer: PECompact v1.10b2
Anti-Virus Detection Rate: 9 / 12 detection on January 30th, 2014
Anti-Virus Label: Avira – “TR/Spy.537088.19”
Destination Traffic: TCP –> 87.109.254.5:288 (Saudi Telecom DSL Pool)

These two malware samples use the same Java icon, but it’s slightly modified. At least 102 other malware samples use the same icon going back to 2010. During runtime analysis all three of these samples send a SYN packet to fuewuwoekmcdd.myvnc.com (which resolves to different Saudi Telecom dynamic IP addresses at different times) without receiving a reciprocal SYN-ACK reply. Perhaps the threat actor’s DDNS is misconfigured. TRAC proprietary intelligence reveals a small number of current global victims which may be indicative of an ineffective manual spreading mechanism for this particular Trojan.

The threat actor behind this malware campaign may be Saudi, or the host on the Saudi Telecom network may be compromised, and in a perfect world collaboration between the DDNS provider, law enforcement, and Saudi Telecom would produce a quick determination on the nature of the host and further individual attribution. This is just one example out of hundreds of thousands, and based on the previous malware sample numbers, DDNS is being leveraged for an escalating amount of malicious activities. Yet DDNS also represents a solid choke point for global law enforcement to pursue attribution on a large scale.

Incident Response and Security Architecture groups should seriously consider using DDNS as an IoC category for detection and remediation. If traffic to DDNS domains is not necessary on the network, think about implementing a DNS RPZ (Response Policy Zone) – which is natively available in BIND 9.8.1 and later – to detect and/or prevent traffic to the most egregious DDNS domains.

For more on this topic please view the “Dynamic Detection of Malicious DDNS” video below.