The global internet relies on Content Delivery Networks (CDNs) to deliver a seamless web experience for users. Because of the shared nature of a CDN’s resources, network operators must be careful when identifying and blocking threats that abuse CDNs. In short, network operators cannot indiscriminately block CDN infrastructure when malicious abuse is detected. So, the question is, what can be done to address malicious threats in CDNs? First, we need to detect the CDN abuse and then selectively block access to the resources hosted on the CDN server. In this blog post, we explain how Juniper Threat Labs (JTL) identifies threats that abuse CDN infrastructure through dynamic behavior profiling.
What are Content Delivery Networks (CDNs)?
Internet users are spread across the globe. They expect fast, secure, and reliable access to web content. CDNs play a crucial role by bridging the physical distance between the user and the server, ensuring that everyone, no matter where they are, can have a similar web surfing experience. Without CDNs, a user in India trying to access a website hosted in the United States might experience slower load times than someone in the United States attempting to access the same website. CDNs help by storing copies of web content in many different places worldwide; so, regardless of where the user is in the world, the content the user is attempting to access does not have to travel as far.
Expanded Use of CDNs
Some users have found creative ways to use CDNs beyond their original purpose. For example, users can bypass Internet censorship, bypass regional content restrictions, proxy access to their domains and obfuscate their activities using domain fronting.
Similarly, malicious adversaries abuse CDNs to distribute malicious payloads, host phishing sites, hide command and control (C2) servers and exfiltrate data. This abuse of CDNs makes the work of network operators more challenging. They need to differentiate between legitimate and malicious traffic, which can be difficult when bad actors use sophisticated techniques to blend in with legitimate CDN traffic. Network operators that attempt to block CDN access altogether might disrupt access to other sites, which is generally undesirable. Moreover, the global and distributed nature of CDNs complicates legal jurisdiction and the process of taking down malicious content hosted in CDNs.
Malware CDN Abuse Examples
When we inspected 1000 random malware samples that targeted our customers’ networks, Juniper Threat Labs found that they attempted to connect to servers hosted by the following CDN providers:
- Akamai
- Amazon CloudFront
- CacheFly
- CDN77
- Discord (Cloudflare)
- Edgeio
- Fastly
- Google Firebase
- Microsoft Azure
- StackPath
Note that not all connections to CDN servers are being abused for malicious purposes. When malware infects a machine, the operating system (OS) can connect to CDN servers for legitimate services. For example, malware might connect to Google.com to test internet connectivity and in doing so the OS establishes a Transport Layer Security (TLS) connection to Google’s site. To ensure the security of the TLS connection, the OS will download a Certificate Revocation List (CRL). The CRLs are typically hosted on CDNs to speed up the security check. This is a routine process the OS performs for any program, connecting to a remote server, including malicious ones. Therefore, when analyzing malware network connections, we must have the correct context about the connection before we can identify it as CDN abuse. Nevertheless, we have found specific samples that abuse CDN infrastructure directly. We describe two such cases next.
Case 1: RedLine Stealer – Payload Download
RedLine Stealer is an information harvester that attackers use to steal data such as saved user credentials, credit card data and browser auto-complete information among other things. It is a popular malware variant that is typically delivered through social engineering. We discovered this sample when Juniper ATP Cloud blocked an attempt to access a known malware download domain. The following figure summarizes the detection and inspection of the suspicious file.
Figure 1: RedLine Stealer Blocked Attack
In this attack, the targeted user requested a suspicious binary file from a known C2 server (Figure 1, step 1). The SRX Firewall blocked this request and sent the file to ATP Cloud for further analysis (steps 2 and 3). ATP Cloud detonated the suspicious file in a sandbox environment and performed dynamic analysis (step 4). Dynamic analysis uncovered an additional stage to the attack in that the malware payload was hosted on a CDN server (step 5). Using this new information, Juniper ATP Cloud not only blocks the first stage but can also block requests to that specific CDN URL, further protecting customers from second-stage malicious payload served by the abused CDN.
As alluded to above, Juniper ATP Cloud detects both the first and second stage of this attempted malicious attack. The first stage malware variant has the following indicators:
| SHA256 | daf576a4e5b3bab87f02f9a7b05afa403999bc000bb98346d47dfca514ae5dfa |
| MIME type | application/x-dosexec |
| Size | 5MB |
| Platform | Win32 |
| Malware Name | Generic |
The first stage executes (as shown in Figure 1, step 4) and downloads (step 5 in Figure 1) what appears to be a DLL file from Discord’s CDN using the following URL:
| https://cdn[.]discordapp[.]com/attachments/1078789718923292715/1079896776011677766/Tjqqjifejlv.dll |
Upon closer inspection of the downloaded file, we find that the file is not a valid DLL since the file header information does not quite follow the Portable Executable (PE) format. That’s because the malware creator cleverly reversed bytes in the file. Since many security appliances rely on file type identification to hone into potential threats, attackers sometimes use this simple technique to bypass file inspection. By using a reversed-byte file, the attacker increases the likelihood of successfully delivering this second stage malicious component of the attack. Interestingly, only 13 AV engines identify the second stage malware as malicious on VirusTotal. After reversing the bytes for the second stage file, 48 AV engines identify the file as malicious on VirusTotal.
Technical Analysis of RedLine Variant
This RedLine variant downloads the main payload from a CDN to bypass traditional blocklists. Specifically, the attacker hosted the RedLine Stealer malware on Discord’s CDN where it was part of the second-stage download shown in Figure 1, step 5. Discord’s CDN uses Cloudflare as the CDN backend. These Cloudflare domains and IP addresses have high reputation scores, which allow attackers to evade security appliances that rely on reputation-based detection. Shown below in Figure 2 is information Juniper provides following its detection of RedLine in the second stage of an attempted attack.
Figure 2: ATP Cloud Detection for RedLine Stealer
Case 2: LuminosityLink Remote Access Trojan (RAT) – Profiling Device Network Bandwidth
The second case shows another interesting abuse of CDNs. A sample of LuminosityLink RAT was detected and blocked by Juniper’s ATP Cloud as shown in Figure 3. Similarly, the detection triggered a dynamic analysis of the RAT, and Juniper Threat Labs found unique connections to the CacheFly CDN.
Figure 3:ATP Cloud detection of LuminosityLink RAT
The malicious LuminosityLink RAT sample analyzed has the following indicators:
| SHA256 | 68a599d2658096ff9c529c5aeb9644119c47e1c744b07323a3df8a8e5e94c4da |
| MIME type | application/x-dosexec |
| Size | 1MB |
| Platform | Win32 |
| Malware Name | Win32:Trojan:Ursu:Gen:B |
To further understand the CDN abuse, Juniper Threat Labs reverse engineered the sample to verify the functionality. We found that LuminosityLink RAT has a built-in feature that allows an attacker to profile the network bandwidth/speed of an infected host. Specifically, the RAT uses a CacheFly CDN to download a 5 MB file and report the speed back to the attacker. The following is disassembled .NET code of the LuminosityLink RAT network bandwidth/speed profiler:
|
@1000696b: newobj System.Void System.Net.WebClient.ctor(); Creating a WebClient instance @1000696c: stloc.0; Storing the WebClient instance @1000696f: ldloc.0; Loading the WebClient instance @10006970: ldstr; http://cachefly.cachefly.net/5mb.test; Specifying URL to download data from @10006971: callvirt 0A0001AC; Downloading data @1000698c: call 0A000212; Calling a method to get download time
@1000698a: ldc.r8 5120; Data size (5MB) @1000698d: conv.r8 @1000698e: div; Calculating the download speed
Formatting the download speed @10006991: ldloca.s V_2 @10006992: call 0A0001AF; Converting download speed to string @10006993: ldstr; “KB/sec” @10006994: call 0A000019; Concatenating the string with “KB/sec”
@10006995: stloc.s V_7; Storing the formatted download speed @100069a0: ldloc.s V_7; Loading the result string @100069a1: ret; Returning the result string |
Figure 4:Snippet from Disassembled LuminosityLink Code
At offset 1000696b (atop Figure 4 above), the code initializes a WebClient instance to conduct the speed test. Then at offset 10006970, the code specifies the Cache Fly URL to download a 5 MB file. Then the code calls two functions: one to download the test file and another to measure the time it took to download the file. The code loads the constant 5120, which is the size of the downloaded file (i.e., 5MB = 5120KB), to calculate the bandwidth/network speed of the system (offset 1000698e). Finally, the code formats the results and concatenates the string “KB/sec” to the results.
You might ask why malware would use CDN for profiling network speed like this? Recall that CDNs replicate content across the globe to provide better experience for the user. When malware uses a CDN to profile an infected system they get a more accurate result of the last mile bandwidth speed because the data download is geographically closer, which reduces the effect of latency and network congestion on the results. With this information, attackers can sell high-bandwidth infected systems to use as proxies for malicious activities.
Takeaway
In conclusion, Juniper Threat Labs continues to find that malicious threat actors are actively abusing CDNs to evade detection. As CDNs play a crucial role on the internet in terms of speedy content delivery for all users regardless of location, network operators cannot indiscriminately block CDNs when malware is detected on one or more of their servers. Juniper ATP Cloud and SecIntel feeds will identify CDN IOCs and ensure only the ones that cause minimum disruption to legitimate traffic are acted upon. Customers with an active ATP Cloud subscription are protected against all the malware samples described in this blog.
