The COVID-19 pandemic triggered the largest shift to remote work in history, and organizations struggled to migrate to the cloud and secure their employees working from home. In the 1H 2021 edition of the biannual Unit 42 Cloud Threat Report, researchers analyzed data from hundreds of cloud accounts around the world between October 2019 and February 2021 to understand the global impact of COVID-19 on the security posture of organizations.
The report explains which types of threats increased the most, which industries were most heavily affected, how cloud security trends varied across different regions and what organizations should be doing to respond to the security threats they face in the COVID-19 era.
Key Findings
COVID-19 Critical Industries Suffer Spike in Security Incidents
Among the industries with the highest increases in security incidents were retail, manufacturing and government, which saw incidents rise 402%, 230% and 205%, respectively. Security incidents are defined as events that caused violations in security policies and put sensitive data at risk.
These same industries were among those facing the greatest pressures to adapt and scale in the face of the pandemic – retailers for basic necessities, and manufacturing and government for COVID-19 supplies and aid.
Cryptojacking in the Cloud Is on the Decline
From December 2020 through February 2021, only 17% of organizations with cloud infrastructure showed signs of cryptojacking activity, compared to 23% from July through September 2020. This is the first recorded drop since Unit 42 began tracking cryptojacking trends in 2018. This is likely because organizations are doing a better job of protecting against cryptojacking attacks.
However, research also shows that cryptomining activity fluctuated, increasing and then decreasing in intensity following key political and economic developments related to the pandemic. This suggests that incentives to mine cryptocurrency were impacted by the pandemic as well.
Sensitive Data in the Cloud Remains Publicly Exposed
Unit 42 found that 30% of organizations host sensitive data in the cloud without proper security controls in place. Due in most cases to a simple lack of effective access-control restrictions, these businesses place personally identifiable information and other critical assets at risk. These risks could be contained by cloud security automation tools that audit for oversights such as improperly configured access controls.
Growing Cloud Security Along With Your Cloud
As the report explains, implementing cloud security automation tools that can perform tasks – such as auditing Infrastructure as Code (IaC) templates for security risks, scanning cloud environments for misconfigured ports and comparing cloud configurations to industry-accepted security benchmarks – go a long way toward keeping cloud workloads secure, even as they grow in size. Hiring security engineers who understand cloud-native development and can help programmers build secure applications is important, too.
In short, as organizations scaled up their cloud environments in response to the pandemic, they did not always scale up their security and governance processes at the same rate. The result has been an explosion in cloud security incidents across a variety of regions and industries. Although certain risks, such as cryptojacking, are on the decline, it’s imperative that organizations take steps to plug the vulnerabilities that continue to lurk within their cloud environments.
From 2019-20, we noticed a dramatic 1,160% increase in malicious PDF files – from 411,800 malicious files to 5,224,056. PDF files are an enticing phishing vector as they are cross-platform and allow attackers to engage with users, making their schemes more believable as opposed to a text-based email with just a plain link.
To lure users into clicking on embedded links and buttons in phishing PDF files, we have identified the top five schemes used by attackers in 2020 to carry out phishing attacks, which we have grouped as Fake Captcha, Coupon, Play Button,File Sharing and E-commerce.
To analyze the trends that we observed in 2020, we leveraged the data collected from the Palo Alto Networks WildFire platform. We collected a subset of phishing PDF samples throughout 2020 on a weekly basis. We then employed various heuristic-based processing and manual analysis to identify top themes in the collected dataset. Once these were identified, we created Yara rules that matched the files in each bucket, and applied the Yara rules across all the malicious PDF files that we observed through WildFire.
Data Overview
In 2020, we observed more than 5 million malicious PDF files. Table 1 shows the increase in the percentage of malicious PDF files we observed in 2020 compared to 2019.
Malware
Total PDF Files Seen
Percentage of PDF Malware
Percentage Increase
2019
411,800
4,558,826,227
0.009%
1,160%
2020
5,224,056
6,707,266,410
0.08%
Table 1. Distribution of malicious PDF samples in 2019 and 2020.
The pie chart in Figure 1 gives an overview of how each of the top trends and schemes were distributed. The largest number of malicious PDF files that we observed through WildFire belonged to the fake “CAPTCHA” category. In the following sections, we will go over each scheme in detail. We do not discuss the ones that fall into the “Other” category, as they include too much variation and do not demonstrate a common theme.
Figure 1. Malicious PDF trends in 2020.
Usage of Traffic Redirection
After studying different malicious PDF campaigns, we found a common technique that was used among the majority of them: usage of traffic redirection.
Before we review the different PDF phishing campaigns, we will discuss the importance of traffic redirection in malicious and phishing PDF files. The links embedded in phishing PDF files often take the user to a gating website, from where they are either redirected to a malicious website, or to several of them in a sequential manner. Instead of embedding a final phishing website – which can be subject to frequent takedowns – the attacker can extend the shelf life of the phishing PDF lure and also evade detection. Additionally, the final objective of the lure can be changed as needed (e.g. the attacker could choose to change the final website from a credential stealing site to a credit card fraud site). Not specific to PDF files, the technique of traffic redirection for malware-based websites is heavily discussed in “Analysis of Redirection Caused by Web-based Malware” by Takata et al.
Phishing Trends With PDF Files
We identified the top five phishing schemes from our dataset and will break them down in the order of their distribution. It is important to keep in mind that phishing PDF files often act as a secondary step and work in conjunction with their carrier (e.g., an email or a web post that contains them).
1. Fake CAPTCHA
Fake CAPTCHA PDF files, as the name suggests, demands that users verify themselves through a fake CAPTCHA. CAPTCHAs are challenge-response tests that help determine whether or not a user is human. However, the phishing PDF files we observed do not use a real CAPTCHA, but instead an embedded image of a CAPTCHA test. As soon as users try to “verify” themselves by clicking on the continue button, they are taken to an attacker-controlled website. Figure 2 shows an example of a PDF file with an embedded fake CAPTCHA, which is just a clickable image. A detailed analysis of the full attack chain for these files is included in the section Fake CAPTCHA Analysis.
Figure 2. Phishing PDF with a fake CAPTCHA asking users to click on “Continue” to verify themselves.
2. Coupon
The second category that we identified were phishing PDF files that were coupon-themed and often used a logo of a prominent oil company. A considerable amount of these files were in Russian with notes such as “ПОЛУЧИТЬ 50% СКИДКУ” and “ЖМИТЕ НА КАРТИНКУ” which translate to “get 50% discount” and “click on picture” respectively. Figure 3 shows an example of these types of phishing PDF files:
Figure 3. Phishing PDF file with a logo of a prominent oil company asking the user to click on the picture.
Similar to other campaigns we observed, these phishing files also leveraged traffic redirection for reasons mentioned previously. Upon analyzing several of them, we found out that they use two traffic redirectors. Figure 4 shows the chain for a sample (SHA256: 5706746b7e09b743a90e3458e5921367a66a5c3cfbd9417ed082dea586b7986e).
Figure 4. Attack chain for a coupon-themed sample.
The gating website took us to another website (track[.]backtoblack.xyz), which was a redirector itself. Eventually, we were routed to an adult dating website through a GET request with some parameters filled such as click_id, which can be used for monetization as shown in Figure 5. All these redirections happened through HTTP 302 response messages. Our research showed that the offer_id parameter of backtoblack[.]xyz controls what website the user lands on at the end.
Figure 5. Phishing PDF sample lands the user on a registration page of an adult dating website.
3. Static Image With a Play Button
These phishing files do not necessarily carry a specific message, as they are mostly static images with a picture of a play button ingrained in them. Although we observed several categories of images, a significant portion of them either used nudity or followed specific monetary themes such as Bitcoin, stock charts and the like to lure users into clicking the play button. Figure 6 shows a PDF file with a Bitcoin logo and a clickable play button.
Figure 6. Bitcoin logo with a clickable play button.
Upon clicking the play button, we were again, as expected, redirected to another website. In the majority of our tests, we were redirected to https://gerl-s[.]online/?s1=ptt1. From the domain name, one could assume the website is also within the realm of online dating. However, at the time of this writing, this website had been taken down. Unlike the previous campaign, there was only one redirector involved, and we noticed that all the redirectors had the format of: 6-digit-alphanumeric-unique-id[dot]sed followed by a main domain as listed below.
http://pn9yozq[.]sed.notifyafriend.com/
http://l8cag6n[.]sed.theangeltones.com/
http://9ltnsan[.]sed.roxannearian.com/
http://wnj0e4l[.]sed.ventasdirectas.com/
http://x6pd3rd[.]sed.ojjdp.com/
http://ik92b69[.]sed.chingandchang.com/
http://of8nso0[.]sed.lickinlesbians.com/
4. File Sharing
Figure 7. Phishing PDF with a logo of a popular file sharing platform asking the user to click on the button for access.
This category of phishing PDF files utilizes popular online file sharing services to grab the user’s attention. They often inform the user that someone has shared a document with them. However, due to reasons which can vary from one PDF file to another, the user cannot see the content and apparently needs to click on an embedded button or a link. Figure 7 shows a PDF with a Dropbox logo asking the user to click on the button to request access. Figure 8 similarly shows a picture of a PDF file with a OneDrive logo, asking the user to click on “Access Document” to view the content of the file. As the number of cloud-based file sharing services increases, it would not be surprising to see this theme surge and continue to be among the most popular approaches.
Figure 8. Phishing PDF file asking the user to click on “Access Document” to view the shared file.
Clicking on the “Access Document” button took us to a login page with an Atlassian logo, as shown in Figure 9. We were given two options to use for signing in: Microsoft email or other email services.
Figure 9. Phishing website asking the user to log in with one of the provided email options.
Atlassian Stack is geared towards enterprises, so we assume that this campaign was targeting enterprise users. Each of those links were designed to look like a legitimate email sign-on page. For instance, “Continue with Microsoft” took us to a page that looked somewhat similar to what one would encounter upon entering the legitimate https://login.live.com, as shown in Figure 10.
Figure 10. Phishing website looking like Microsoft’s login page. Note the URL, which gives away that the page is not legitimate.
After we entered a fake email address, we proceeded to another page that asked us to enter our password, as shown in Figure 11.
Figure 11. To closely imitate login.live.com, the “Enter password” page comes after the user enters a valid username. Note the URL, which indicates a scam site.
We observed that the stolen credentials were sent on the attacker's server through the parameters in a GET request, as shown in Figure 12.
Figure 12. Phished credentials submitted to the attacker's server through a GET request.
After entering the test credentials, we were taken back to the first login page. We would like to note that, at the time that we visited this website, it was already flagged as phishing by major browsers such as Google Chrome and Mozilla Firefox. However, we clicked through the warning page to investigate further.
5. E-commerce
Incorporating e-commerce themes into phishing emails and documents is not a new trend. However, we observed an upward trend in the number of fraudulent PDF files that used common e-commerce brands to trick users into clicking on embedded links. Figure 13 shows an example phishing PDF file notifying the user that their credit card is no longer valid, and they need to “update payment information” to not have their Amazon Prime benefit interrupted. Figure 14, similarly, shows a PDF file telling the user their Apple ID account will be suspended if they do not click on the link to update their information.
Figure 13. Phishing PDF file claiming the user’s credit card is about to expire on a well-known e-commerce website.Figure 14. Phishing PDF file claiming the user’s Apple ID is about to be disabled.
At the time of this writing, all the websites for this specific campaign were taken down. It is worth noting that the majority of these e-commerce themed phishing PDF files used https://t.umblr[.]com/ for redirection purposes. Examples include:
As previously mentioned, close to 40% of phishing PDF files that we saw in 2020 were part of the fake CAPTCHA category. Figure 15 shows the hex content of a fake CAPTCHA sample (SHA256: 21f225942de6aab545736f5d2cc516376776d3f3080de21fcb06aa71749fc18f). We can see that the PDF file has an embedded Uniform Resource Identifier (URI) that points to https://ggtraff[.]ru/pify?keyword=download+limbo+apk+full+game, which is a traffic redirector. As mentioned earlier, traffic redirection websites do not point to a fixed website, and they often redirect the user to a different website upon each visit.
Figure 15. Embedded URL in a fake CAPTCHA sample.
Figure 16 is the HTTP response body that we got from the aforementioned URI during one of our tries. The returned response from the redirector was a small JavaScript code stub that again redirects the user, but this time to: https://robotornotcheckonline[.]xyz/?p=miywentfmi5gi3bpgizdqnzv&sub1=wbly&sub3=1h6oih4jofeu&sub4=download+limbo+apk+full+game.
Figure 16. URL redirecting the user to robotornotcheckonline[.]xyzTo understand the whole chain, we followed the link from Figure 16. The response was a multi-function JavaScript code that can be seen in Figure 17.
Figure 17. JavaScript code that asks the user to subscribe to push notifications.
Essentially, the code listed above registers a browser push notification. Mozilla describes browser push notifications as follows: “Notifications API lets a web page or app send notifications that are displayed outside the page at the system level; this lets web apps send information to a user even if the application is idle or in the background.” Figure 18 shows the permission request when visiting the website in a browser.
Figure 18. robotornotcheckonline[.]xyz asking the user to subscribe to their push notifications By clicking on “Allow”, the user is then redirected to another website that asks them to subscribe to another push notification. When the user agrees and subscribes to the push notification, the function SubS() from Figure 17 is called, which sends a POST request to let the controller know that the user has subscribed to them. Figure 19 shows the specific POST request. We can see that there are a few parameters with unique values such as “key” and “secret” that are sent along to fingerprint the user.
Figure 19. POST request notifying the controller that the user has subscribed to their notifications.
This loop can go on a few times. However, it is important to note that the site does not have to be open in the browser for the notifications to pop. After completing the chain, we noticed two push notifications were registered in our browser, as shown in Figure 20. This now registers our browser as a “target” for these websites to send future popups for additional malvertising websites and extension installations.
Figure 20. Fake CAPTCHA sample resulting in the registration of two push notifications.
At the end, we landed on an online gaming website. Below is the HTTP GET request used:
As we can see, there are a lot of parameters involved with the above GET request. It is our assumption that this is how the attackers generate revenue. These identifiers tell the owner of the website how the user got there. If it was through the means that the attacker leveraged, the attacker in return gets a commision of some sort for bringing the users to that website. We also noticed Urchin Tracking Module parameters were also used to evaluate the effectiveness of this “marketing” method. To keep a stream of revenue, instead of a one-time click, it appears to us that attackers are leveraging push notifications. That way they can, once in a while, use the notification mechanism to deceive subscribed users into clicking on more links, and hence generate more revenue. As previously mentioned, our analysis has shown that fake CAPTCHA phishing samples have embedded links that point to traffic redirection websites, which then redirect the user to a different website upon each visit. To better understand where else these phishing files can lead us to, we decided to visit them a few more times. On one of those instances, we were not only presented with a page that asked us to subscribe to their push notifications, we were also asked to download a Google Chrome extension, as shown in Figure 21.
Figure 21. Traffic redirection website taking us to a website that subscribes users to push notifications and asks them to download a Chrome extension
When “Add to Chrome” was clicked, we were then taken to the Chrome Web Store (“CWS”). CWS is Google's online store that hosts browser extensions. Figure 22 shows the extension on the CWS with more than a thousand downloads.
Note: at the time of the publication the extension was not available on Chrome Web Store anymore.
Figure 22. HDSportSearch plugin with more than 1,000 downloads on Chrome Web Store.
Upon downloading and analyzing the extension, the manifest.json file bundled in the extension package revealed that the HDSportSearch extension is a search engine hijacker that overrides the search engine default values for the browser, as shown in Figure 23.
Figure 23. manifest.json for HDSportSearch plugin overriding Chrome’s settings.
Figure 24 summarizes the paths we were able to explore for the PDF phishing file with a fake CAPTCHA.
Figure 24. Paths and actions that a PDF with a fake CAPTCHA can take.
Conclusion
We covered the most common PDF-based phishing campaigns that we saw in 2020 along with their distribution. Data from recent years demonstrates that the amount of phishing attacks continues to increase and social engineering is the main vector for attackers to take advantage of users. Prior research has shown that large-scale phishing can have a click-through rate of up to 8%. Thus, it is important to verify and double check the files you receive unexpectedly, even if they are from an entity that you know and trust. For example, why was your account locked out of nowhere, or why did someone share a file with you when you least expected it?
Palo Alto Networks customers are protected against attacks from such phishing documents through various services:
Cortex XDR (protects against phishing document delivery and execution).
Next-Generation Firewalls with security subscriptions including WildFire and Threat Prevention (protects against phishing document delivery), URL Filtering (protects against redirectors and final phishing URLs) and DNS Security (protects against redirectors and final phishing domains).
AutoFocus users can track some of these PDF phishing campaigns under the Autofocus tag GenericPhishingDocs.
Hancitor is an information stealer and malware downloader used by a threat actor designated as MAN1, Moskalvzapoe or TA511. In a threat brief from 2018, we noted Hancitor was relatively unsophisticated, but it would remain a threat for years to come. Approximately three years later, Hancitor remains a threat and has evolved to use tools like Cobalt Strike. In recent months, this actor began using a network ping tool to help enumerate the Active Directory (AD) environment of infected hosts. This blog illustrates how the threat actor behind Hancitor uses the network ping tool, so security professionals can better identify and block its use.
As early as October 2020, Hancitor began utilizing Cobalt Strike and some of these infections utilized a network ping tool to enumerate the infected host’s internal network. Normal ping activity is low to nonexistent within a Local Area Network (LAN), but this ping tool generates approximately 1.5 GB of Internet Control Message Protocol (ICMP) traffic as it pings more than 17 million IP addresses of internal, non-routable IPv4 address space.
To understand how this ping tool is used, we must first understand the chain of events for current Hancitor activity. This blog reviews examples of recent Hancitor infections within AD environments. This blog also contains relatively new indicators noted from this threat actor as of February 2021, and it provides five examples of the associated network ping tool seen in December 2020 and January 2021.
Palo Alto Networks has shared our findings, including file samples and indicators of compromise described in this report, with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors.
Chain of Events for Recent Hancitor Infections
Since Nov. 5, 2020, the actor pushing Hancitor has displayed consistent patterns of infection activity. See Figure 1 for a flow chart showing the chain of events.
Figure 1. Hancitor chain of events.
The chain of events for recent Hancitor infections is:
Email with link to a malicious page hosted on Google Drive.
Link from a Google Drive page to a URL that returns a malicious Word document.
Enable macros (per instructions in Word document text).
Hancitor DLL is dropped and run using rundll32.exe.
Hancitor generates command and control (C2) traffic.
Hancitor C2 leads to Cobalt Strike activity in AD environments.
Hancitor-related Cobalt Strike activity can send other files, such as a network ping tool or malware based on the NetSupport Manager Remote Access Tool (RAT).
First Stage: Distributing Malicious Word Documents
Hancitor has historically sent emails spoofing different types of organizations that send notices, faxes or invoices. Emails spoofing DocSign have been reported as early as October 2017, but the group behind Hancitor began more frequent use of DocuSign templates starting in October 2019. Currently, most waves of emails pushing Hancitor have used a DocuSign theme, and the average wave of Hancitor malspam looks like this one reported on Jan. 12, 2021.
These DocuSign-themed messages have links to malicious Google Drive pages established through fraudulent or possibly compromised Google accounts. Cloud-based collaborative services such as Microsoft’s OneDrive and Google Drive are frequently abused by threat actors to distribute malware.
Google Drive links from emails pushing Hancitor start with https://docs.google.com/document/d/e/2PACX- and end with /pub. This URL pattern has also been noted pushing other families of malware.
To get a better idea of these URLs, examples from a wave of Hancitor emails on February 8th, 2021, are shown below in Table 1. Google was notified of these links, and they have been taken offline.
Table 1. Seven examples of malicious Google Drive links from DocuSign-themed emails pushing Hancitor on Feb. 8, 2021.
A recent example from an email is shown below in Figure 2.
Figure 2. Example of a fake DocuSign email pushing Hancitor from Feb. 2, 2021.
Of note, any Google Drive URL that starts with https://docs.google.com/document/d/e/2PACX- and ends with /pub is not inherently malicious. However, they are definitely suspicious when found in unsolicited emails.
These Google Drive URLs display a web page with a link to download a Word document. Figure 3 shows an example of these malicious pages using Google Drive.
Figure 3. Google Drive link from fake DocuSign email on Feb. 2, 2021, shown in a web browser.
These pages link to malicious URLs using Google with various parameters, including the actual destination URL. In Figure 3 above, a link from a Google Drive page, obtained from a fake DocuSign email on Feb. 2, 2021, starts innocently enough with https://www.google.com/. However, after clicking the link, the web browser loads hxxp://ajlbulicidate[.]pt/squriming.php which is actually a malicious URL. Figure 4 shows the page from ajlbulicidate[.]pt as it is initially loaded.
Figure 4. Web browser immediately after clicking link from the Google Drive page.
The page from ajlbulicidate[.]pt contained a script with base64 text to create a malicious Word document. This script causes a browser to offer the malicious Word document for download, then it redirects to a DocuSign page as shown in Figures 5 and 6.
Figure 5. Base64 text representing malicious Word document in script from web page hosted at ajlbulicidate[.]pt.Figure 6. Script offers to save malicious Word document, then redirects to a DocuSign URL.
The page at hxxp://ajlbulicidate[.]pt/squriming.php briefly appears before offering the Word document for download and redirecting to a DocuSign URL. Potential victims might only notice the DocuSign page and Word document. See Figure 7 for an example. This technique could lead potential victims to believe the Word document is a legitimate file sent by DocuSign.
Figure 7. Web browser a few seconds after clicking link in malicious Google Drive page from Figure 3.
Word documents originating from these DocuSign-themed messages use the template shown below in Figure 8.
Figure 8. Malicious Word document with macro for Hancitor based on DocuSign-themed malspam.
DocuSign is not the only theme and template used to push Hancitor. For example, on Feb. 9, 2021, malspam using a different email and document template pushed Hancitor malware. Except for the different templates, the infection process remained the same.
Appendix A lists 127 samples of SHA256 hashes for Word documents with macros for Hancitor from Nov. 5, 2020, through Feb. 25, 2021.
Second Stage: Hancitor Infects Victim
When macros are enabled for these malicious Word documents, the macro code drops and runs a malicious DLL file for Hancitor. The DLL file is contained within the macro code. In January and February 2021, these Hancitor DLLs were saved to one of two locations, as shown in Table 2.
Figure 9 shows one of the Hancitor DLL files from an infected host on Feb. 2, 2021.
Figure 9. Hancitor DLL from an infected Windows host on Feb. 2, 2021.
These Hancitor DLL files are run with rundll32.exe. An example from Feb. 2, 2021, revealed by Process Hacker, is shown below in Figure 10.
Figure 10. Process for Hancitor DLL shown in Process Hacker.
Network traffic caused by Hancitor starts with an IP address check by the infected Windows host. This IP address check goes to a legitimate service at api.ipify.org. The IP check is immediately followed by C2 traffic, as shown in a Wireshark column display below in Figure 11.
Figure 11. Wireshark column display showing IP address check and Hancitor C2 URLs.
From November 2020 through February 2021, Hancitor C2 traffic consisted of HTTP POST requests ending with /8/forum.php. Posted data includes the public IP address of the infected Windows host, the host name and user account name. Posted data also includes the version of Windows and domain information if the infected host is part of an AD environment. Finally, posted data also contains a Globally Unique Identifier (GUID) for the infected host and a build number for the Hancitor malware sample. See Figure 12 below for an example of recent Hancitor C2 traffic.
Figure 12. TCP stream from an example of Hancitor C2 traffic.
Appendix B lists 63 SHA256 hashes for samples of Hancitor DLL files from Nov. 5, 2020, through Feb. 25, 2021.
Third Stage: Hancitor Retrieves Follow-Up Malware
After Hancitor establishes C2 traffic, it retrieves follow-up malware. Each day, follow-up malware items for Hancitor are hosted on the same domain. For example, on Feb. 2, 2021, follow-up malware for Hancitor was hosted at bobcvatofredding[.]com. Table 3 shows a few recent examples of URLs for follow-up malware by Hancitor.
Date
URL
Follow-Up Malware
2021-01-19
hxxp://alumaicelodges[.]com/1901.bin
Cobalt Strike
2021-01-19
hxxp://alumaicelodges[.]com/1901s.bin
Cobalt Strike
2021-01-19
hxxp://alumaicelodges[.]com/fls.exe
Ficker Stealer
2021-01-20
hxxp://ferguslawn[.]com/2001.bin
Cobalt Strike
2021-01-20
hxxp://ferguslawn[.]com/2001s.bin
Cobalt Strike
2021-01-20
hxxp://ferguslawn[.]com/6fokjewkj.exe
Ficker Stealer
2021-01-27
hxxp://onlybamboofabrics[.]com/2701.bin
Cobalt Strike
2021-01-27
hxxp://onlybamboofabrics[.]com/27012.bin
Cobalt Strike
2021-01-27
hxxp://onlybamboofabrics[.]com/6gdwwv.exe
Ficker Stealer
2021-02-02
hxxp://bobcatofredding[.]com/0102.bin
Cobalt Strike
2021-02-02
hxxp://bobcatofredding[.]com/0102s.bin
Cobalt Strike
2021-02-02
hxxp://bobcatofredding[.]com/6lavfdk.exe
Ficker Stealer
2021-02-10
hxxp://backupez[.]com/0902.bin
Cobalt Strike
2021-02-10
hxxp://backupez[.]com/0902s.bin
Cobalt Strike
2021-02-10
hxxp://backupez[.]com/6yudfgh.exe
Ficker Stealer
2021-02-10
hxxp://backupez[.]com/47.exe
Send-Safe spambot malware
Table 3. Examples of URLs for follow-up malware seen from recent Hancitor infections.
Hancitor will only send Cobalt Strike when it infects a host in an AD environment. It will not send Cobalt Strike if the computer is a standalone host like a home computer. Hancitor generally sends Ficker Stealer for any host it infects.
Post-infection traffic is the easiest way to identify follow-up malware from a Hancitor infection. Ficker Stealer causes different traffic than Cobalt Strike. Figure 13 shows traffic from an infection on Feb. 2, 2021, and it highlights items related to Ficker Stealer.
Figure 13. Traffic from a Hancitor infection, highlighting items related to Ficker Stealer.
Appendix D contains information on the Ficker Stealer malware samples associated with Hancitor from October 2020-March 2021.
Figure 14 below shows the same traffic, but it highlights items related to Cobalt Strike.
Figure 14. Same traffic from a Hancitor infection, highlighting items related to Cobalt Strike.
Ficker Stealer and Cobalt Strike do not leave any artifacts saved to disk on an infected host. Ficker Stealer is a "smash and grab" style of malware designed to exfiltrate data, and it does not remain on an infected host. Cobalt Strike is resident in system memory, and it did not survive a reboot in our test environment.
Another file that appeared on Hancitor-infected hosts after Cobalt Strike started was a Windows EXE file for a network ping tool.
This EXE file started appearing as early as Dec. 15, 2020, and we noted various file hashes through at least Jan. 25, 2021. The network ping tool was always saved to the same directory as the Hancitor Word document.
Figure 15 shows an example of the tool seen on Jan. 13, 2021, after a Hancitor Word document was saved to the infected user’s Documents folder.
Figure 15. An example of the network ping tool from a Hancitor infection with Cobalt Strike on Jan. 13, 2021.
As seen in Figure 15, the EXE file was named xx.exe. A week later on Jan. 20, a new sample of the same tool was named netpingall.exe, as shown in Figure 16.
Figure 16. An example of the network ping tool from a Hancitor with Cobalt Strike infection on Jan. 20, 2021.
Timestamps from the Jan. 20, 2021, infection show the following:
0120_203089882.doc – Word doc with macros for Hancitor – 16:27 UTC
netpingall.exe – Network ping tool seen after Cobalt Strike - 17:19 UTC
result.txt – Results of the network ping tool scan – 18:18 UTC
An EXE for the network ping tool appeared approximately 52 minutes after the Word document for Hancitor was saved to disk. Approximately 59 minutes after the network ping tool appeared, the results of the scan were saved to a text file named result.txt.
This ping tool is designed to find any other active hosts within an AD environment. The tool generates approximately 1.5 GB of ICMP ping traffic over the network as it pings more than 17 million IP addresses of internal, non-routable IPv4 address space.
Normally, ping traffic to internal, non-routable IPv4 addresses is almost nonexistent in an AD environment. Ping traffic within internal IP address space should be limited to the LAN. For example, a LAN environment for 172.16.1.0/24 consists of 254 internal IP addresses that a host might ping within this network. We would not normally see ping traffic to other non-routable IPv4 space outside of those 254 IP addresses.
We tested samples of this ping tool in various sizes of LAN environments, and it consistently generates 1.5 GB of ICMP ping traffic to more than 17 million non-routable IPv4 addresses.
This is exceedingly noisy traffic. Furthermore, Hancitor has demonstrated a noticeable lack of stealth in deploying and using this ping tool. Such an unusual EXE file is easy to notice, especially when the results of its scan are saved as a text file in the same directory.
For Hancitor infections involving this ping tool, the associated files were never deleted after saving the results to result.txt, so any forensic investigation would quickly find this tool. The 1.5 GB of ICMP traffic should be very noticeable.
The ping tool generates ICMP ping traffic, first hitting all IP addresses in the 192.168.0.0/16 block. then it does the 172.16.0.0/12 block, and it finishes with the 10.0.0.0/8 block.
Figure 17. An example of the start of ICMP traffic from one of the network ping tool samples.
Since Jan. 25, 2021, we have not discovered any new ping tool samples from Hancitor infections with Cobalt Strike. Why can we no longer find it? Perhaps the threat actor behind Hancitor realized how suspicious this activity is and stopped using it.
Appendix C lists information for five samples of the network ping tool discovered from Hancitor infections with Cobalt Strike that appeared in December 2020 and January 2021.
Conclusion
Post-infection activity from Hancitor malware has settled into noticeable patterns. These patterns include the use of Cobalt Strike for a Hancitor infection within an AD environment. In some cases, follow-up malware sent through Cobalt Strike may include a network ping tool that generates an abnormally large amount of ICMP traffic as it pings over 17 million internal IPv4 addresses.
Organizations with decent spam filtering, proper system administration and up-to-date Windows hosts have a much lower risk of infection from Hancitor and its post-infection activity. Palo Alto Networks Next-Generation Firewall customers are further protected from this threat with a Threat Prevention security subscription.
Palo Alto Networks has shared our findings, including file samples and indicators of compromise described in this report, with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit www.cyberthreatalliance.org.
Indicators of Compromise
Appendix A
SHA256 hashes for 127 samples of Word documents with macros for Hancitor from Nov. 5, 2020, through Feb. 25, 2021. Information is available in this GitHub repository.
Appendix B
SHA256 hashes for 63 examples of Hancitor DLL files from Nov. 5, 2020, through Feb. 25, 2021. Information is available in this GitHub repository.
Appendix C
Information for five samples of the network ping tool seen from Hancitor infections using Cobalt Strike from December 2020-January 2021. Information is available in this GitHub repository.
Appendix D
Information for three samples of Ficker Stealer malware associated with Hancitor infections from October 2020 through March 2021. Information is available in this GitHub repository.
Appendix E
Information for a sample Send-Safe spambot malware associated with a Hancitor infection from February 2021. Information is available in this GitHub repository.
In recent years, Remote Desktop Protocol (RDP) has been exploited by attackers to access unsecured servers and enterprise networks. Since 2017, RDP has become a significant vector in malware attacks using ransomware. Security professionals have increasingly focused their attention on this protocol by writing signatures to detect RDP vulnerabilities and prevent attacks.
As a proprietary protocol from Microsoft, RDP supports several operating modes that encrypt network traffic. Unfortunately, this encryption makes writing RDP signatures difficult because RDP content is hidden.
Fortunately, we can establish a test environment that provides a key file, and we can use that key to decrypt a packet capture (pcap) of the RDP traffic in Wireshark.
This blog demonstrates how to prepare the environment, obtain a decryption key and use it to decrypt RDP traffic.
Requirements
The following are necessary to get the most value from this tutorial:
A virtual environment to run two Windows hosts like VirtualBox or VMware.
An understanding of how to set up and use RDP.
An RDP client. We use a host running Windows 10 Professional for this tutorial.
An RDP server. This can be another Windows host with RDP enabled, or it can be a non-Windows host running FreeRDP.
A way to record the network traffic between these two hosts. This is most easily done within a virtual environment.
Wireshark version 3.0 or better.
A basic knowledge of network traffic fundamentals.
Overall Process
The overall process follows seven general steps:
Step 1: Set up a virtual environment with two hosts, one acting as an RDP client and one acting as an RDP server.
Step 2: Remove forward secrecy ciphers from the RDP client.
Step 3: Obtain the RDP server's private encryption key.
Step 4: Capture RDP traffic between the RDP server and Windows client.
Step 5: Open the pcap in Wireshark.
Step 6: Load the key in Wireshark.
Step 7: Examine RDP data.
Step 1: Set Up Virtual Environment
The two most common virtual environments for this type of analysis are VirtualBox or VMware Workstation for Windows and Linux. VMWare Fusion is used for macOS. VirtualBox is free, while VMware is a commercial product.
This tutorial does not cover setting up virtual machines (VMs) in a virtual environment. The basic structure of our lab used for this tutorial is shown below in Figure 1.
Figure 1. Lab setup used for this tutorial.
Our lab environment contained two Windows 10 hosts. One of the hosts acted as an RDP client, and the other acted as an RDP server. We recorded network traffic from an RDP session between these two hosts from the virtual LAN.
Step 2: Remove Forward Secrecy Ciphers From RDP Client
Some encryption ciphers provide forward secrecy, which is also known as perfect forward secrecy. These types of ciphers create multiple session keys for an SSL/TLS connection. With forward secrecy, we cannot decrypt SSL/TLS traffic using a single private encryption key from the RDP server. Therefore, we had to remove configuration options that support forward secrecy on the RDP client.
For this tutorial, our RDP client was a host running Windows 10 Pro. This host has a built-in RDP client.
Open the Group Policy Management Console gpedit.msc as an administrator as shown below in Figure 2.
Figure 2. Running the Group Policy Editor in Windows 10 Pro as an administrator.
From the console, use the following menu path:
Computer Configuration.
Administrative Templates.
Network.
SSL Configuration Settings.
Below, Figure 3 shows how to find SSL Configuration Settings.
Figure 3. Getting to the SSL Configuration Settings.
Under SSL Configuration Settings, double-click the entry for SSL Cipher Suite Order as shown below in Figure 4.
Figure 4. Getting to the SSL Cipher Suite Order.
Under the SSL Cipher Suite Order, click the Enabled option as shown below in Figure 5.
Figure 5. Enabling the SSL Cipher Suite Order.
Next, double-click the list of ciphers and select the entire list as shown below in Figure 6.
Figure 6. Selecting the list of ciphers.
Once the list has been selected, copy it as shown below in Figure 7.
Figure 7. Copying the list of ciphers.
Copy this list of ciphers into a text editor such as Notepad. Remove any ciphers that support Elliptic Curve cryptography using Diffie-Hellman Ephemeral (ECDHE) or Digital Signature Algorithm (ECDSA) encryption. These should be any entries with ECDHE and/or ECDSA in the name. In the example shown below in Figure 8, these ciphers were all located sequentially, so they were easy to delete from the text.
Figure 8. Deleting entries for ECDHE and ECDSA.
Our updated list of ciphers from Figure 8 is listed below in Table 1.
Table 1. Updated list after removing forward secrecy ciphers.
Paste the updated cipher list back into the SSL Cipher Suites Field, making sure to overwrite the original list. Click the Apply button, then click OK to close the window. You have now updated the list and can close the Group Policy Editor.
After we accomplished this step, we had to obtain the RDP server’s private key.
Step 3: Obtain RDP Server's Private Key
FreeRDP is one option to use as an RDP server. You can get FreeRDP from this GitHub repository, as well as build instructions. Make sure to set the WITH_SERVER=ON flag when creating the server. Once the server is built, you must provide it with a private key, or use one that comes with FreeRDP.
For our RDP server in this tutorial, we used another host running Windows 10 Pro. Then we extracted the private key from the host’s operating system.
To ensure our second Windows host acted as an RDP server, we enabled RDP. To enable RDP on a host running Windows 10 Pro, go to Windows Settings from the Start Menu, then select the System icon as shown below in Figure 9.
Figure 9. Getting to the Windows System settings.
Under the system settings, select Remote Desktop and click the switch for Enable Remote Desktop as shown below in Figure 10.
Figure 10. Enabling RDP in WIndows 10.
After setting up our second Windows host as an RDP server, we extracted the private key from its operating system.
To extract the server key, we could either use either Jailbreak or Mimikatz. We chose Jailbreak.
Jailbreak is a tool by iSECPartners that can export the server's RDP certificate. From the exported certificate, we could extract the private key.
To use Jailbreak, we downloaded the following Jailbreak binaires from this GitHub repository on our newly established RDP server:
EasyHook64.dll
jailbreak64.exe
jailbreakhook64.dll
jbstore2_64.exe
Note: The above files were used on a Windows 10 Pro 64-bit host downloaded on March 4, 2021. A screenshot of the GitHub page is shown below in Figure 11.
Figure 11. GitHub page for Jailbreak binaries.
After we downloaded the Jailbreak binaries, we opened a Command prompt with administrator privileges as shown below in Figure 12.
Figure 12. Opening a command prompt as an administrator.
In the command prompt, we went to the directory with the downloaded Jailbreak binaries. We ran the following command from this directory:
See Figure 13 below for an example of running the 64-bit command on our Windows host acting as the RDP server.
Figure 13. Running Jailbreak from the command prompt.
This command opened the certificate manager for our local machine. From the left column, we expanded Remote Desktop and went to the Certificates folder. This showed one certificate. If there had been more than one certificate, we would have selected the one with the most recent expiration date. We right-clicked on the certificate, selected All Tasks then used Export as shown below in Figure 14.
Figure 14. Exporting the RDP certificate.
When exporting the certificate, we made sure to select the option to export the private key as shown below in Figure 15.
Figure 15. Ensuring the private key is exported with the certificate.
For our host, we could only export the certificate as a PKCS #12 (.PFX) file as shown below in Figure 16.
Figure 16. Could only export the certificate as a .pfx file.
As shown below in Figure 17, the certificate had to have a password. Fortunately, we had no complexity requirements, so we used a single letter as the password.
Figure 17. The export process required a password for the certificate.
Finally, we exported our certificate with the private key as shown below in Figure 18.
Figure 18. Completing our certificate export.
As an alternative, we could have extracted the server’s certificate using Mimikatz instead of Jailbreak. The instructions for using Mimikatz to get the RDP server certificate are listed on GitHub.
Since our certificate was obtained using Jailbreak, we moved it to a Linux host and used OpenSSL to extract the key. First, we used the following OpenSSL command to extract the key in PEM format:
To remove the passphrase form the key, we also used the following command:
openssl rsa -in server_key.pem -out server.key
This provided us with the RDP server’s private key as shown below in Figure 19.
Figure 19. Private server key extracted from the certificate.
Before we could use the private server key, we needed to record an RDP session between our two Windows hosts and save it as a pcap.
Step 4: Capture RDP Traffic
With our two Windows hosts in the same virtual environment, we could use a tool like dumpcap, tcpdump or Wireshark itself to record network traffic in the VLAN using promiscuous mode. Once the recording started, our WIndows client used RDP to log in to the other Windows host acting as an RDP server. The host name of the server was DESKTOP-USER1PC.
Figure 20. Using the Remote Desktop Connection tool to log into our RDP server.
While the pcap was being recorded, we logged into DESKTOP-USER1PC and performed some basic tasks like opening documents and web browsing.
Figure 21. Performing some common desktop tasks through RDP.
After a minute or so, we logged off RDP and stopped recording network traffic from our VLAN.
Step 5: Open the pcap in Wireshark
We opened the pcap of our RDP session in Wireshark. When filtering on rdp in our Wireshark display filter, we saw no results because the RDP traffic was encrypted. Figure 22 shows the blank column display we saw when filtering for RDP in our pcap.
Figure 22. Filtering for RDP information, but no results, due to encrypted RDP traffic.
However, when we used our private server key to decrypt RDP traffic in Wireshark, the results looked much different.
Step 6: Load the Key in Wireshark
In the pcaps we recorded, the RDP server DESKTOP-USER1PC was at IP address 10.3.4.138, and RDP traffic took place over TCP port 3389. We needed this information to properly decrypt RDP traffic in Wireshark.
In Wireshark, we used the Preferences window and expanded the Protocols section as shown below in Figure 23.
Figure 23. Getting to the Protocols section of Wireshark’s preferences menu.
With Wireshark 3.x, use the TLS entry. If you are using Wireshark 2.x, use the SSL entry. For this section, there should be a button to edit the RSA keys list. We clicked the button and added the IP address of the RDP server, the RDP port (3389) and the location of the private key file. Our example is shown below in Figure 24.
Figure 24. Go to the TLS section and add the private key to the RSA keys list.
After Wireshark was set up to decrypt RDP traffic, we had much better results when reviewing the pcap.
Step 7: Examine RDP Data
After our key was loaded, our column display was no longer blank when filtering for RDP. We had several results as shown below in Figure 25.
Figure 25. Viewing the same RDP activity after the private key was loaded in Wireshark.
For security professionals who write signatures to find RDP vulnerabilities and attacks, the type of information revealed above in Figure 25 is critical to their work.
Conclusion
This blog reviewed how to establish an environment to decrypt traffic from an RDP session. This is easiest to do in a virtual LAN with two hosts running Windows 10 Professional. After ensuring the client did not use any forward secrecy ciphers, we extracted the private key from our Windows host acting as the RDP server. Then we easily recorded a pcap of network traffic. After the session finished, we were able to decrypt RDP traffic using the server’s private key.
This type of environment can help security professionals when writing signatures to detect RDP vulnerabilities and attacks.
For more help with Wireshark, see our previous tutorials:
Matrix is a ransomware family that was first identified publicly in December 2016. Over the years since its inception, it has primarily targeted small- to medium-sized organizations. As of 2019, it had been observed across geographic locations such as the U.S., Belgium, Taiwan, Singapore, Germany, Brazil, Chile, South Africa, Canada and the UK. While initially leveraging tactics such as spam email campaigns, propagation via Windows shortcuts and the RIG exploit kit for distribution, the primary attack vector for the Matrix ransomware family shifted in 2018 to brute forcing weak Remote Desktop Protocol (RDP) credentials. The shift to this attack methodology appears to be a recurring trend in similar targeted ransomware families such as Dharma, Ryuk and BitPaymer.
Matrix Ransomware Overview
Figure 1. Screenshot of Matrix ransom note
When executed, Matrix encrypts user files and network shares, as well as deleting volume shadow copies and disabling recovery options on the affected device. Like with many other ransomware variants, the ransom note delivered by Matrix demands payment in Bitcoin. Instead of spreading through an organization, past Matrix infections appear to have been more targeted in nature.
Matrix is unique in that instead of delivering a more conventional ransom note that demands a fixed ransom amount, the threat actors behind it ask victims to contact them directly and submit a small sample of about three to five files for decryption. This is done so the threat actors can determine a variable ransom based on factors such as the predicted value of the victim’s files or the current dollar value of Bitcoin.
As of 2020, Matrix ransomware has been seen appending the following file extensions on files: .MTXLOCK, .CORE, .ANN, .FOX, .KOK8, .KOK08, .NEWRAR, .FASTBOB, .FASTB, .EMAN, .THDA, .RAD, .EMAN50, .GMPF, .ATOM, .NOBAD, .TRU8, .FASTA, .JNSS, .FBK, .ITLOCK, .SPCT, .PRCP, .CHRB, .AL8G, .DEUS, .FG69, .JB88, .J91D, .S996, .[barboza40@yahoo.com], .[Linersmik@naver.com][Jinnyg@tutanota.com], .[poluz@tutanota.com], .[Yourencrypt@tutanota.com], .[Files4463@tuta.io], .[RestorFile@tutanota.com], .[RestoreFile@qq.com], .[oken@tutanota.com], .[Vfemacry@mail-on.us], .[d3336666@tutanota.com], and .[Bitmine8@tutanota.com]
In addition, Matrix has other variants, including one dubbed “Fox Ransomware,” which adds the “.FOX” extension to encrypted files.
This section documents relevant tactics, techniques and procedures (TTPs) used with Matrix and maps them directly to Palo Alto Networks product(s) and service(s). It also further instructs customers on how to ensure their devices are configured correctly.
Product / Service
Course of Action
Initial Access, Persistence, Lateral Movement
The below courses of action mitigate the following techniques:
Spearphishing Attachment [T1566.001], Valid Accounts [T1078], Replication Through Removable Media [T1091], Remote Desktop Protocol [T1021.001]
NGFW
Set up File Blocking
Ensure that security policies restrict User-ID Agent traffic from crossing into untrusted zones
Ensure application security policies exist when allowing traffic from an untrusted zone to a more trusted zone
Ensure 'Service setting of ANY' in a security policy allowing traffic does not exist
Ensure 'Security Policy' denying any/all traffic to/from IP addresses on Trusted Threat Intelligence Sources Exists
Ensure that User-ID is only enabled for internal trusted interfaces
Ensure that 'Include/Exclude Networks' is used if User-ID is enabled
Ensure that the User-ID Agent has minimal permissions if User-ID is enabled
Ensure that the User-ID service account does not have interactive logon rights
Ensure remote access capabilities for the User-ID service account are forbidden
Threat Prevention†
Ensure that antivirus profiles are set to block on all decoders except 'imap' and 'pop3'
Ensure a secure antivirus profile is applied to all relevant security policies
Ensure that all zones have Zone Protection Profiles with all Reconnaissance Protection settings enabled, tuned and set to appropriate actions
WildFire†
Ensure that WildFire file size upload limits are maximized
Ensure forwarding is enabled for all applications and file types in WildFire file blocking profiles
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
The below courses of action mitigate the following techniques: Windows Command Shell [T1059.003], Match Legitimate Name or Location [T1036.005], Services File Permissions Weakness [T1574.010], Disable or Modify Tools [T1562.001], Service Stop [T1489], Modify Registry [T1112], Data Encrypted for Impact [T1486], Inhibit System Recovery [T1490]
Cortex XDR
Enable Anti-Exploit Protection
Enable Anti-Malware Protection
Configure Restrictions Security Profile
Configure Behavioral Threat Protection under the Malware Security Profile
Cortex XSOAR
Deploy XSOAR Playbook - Ransomware Manual for incident response.
Table 1. Courses of Action for Matrix ransomware. †These capabilities are part of the NGFW security subscriptions service.
Conclusion
While targeted ransomware attacks are not new, Matrix is a prime example of how threat actors can enter into the pool of existing ransomware and cash out quickly by targeting low-hanging fruit. The ransom negotiation tactics used by the Matrix threat actors further amplifyies the dangerous impact that such an attack can have on its victims, especially given the volatile state of cryptocurrency value today. Furthermore, this malware family’s shift in tactics to RDP exploitation, following a similar shift seen in other ransomware groups, serves to emphasize the need for businesses to stay vigilant on current ransomware trends.
Palo Alto Networks detects and prevents Matrix in the following ways:
WildFire: All known samples are identified as malware.
As a cybercriminal, there are many ways to make a profit. One of the easiest ways is cryptojacking – the illegal use of someone else’s computing resources to mine cryptocurrencies. Container images are known as a simple way to distribute software, yet malicious cryptojacking images are also a simple way for attackers to distribute their cryptominers.
I decided to take an extensive look into Docker Hub and discovered 30 malicious images with a total number of 20 million pulls (which means the images were downloaded 20 million times), together accounting for cryptojacking operations worth US$200,000. In this post, I will elaborate on my findings and why it is reasonable to assume that there are many other undiscovered malicious images on Docker Hub and other public registries.
Palo Alto Networks Prisma Cloud customers are protected from these threats through the Cryptominers Runtime Detection feature and the Trusted Images feature. In addition, Palo Alto Networks Next-Generation Firewall customers with the Threat Prevention security subscription are protected against the delivery of these images.
Finding Malicious Cryptojacking Images
In the last several years, Unit 42 researchers have been witnessing cloud-based cryptojacking attacks in which miners are deployed using an image in Docker Hub.
The cloud is popular for cryptojacking attacks due to two main reasons:
The cloud consists of many instances for each target (e.g. lots of CPUs, lots of containers, lots of virtual machines), which can translate to big mining profits.
The cloud is hard to monitor. Miners can run undetected for a long time, and without any detection mechanisms in place, they may run until the user finds an inflated cloud usage bill and realizes that something is wrong.
Modern cloud technology is largely based on containers, and in some environments, Docker Hub is the default container registry. Attackers can take advantage of it to deploy miners on compromised clouds.
Because of all of the facts mentioned above, I wanted to see if I could find malicious cryptojacking images in Docker Hub. In my research, I found 30 images from 10 different Docker Hub accounts that account for over 20 million pulls.
Individuals improve their mining efficiency by using mining pools, and so do adversaries.
It is possible to check how many cryptocurrencies were mined to a mining pool account by inspecting the mining pool. Half of the images I found used a mining pool that shares this information, and by extrapolating from that half I estimated that, in total, in all of the attacks, US$200,000 worth of cryptocurrencies were mined.
Figure 1. Research findings.
In order to better understand the findings, I began classifying the results. With the help of public mining pools, I checked which cryptocurrency is mined, which cryptominer is used and how many coins have been mined.
Coin Distribution
My first discovery, perhaps not surprising to our returning readers, is that the most popular cryptocurrency for attackers to mine is Monero, just as we saw with Pro-Ocean, Cetus and many more.
Attackers favor Monero for three reasons:
Monero provides maximum anonymity. One of its features is that, unlike for other coins, Monero transitions are hidden. This privacy is perfect for cybercriminals because it means their activity is hidden. Hence, they won’t get banned from exchanges and it is easier for them to evade attempts to track their funds.
The Monero mining algorithm favors CPU mining, unlike many other cryptos that require ASICs or GPU for mining. This is convenient because all computers have CPUs. Thus, the miner can run effectively on any machine. This is even more suitable for containers, of which the vast majority run without a GPU.
Monero is a popular coin, and its exchange volume is around US$100 million a day, making it easy for the attackers to sell their coins.
The figure below demonstrates the cryptocurrency distribution of the cryptojacking images found on Docker Hub.
Figure 2. Cryptocurrency distribution.
Cryptominer Distribution
In most attacks that mine Monero, the attackers used XMRig, just as we saw with Hildegard and Graboid. XMRig is a popular Monero miner and is preferred by attackers because it’s easy to use, efficient and, most importantly, open source. Hence, attackers can modify its code.
For example, most Monero cryptominers forcibly donate some percentage of their mining time to the miner’s developers. One common modification attackers make is to change the donation percentage to 0.
Figure 3. Cryptominer distribution.
Image Tags
Container registries allow users to upgrade their images and in that process upload a new tag to the registry. Tags are a way to reference different versions of the same image.
When examining the tags of the images, I found that some images have different tags for different CPU architectures or operating systems. It seems like some attackers are versatile and add these tags in order to fit a broad range of potential victims that includes a number of operating systems (OS) and CPU architectures.
In some images, there are even tags with different types of cryptominers. This way, the attacker can choose the best cryptominer for the victim’s hardware.
The only thing that is common for all the tags in a certain image is the wallet address or the mining pool credentials. With the help of these identifiers, I could classify each campaign. After digging deeper, in some cases, I could see that there are numerous Docker Hub accounts that belong to the same campaign. For example, in previous research, Unit 42 found the malicious account azurenql. Now, we discovered that the campaign is broader and includes the accounts 021982, dockerxmrig, ggcloud1 and ggcloud2.
In my research, I was able to find additional images mining Monero for the same campaign described in recent Unit 42 findings on azurenql, adding over 10 million more pulls under the attacker’s name.
Conclusion
The cloud presents big opportunities for cryptojacking attacks. In my research, I used a cryptomining scanner that only detects simple cryptomining payloads. I also made sure any identified image was malicious by correlating the wallet address to previous attacks. Even with these simple tools, I was able to discover tens of images with millions of pulls. I suspect that this phenomenon may be bigger than what I found, with many instances in which the payload is not easily detectable.
Palo Alto Networks Prisma Cloud customers are protected from these threats through the Cryptominers Runtime Detection feature and the Trusted Images feature. In addition, Palo Alto Networks Next-Generation Firewall customers with the Threat Prevention security subscription are protected against the delivery of these images.
In April 2020, we reported on a large influx of COVID-19 themed phishing attacks starting in February 2020. With March 2021 marking the one-year anniversary that the World Health Organization declared COVID-19 a pandemic, we revisited the phishing trends we observed in the past year to gain deeper insight into the various COVID-related topics that attackers might try to exploit.
Starting with the set of all phishing URLs detected globally between January 2020 and February 2021, we generated sets of specific keywords (or phrases) that served as indicators for each COVID-related topic, and applied keyword matching to determine which phishing URLs were related to each topic. (To ensure that the matched URLs were indeed COVID-related, we iteratively spot-checked the resulting URLs and refined these keywords/phrases to minimize the incidence of false positives.)
We found that at each step along the way, attackers have continued to change their chosen tactics to adapt to the latest pandemic trends, in hopes that maintaining a timely sense of urgency will make it more likely for victims to give up their credentials.
We found phishing attacks largely centered around Personal Protective Equipment (PPE) and testing kits in March 2020, government stimulus programs from April through the summer 2020 (including a fake U.S. Trading Commission website that posed as the U.S. Federal Trade Commission in order to steal user credentials) and vaccines from late fall 2020 onward (including a fake Pfizer and BioNTech website also stealing user credentials). Of note, we found that vaccine-related phishing attacks rose by 530% from December 2020 to February 2021, and that phishing attacks relating to and/or targeting pharmacies and hospitals rose by 189% during that same timeframe.
We found no evidence that any of these efforts were successful, but are highlighting these cases to make healthcare organizations around the globe aware of this heightened activity targeting their sector, so they can alert employees to be on guard for malicious credential-phishing sites.
We predict that as the vaccine rollout continues, phishing attacks related to vaccine distribution – including attacks targeting the healthcare and life sciences industries – will continue to rise worldwide.
In addition to these security services, best practices to protect yourself and your organization from phishing attacks include:
For individuals:
Exercising caution when clicking on any links or attachments contained in suspicious emails, especially those relating to one’s account settings or personal information, or otherwise trying to convey a sense of urgency.
Verifying the sender address for any suspicious emails in your inbox.
Double-checking the URL and security certificate of each website before inputting your login credentials.
Reporting suspected phishing attempts.
For organizations:
Implementing security awareness training to improve employees’ ability to identify fraudulent emails
Regularly backing up your organization’s data as a defense against ransomware attacks initiated via phishing emails.
Enforcing multi-factor authentication on all business-related logins as an added layer of security.
Phishing Trends
Since January 2020, we have observed 69,950 phishing URLs linked to COVID-related topics, of which 33,447 are directly linked to COVID-19 itself. In Figure 1, we plot the relative popularity of these different topics over time, normalized so that each topic has a peak popularity of 100%. Looking at how the heights of each colored section differs over time, we can see that certain topics have remained steady targets of phishing attacks, while others have experienced more noticeable spikes at various points in time. Pharmaceutical drugs and gathering virtually (e.g. Zoom), for example, have been a relatively steady target of phishing attacks since the start of the pandemic; vaccines and testing, on the other hand, have experienced more defined peaks in popularity.
Figure 1. Trends in COVID-themed phishing attacks from January 2020-February 2021 (global).
For the COVID-19 themed phishing pages that were found to be targeting known brands, we determined that the majority of these pages were attempting to steal users’ business credentials: e.g. Microsoft, Webmail, Outlook, etc. Each bar in Figure 2 represents the percentage of phishing URLs that were attempting to steal users’ login credentials for that particular website. (For example, about 23% of COVID-themed phishing URLs were fake Microsoft login pages.) With the pandemic forcing many employees to shift to remote work, these business-related phishing attempts have become an increasingly important attack vector for cybercriminals.
Figure 2. Top phishing targets in COVID-related URLs (global). Each bar represents the percentage of phishing URLs attempting to steal users’ login credentials for that particular website. (Note that in this figure, we only include URLs that target identifiable brands.)
Furthermore, we notice that with these COVID-19 themed phishing attacks, attackers are constantly creating new websites to host their phishing campaigns. In Figure 3, which shows the age for each website that we found to host a COVID-related phishing page, we can see that many COVID-related phishing pages are hosted on newly created sites (we define this as sites that were first observed fewer than 32 days ago), suggesting that attackers purposefully set up these sites just days before their intended attacks. This gives the attackers the opportunity to craft the message surrounding the attack – as well as the website URL itself – to fit the latest pandemic trends.
Figure 3. Age of websites that host COVID-related phishing pages at time of detection (global).
January-March 2020: Initial Surge, Testing Kits and PPE
Between January and February 2020, as COVID-19 began its spread throughout the world, cybercriminals had already begun trying to use the soon-to-be pandemic to their advantage. During this timeframe, we observed a 313% increase in phishing attacks directly related to COVID-19.
In Figure 4, we see an example of a COVID-19 themed phishing attack. The fake Google Form first asks the user to input his or her email address and password in order to participate in a supposed company COVID-19 screening program. In the subsequent pages, the form asks a series of legitimate-sounding health-related questions, e.g. “Since your last day of work, have you had two or more of the following? Chills, Repeated shaking with chills, Headache, Muscle pain, Sore throat, New loss of taste or smell,” to give the impression that the form itself is legitimate. The final question before submission asks the employee to “digitally sign” the form by entering his or her full name.
Figure 4. https://docs[.]google[.]com/forms/d/e/1FAIpQLSdiQL-IcnGqRIKzTVmpeQSBVRrD06c4NolWvgWcdRH-NgBx-A/viewform?vc=0&c=0&w=1&flr=0 (Credential stealing form related to COVID-19 screening.)From February-March 2020, concern about COVID-19 spreading to the U.S. quickly became prominent. In response to people’s desire to protect themselves and their families, interest in testing kits, PPE such as hand sanitizer and N95 masks, and even essential goods like toilet paper began to rise rapidly.
Figure 5. Online interest in “COVID Test Kit” vs. COVID testing-related phishing prevalence (global data via Google Trends).
These trends are observable in our historical phishing data as well. In February 2020, we observed a 136% increase in PPE-related phishing attacks worldwide, many of which took the form of online shopping scams (see Figure 6 for an example). During the month of March, we observed a 750% increase in phishing attacks related to testing kits, just as The New York Times reported on a shortage of COVID tests across the U.S.
Figure 6. https://atemmaske-kn95-de[.]com (Scam website, translated from German to English).In addition to these scam sites, we also observed seemingly legitimate testing kit vendors whose websites had become compromised for credential stealing purposes. In Figure 8, we see a fake Microsoft Sharepoint login page that a user would be taken to via a link in a phishing email. The phishing page would ask for the user’s email and Microsoft password in order to view a time-sensitive invoice that had been “shared” with him or her.
Figure 7. covid-testkit[.]co[.]uk (A UK-based wholesaler of COVID-19 test kits)Figure 8. covid-testkit[.]co[.]uk/wp-includes/images/i/Newfilesviewc7c782c3b7c54f958e7eb2efff3a49b28866b4fc22dd46cfbad9e6ac9d0cd18cca873584897b48c88d82ecf5cd62783dServices (Credential stealing page on a compromised COVID-related website)
April-July 2020: Government Stimulus and Relief Programs
In April 2020, the IRS began distributing $1,200 stimulus checks to individuals as a part of the CARES Act. Around the same time, the Paycheck Protection Program (PPP) was put into action, promising to provide relief to small businesses across the U.S. Many business owners scrambled to get a piece of the funds, causing online interest in COVID stimulus and relief programs to surge, and funds to quickly run out.
Figure 9. Stimulus programs online interest vs. COVID government stimulus and relief-related phishing prevalence (global data via Google Trends).
Subsequently, we noticed that phishing attacks related to government relief programs increased by 600% in April 2020. In Figures 10-11, we show an example of a phishing page pretending to represent the “U.S. Trading Commission,” a fake branch of the U.S. federal government that the FTC warned about. The website promises up to $5,800 in “Temporary Relief Fund” grants for each individual. Fake statistics are displayed on the right-hand side of the page, giving the user the illusion that there are still billions of dollars left to distribute.
Figure 10. ungodsirealnighchis[.]gq/us/protecting-americas-consumers-covid/ (Fake website pretending to represent the “U.S. Trading Commission.”)Upon clicking a button saying “Start Verification Procedure,” the user is redirected to a form asking for their Social Security Number (SSN) and driver’s license number in order to receive these emergency COVID relief funds.
Figure 11. ungodsirealnighchis[.]gq/us/protecting-americas-consumers-covid/verification.php (Credential stealing form related to COVID government aid.)After completing the form, the confirmation page simply states: “Your response has been recorded. We will contact you as soon as possible. You may always contact us directly at 213-746-7272 for faster service.” (Note that this phone number is likely fake, since once the user has filled out the form, the attacker would already have the credentials they wanted.)
After the legitimate stimulus and relief programs were put in place, these economic relief-related phishing attacks stayed relatively popular for the months to come (see Figure 9), as many people were still in need of financial support. In Figure 12, we see another credential stealing page asking the user to input personal and corporate information, driver’s license photo and bank account details in order to receive additional relief funds from a “COVID-19 giveaway.” We see a similar example in Figure 13, which promises to send the user a free lockdown fund package of 3000 Indian rupees after inputting their bank account information.
Figure 12. covid-19-benefit[.]cabanova[.]com (Credential stealing page related to a supposed COVID relief giveaway.)Figure 13. fund4-covid19[.]com (Credential stealing site asking the user to input his or her bank account information in order to receive a limited-time “lockdown fund package.”)
November 2020-February 2021: Vaccine Approval and Rollout
For the next several months, various states settled into a state of on-and-off lockdowns, while people awaited news of a potential vaccine.
In November 2020, after months of anticipation, Pfizer and BioNTech released a promising set of initial results, showing over 90% vaccine effectiveness based on a subset of 94 participants in their real-world trial. In December, the U.S. Food and Drug Administration (FDA) granted emergency use authorization for Pfizer’s mRNA vaccine, after which the vaccine rollout began.
With many Americans now looking for a way to sign themselves and their family members up for immunization, it should be no surprise that cybercriminals would try to use this trend to their advantage. From December 2020 to February 2021, we observed a 530% increase in vaccine-related phishing attacks (see Figure 14).
Figure 14. “COVID Vaccine” online interest vs. COVID vaccine-related phishing prevalence (global data via Google Trends).
In Figures 15-16, we show an example of a fake website that claims to represent Pfizer and BioNTech, the makers of the mRNA vaccine. The phishing page asks the user to log in with his or her Office 365 credentials, supposedly in order to sign up for the vaccine.
Also note that this phishing website employs an increasingly common technique known as “client-side cloaking.” Rather than revealing the credential stealing form immediately, the website first asks the user to click the “Login” button, in an effort to evade automated, crawler-based phishing detectors.
Figure 15. pfizer-vaccine[.]online (Fake Pfizer website with client-side phishing cloaking.)Figure 16. pfizer-vaccine[.]online (Credential stealing form revealed after user clicks the “Login” button.)At the same time as attackers have started to capitalize on the vaccine registration process, they have also increased their targeting of hospitals and pharmacies – organizations that play a significant role in distributing the vaccine. According to a national survey conducted by the American Medical Association (AMA), 83% of physician practices have already been affected by cyberattacks at some point in the past. Now more than ever, we suspect that organizations involved in the production and distribution of the vaccine — a process involving high amounts of time-sensitive and confidential data that could be held for ransom — may be viewed as high-value targets for cybercrime.
From December 2020 to February 2021, we observed a 189% increase in attacks related to pharmacies and hospitals. Many of these attacks are part of larger clusters of phishing campaigns, where several different URLs are sent to different employees of the same organization, in the hopes that at least one of the employees will mistakenly input his or her credentials into the fake login page.
Perhaps unsurprisingly, given the global nature of COVID-19, these phishing campaigns targeting pharmaceutical and healthcare companies seem to be prevalent worldwide, not just in the U.S.
In certain cases, we also observe legitimate pharmaceutical companies whose websites have been compromised and used for phishing purposes. In Figure 17, we can see that a website belonging to a global life sciences technology marketplace company which had been compromised and used to host a phishing page for stealing users’ business credentials. These sorts of attacks can be particularly dangerous, as the legitimacy of the original website may trick users into incorrectly thinking that the phishing page is also legitimate.
Figure 17. A compromised website from a global life sciences technology marketplace being used for credential stealing.With the global vaccine rollout still very much in-progress, we expect that attacks related to the vaccine – and attacks targeting corresponding industries – will continue to rise as vaccine production and distribution continue to scale up over the coming months.
Conclusion
At various points during the COVID-19 pandemic, we have seen attackers shift their focus from one topic to another depending on the current state of events. In the early stages of the pandemic, testing kits and PPE were a significant area of focus for attackers. The focus then shifted to government stimulus and relief programs, before pivoting again to the vaccine rollout. As we have seen, attackers continually adapt to the newest trends. As a result, cybersecurity defenses must adapt as well.
Individuals should continue to exercise caution when viewing any emails or websites claiming to sell any goods or services or provide any benefits related to COVID-19. If it seems too good to be true, it most likely is. Employees in the healthcare industry in particular should view links contained in any incoming emails with suspicion, especially from emails trying to convey a sense of urgency.
General best practices to protect yourself and your organization from phishing attacks include:
For individuals:
Exercising caution when clicking on any links or attachments contained in suspicious emails, especially those relating to one’s account settings or personal information, or otherwise trying to convey a sense of urgency.
Verifying the sender address for any suspicious emails in your inbox.
Double-checking the URL and security certificate of each website before inputting your login credentials.
Reporting suspected phishing attempts.
For organizations:
Implementing security awareness training to improve employees’ ability to identify fraudulent emails
Regularly backing up your organization’s data as a defense against ransomware attacks initiated via phishing emails.
Enforcing multi-factor authentication on all business-related logins as an added layer of security.
In addition to these general best practices, Palo Alto Networks Next-Generation Firewall customers are protected from these threats in multiple ways:
URL Filtering has properly classified all of the phishing URLs mentioned in this blog, and will continue to automatically detect and block newly created phishing pages in the future.
DNS Security can help identify malicious domains, such as typosquatting domains and newly registered domains (NRDs) used specifically to host targeted phishing attacks.
To learn more about how Palo Alto Networks can help protect your organization during the pandemic, please see our response to COVID-19.
Acknowledgements
The author would like to thank Wei Wang, Wayne Xin, Jingwei Fan, Yu Zhang, and Seokkyung Chung for providing several data sources that were used in the analyses, and Jun Javier Wang, Kelvin Kwan, Vicky Ray, Laura Novak, Jen Miller-Osborn, Eddy Rivera and Erica Naone for their help with improving the blog.
Of the 15 new vulnerabilities credited to Unit 42 researchers, 10 come from Microsoft with severity ratings from low to important. The four Adobe Reader DC vulnerabilities are all critical bugs that allow remote code execution (RCE). Lastly, there is an Apple cross site scripting (XSS) vulnerability that could also lead to arbitrary RCE in the context of the currently logged in user.
The Unit 42 researchers credited are Tao Yan, Zhibin Zhang, Bo Qu, Ronen Haber and Ken Hsu.
The recently discovered vulnerabilities are listed in Table 1 below:
Specifically, the patch of CVE-2021-1711 addresses a new type of security issue that Unit 42 researchers discovered. Tao Yan, Qi Deng and Bo Qu will share more technical details at Black Hat Asia 2021.
Conclusion
Palo Alto Networks Next-Generation Firewall customers deploying a Threat Prevention security subscription, which includes capabilities such as vulnerability protection with an intrusion prevention system (IPS), are protected from zero-day vulnerabilities such as these. The WildFire security subscription provides our customers with comprehensive protection and automatic updates against previously unknown threats.
Weaponized exploits for these vulnerabilities are prevented by Cortex XDR’s multi-layered exploit prevention capabilities.
Palo Alto Networks is a regular contributor to vulnerability research in Microsoft, Adobe, Apple, Google Android and other ecosystems, with more than 300 critical vulnerabilities discovered. Our researchers give regular talks at security conferences such as Black Hat, Blue Hat and REcon.
By proactively identifying these vulnerabilities, developing protections for our customers and sharing the information with the security community, we are removing weapons used by attackers to threaten users and compromise enterprise, government and service provider networks.
On Feb. 20, 2021, Unit 42 researchers observed attempts to exploit CVE-2020-9020, which is a Remote Command Execution (RCE) vulnerability in Iteris’ Vantage Velocity field unit version 2.3.1, 2.4.2 and 3.0. As a travel data measurement system, Vantage Velocity captures travel data with a large number of vehicles. If a device is compromised, it will be under control of attackers, who can then leak sensitive data or conduct further attacks, such as Distributed Denial-of-Service (DDoS) attacks. The vulnerability has a critical rating (i.e., CVSS 3.1 score of 9.8) due to its low attack complexity, but critical security impact. The exploit captured by Unit 42 researchers utilized the vulnerability to spread Satori, a Mirai botnet variant.
Palo Alto Networks Next-Generation Firewall customers with security subscriptions such as Threat Prevention, WildFire, URL Filtering and IoT Security are able to detect and prevent the exploit traffic and the malware.
Vulnerability Analysis
The vulnerable devices lack a check on the htmlNtpServer parameter of /cgi-bin/timeconfig.py, allowing attackers to inject commands via crafted HTTP requests and have them executed on victim’s devices. This vulnerability was disclosed in early 2020, but the National Vulnerability Database (NVD) published it recently, not long before the exploit attempts.
Exploit in the Wild
On Feb. 20, 2021, Palo Alto Networks Next-Generation Firewall caught the first exploit attempt. As shown in Figure 1, the exploit attempted to download the file arm7 from the server 198[.]23[.]238[.]203 with the system command wget and then change the access permissions of the downloaded file to ensure it can be executed with the current user privileges.
Figure 1. Exploit request in the wild.
The server 198[.]23[.]238[.]203 was first noticed (serving a malicious shell script) by the security community on Feb. 17, 2021, according to VirusTotal. At the time of this writing, the server is still accessible. It provides an HTTP service on port 80, based on Apache2 HTTP server, that provides a malware downloading service. It also has port 5684 opened, which is believed to serve as the command and control (C2).
According to our investigation, nine samples with similar functions but different platform compatibility were found on the server. They are able to run and compromise devices across multiple mainstream architectures. Thus, these malware can be easily utilized again when the attacker changes the exploit against other target systems.
The information for all nine samples are listed in the Indicators of Compromise (IoCs) section.
Mirai Botnet Variant (Satori)
Based on our in-depth investigation into the behaviors and patterns, we believe that the malware samples hosted on the server 198[.]23[.]238[.]203 are highly likely to be a variant of the Mirai botnet, Satori.
When executed, it prints the message “hello friend :)” to the console. Then, four child processes are spawned and detached from the main process.
The malware was observed to scan port 23 of random hosts (as shown in Figure 2) and tries to login with its embedded password dictionary when port 23 is open.
Figure 2. Satori port scanning.Figure 3. Passwords encrypted with XOR algorithm and key 0x07.
The passwords are encrypted using the XOR algorithm with a single byte key of 0x07, as shown in Figure 3.
The encrypted C2 traffic over SSL was also observed between the victim and 198[.]23[.]238[.]203:5684, as shown in Figure 4.
Figure 4. Traffic to C2 server.
The malware also contains multiple predefined operating system (OS) commands, as shown in Figure 5. Those commands are used to download and execute malicious payload from remote C2 servers to deploy bots on new victim devices.
Figure 5. Predefined OS commands.
Conclusion
CVE-2020-9020 is easy to exploit and can lead to RCE. After gaining control, attackers can take advantage and include the compromised devices in their botnet. Therefore, we strongly advise to apply patches and upgrade when possible.
Palo Alto Networks customers are protected from the vulnerability by the following products and services:
Next-Generation Firewalls with a Threat Prevention security subscription can block the attacks with Best Practices via Threat Prevention signature 90769.
WildFire can stop the malware with static signature detections.
URL Filtering can block malicious malware domains.
IoT Security can provide coverage on legacy IoT sensors.
To evaluate the scope of ransomware attacks and provide actionable steps to mitigate risk, the Unit 42 threat intelligence team and the Crypsis incident response team collaborated to analyze the ransomware threat landscape in 2020. With global data from Unit 42 as well as data from the U.S., Canada and Europe from Crypsis, the 2021 Unit 42 Ransomware Threat Report details key ransomware trends, variants and predictions, including:
2020 ransomware landscape observations, including how ransomware has tried to take advantage of the COVID-19 pandemic, shifts in threat actor approach and information on targeted platforms.
Average ransomware payments from organizations across the U.S., Canada and Europe.
Predictions for the future of ransomware, including our ideas of how the use of variants could increase and ransom demands could get higher. We also detail how we expect threat actors to leverage the ransomware-as-a-service model.
Actionable guidance on how to minimize risk and keep your organization safe from attacks.
To learn more specifics about major ransomware families, please see our previously published ransomware threat assessments on Maze, Ryuk, WastedLocker and Egregor.
On the pages that follow, you’ll find detailed ransomware threat assessments for several ransomware families covered in the report, including:
Ransomware is one of the top threats in cybersecurity and a focus area for Palo Alto Networks. The global threat intelligence team (Unit 42) and incident response team (The Crypsis Group) have partnered to create the 2021 Unit 42 Ransomware Threat Report to provide the latest insights on the top ransomware variants, ransomware payment trends and security best practices so we can understand and manage the threat.
To evaluate the current state of the ransomware threat landscape, the Unit 42 threat intelligence team and the Crypsis incident response team collaborated to analyze the ransomware threat landscape in 2020, with global data from Unit 42 as well as data from the U.S., Canada and Europe from Crypsis.
Key Findings
Cybercriminals Are Making, and Demanding, More Money Than Ever
Note: The following data is from the U.S., Canada and Europe.
The average ransom paid for organizations increased from US$115,123 in 2019 to $312,493 in 2020, a 171% year-over-year increase. Additionally, the highest ransom paid by an organization doubled from 2019 to 2020, from $5 million to $10 million. Meanwhile, cybercriminals are getting greedy. From 2015 to 2019, the highest ransomware demand was $15 million. In 2020, the highest ransomware demand grew to $30 million.
Of note, Maze ransom demands in 2020 averaged $4.8 million, a significant increase compared to the average of $847,344 across all ransomware families in 2020. Cybercriminals know they can make money with ransomware and are continuing to get bolder with their demands.
Healthcare Organizations in the Crosshairs
The world changed with COVID-19, and ransomware operators took advantage of the pandemic to prey on organizations – particularly the healthcare sector, which was the most targeted vertical for ransomware in 2020. Ransomware operators were brazen in their attacks in an attempt to make as much money as possible, knowing that healthcare organizations – which needed to continue operating to treat COVID-19 patients and help save lives – couldn't afford to have their systems locked out and would be more likely to pay a ransom.
Ryuk ransomware stood out from the pack. In October 2020, a joint cybersecurity advisory was issued by the Cybersecurity and Infrastructure Security Agency (CISA), the Federal Bureau of Investigation (FBI) and the Department of Health and Human Services (HHS), warning healthcare organizations against Ryuk attacks.
The Rise of Double Extortion
A common ransomware attack consists of the ransomware operator encrypting data and forcing the victim to pay a ransom to unlock it. In a case of double extortion, ransomware operators encrypt and steal data to further coerce a victim into paying a ransom. If the victim doesn’t pay the ransom, the ransomware operators then leak the data on a leak site or dark web domain, with the majority of leak sites hosted on the dark web. These hosting locations are created and managed by the ransomware operators. At least 16 different ransomware variants are now threatening to expose data or utilizing leak sites, and more variants will likely continue this trend.
The ransomware family that leveraged this tactic the most was NetWalker. From January 2020 to January 2021, NetWalker leaked data from 113 victim organizations globally, far surpassing other ransomware families. RagnarLocker was second, leaking data from 26 victims globally. It’s worth noting that the US Department of Justice announced in January 2021 that it had coordinated international law enforcement action to disrupt the NetWalker ransomware gang. The dark web domain managed by the NetWalker operators, which hosted leaked data, is no longer accessible.
Steps to Reduce Ransomware Exposure
Defending against ransomware attacks is similar to protecting against other malware. However, it represents a much higher risk to the organization.
Initial Access
Initial access is relatively consistent across all ransomware variants. Organizations should maintain user awareness and training for email security as well as consider ways to identify and remediate malicious email as soon as it enters an employee’s mailbox. Organizations should also ensure they conduct proper patch management and review which services may be exposed to the internet. Remote desktop services should be correctly configured and secured, using the principle of least privilege wherever possible, with a policy in place to detect patterns associated with brute-force attacks.
Backup and Recovery Process
Organizations should continue to back up their data and keep an appropriate recovery process in place. Ransomware operators will target on-site backups for encryption, so organizations should ensure that all backups are maintained securely offline. Recovery processes must be implemented and rehearsed with critical stakeholders to minimize downtime and cost to the organization in the event of a ransomware attack.
Security Controls
The most effective forms of protection from ransomware are endpoint security, URL filtering or web protection, advanced threat prevention (unknown threats/sandboxing) and anti-phishing solutions deployed to all enterprise environments and devices. While these will not outright guarantee prevention, they will drastically reduce the risk of infection from common variants and provide stopgap measures, allowing one technology to offer a line of enforcement when another may not be effective.
Possibly CVE-2019-19356 (a Netis WF2419 wireless router exploit).
Three other IoT vulnerabilities yet to be identified.
On Feb. 23, 2021, one of the IPs involved in the attack was updated to serve a Mirai variant leveraging CVE-2021-27561 and CVE-2021-27562, mere hours after vulnerability details were published. On March 3, 2021, the same samples were served from a third IP address, with the addition of an exploit leveraging CVE-2021-22502. Furthermore, on March 13, an exploit targeting CVE-2020-26919 was also incorporated into the samples.
The attacks are still ongoing at the time of this writing. Upon successful exploitation, the attackers try to download a malicious shell script, which contains further infection behaviors such as downloading and executing Mirai variants and brute-forcers.
Five known vulnerabilities and three unknown vulnerabilities were exploited in this attack. Upon successful exploitation, the wget utility is invoked to download a shell script from the malware infrastructure. The shell script then downloads several Mirai binaries compiled for different architectures and executes these downloaded binaries one by one. Vulnerability information is shown in Table 1, below.
The exploit of SonicWall SSL-VPN targets an old version of Bash, which is vulnerable to ShellShock. An attacker can send a crafted Common Gateway Interface (CGI) request to a particular shell script leading to an unauthenticated remote code execution (RCE) vulnerability.
The exploit targets a command injection vulnerability in a system_mgr.cgi component. The component does not successfully sanitize the value of the HTTP parameters f_ntp_server, which in turn leads to arbitrary command execution.
The exploit works by chaining a pre-auth Server-Side Request Forgery (SSRF) vulnerability and a command injection vulnerability, making it possible to execute commands as root without authentication, simply by sending an HTTPS request to the remote target.
The exploit works due to the unsanitized use of the “username” and “password” parameters in requests made to the LogonResource API. The vulnerability can be exploited to allow unauthenticated RCE as root on the OBR server.
The exploit targets an RCE vulnerability in a diagnostic tool utility. An authenticated attacker can perform command execution via multiple vulnerable parameters such as IP address or domain name.
6. CVE-2020-26919: Netgear ProSAFE Plus Unauthenticated Remote Code Execution Vulnerability
Figure 6. Netgear ProSAFE exploit payload.
The exploit targets debug web sections and an attacker can execute system commands through it. This is due to lack of proper checks on access controls leading to RCE with administrator privileges.
The exploit of an unidentified vulnerability targets a command injection vulnerability in certain components. The component does not successfully sanitize the value of the HTTP parameter lang, which in turn leads to arbitrary command execution.
This exploit targets the op_type parameter, which is not properly sanitized leading to a command injection. It has been observed in the past being used by Moobot, however the exact target is unknown.
Malware Behaviors
Binary
Functionality
lolol.sh
After deleting some key folders from the target machine (such as ones containing the existing scheduled jobs, as well as startup scripts), this script downloads the “dark” binaries explained below, saves them to a misleadingly named file “nginx” and tries to run each one. Since the “dark” binaries downloaded are each compiled for a different architecture, only the one compatible with the target machine would actually execute.
Following that, it schedules a job that would (supposedly) run every hour to rerun the lolol.sh script. However, the cron configuration is incorrect. This would have been an attempt to ensure the process is re-launched in case it crashes or is killed for some other reason.
Finally, several packet filter rules are created to block incoming traffic directed at commonly used ports like the standard SSH, HTTP and telnet ports, among others. This is probably to make maintenance of and remote access to the affected system more challenging for an administrator.
In one of the two observed versions of the script, it also downloads and runs the “install.sh” script described below.
install.sh
This script downloads GoLang v1.9.4 onto the target system and adds it to the system path. In addition, it also installs the GoLang standard SSH package and zmap (a common network-scanning package).
It also downloads the “nbrute” binaries and the “combo.txt” file described below. As was the case for the previous script, the “nbrute” binaries downloaded are each compiled for a different architecture, increasing the probability of compatibility with the target machine.
Finally, zmap is run to scan port 22, and IPs found with port 22 open are sent as input to the nbrute binary.
nbrute.[arch]
These binaries are written in GoLang and mainly serve the purpose of brute-forcing the various credentials found in “combo.txt” while initiating an SSH connection with a certain IP.
combo.txt
Plain text file containing numerous combinations of credentials (often default credentials on devices).
dark.[arch]
These binaries are based on the Mirai codebase, and mainly serve the purpose of propagation – either using the exploits described in the section above, or by brute-forcing SSH connections using some hard-coded credentials in the binary.
The key used for the standard Mirai byte-wise XOR encryption routine is 0xbaadf00d.
Table 2. Malware behaviors.
Conclusion
The IoT realm remains an easily accessible target for attackers. Many vulnerabilities are very easy to exploit and could, in some cases, have catastrophic consequences. We strongly advise customers to apply patches whenever possible.
Palo Alto Networks customers are protected from the aforementioned vulnerabilities by the following products and services:
Next-Generation Firewalls with the Threat Prevention security subscription can block the attacks with best practices via threat prevention signatures 90776, 90553, 55228, 57842, 59191, 90302, 90808, 90824 and 90555.
WildFire can stop the malware with static signature detections.
Last week, Microsoft reported that attackers compromised Exchange Mail Servers with the use of four zero-day vulnerabilities. While patches have been released by Microsoft, adversaries are still attacking vulnerable versions of Microsoft Exchange Servers with malicious tools, malware and data exfiltration. Further, Microsoft has confirmed the existence of a ransomware variant leveraging these vulnerabilities, which has been dubbed “DearCry.” It is reasonable to suspect that the ransomware authors were paying homage to an unrelated yet infamous ransomware family, “WannaCry,” which was used as a payload within an orchestrated attack campaign leveraging known Microsoft vulnerabilities to infect victims en masse.
Due to the surge of this malicious activity, we’ve created this threat assessment for overall threat awareness. Full visualization of the techniques observed and their relevant Courses of Action (CoA) can be viewed in the Unit 42 ATOM Viewer.
If you think you may have been impacted, please email crypsis-investigations@paloaltonetworks.com or call (855) 875-4631 to get in touch with the Crypsis Incident Response team.
DearCry Ransomware Overview
DearCry is a new ransomware variant that has been observed exploiting Microsoft Exchange Servers’ ProxyLogon vulnerabilities for initial access. Early reports of the appearance of DearCry ransom notes in tandem with associated Microsoft Exchange Server compromises via ProxyLogon vulnerabilities began to surface on March 9, 2021, and victims in the U.S., Canada and Australia are suspected, according to security researcher Michael Gillespie.
When executed, DearCry ransomware uses AES-256 and RSA-2048 to encrypt victim files, while also modifying file headers to include the string ‘DEARCRY!’ (see Figure 1).
Figure 1. DearCry file header.
As with a majority of ransomware variants, DearCry deploys a ransom note to the victim’s desktop. However, instead of demanding a fixed ransom amount and including a Bitcoin wallet address, DearCry’s note includes two email addresses that the victim is asked to contact, as well as a request for a provided hash to be sent (see Figure 2).
Figure 2. DearCry ransom note.
During its execution, DearCry also runs a service named “msupdate” that is not native to the Windows operating system. This service is later removed when the ransomware finishes its encryption process. Furthermore, all logical drives on the Windows operating system, except for CD-ROM drives, are enumerated on the victim’s system so that the ransomware can begin to encrypt files using an RSA public key.
At the time of this writing, all attributed samples leverage the .CRYPT extension for infected files.
Figure 3. DearCry encrypted files.
Courses of Action
This section documents the relevant tactics, techniques and procedures ( TTPs) used by DearCry and maps them directly to Palo Alto Networks product(s) and service(s). It also further instructs customers how to ensure their devices are configured correctly.
Product / Service
Course of Action
Initial Access
Exploit Public-Facing Application [T1190]
NGFW
Ensure application security policies exist when allowing traffic from an untrusted zone to a more trusted zone
Ensure 'Service setting of ANY' in a security policy allowing traffic does not exist
Ensure 'Security Policy' denying any/all traffic to/from IP addresses on Trusted Threat Intelligence Sources Exists
Threat Prevention†
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
Ensure a secure Vulnerability Protection Profile is applied to all security rules allowing traffic
Deploy Content Pack 8380, which detects the four Microsoft Exchange zero-day vulnerabilities
WildFire†
Ensure that WildFire file size upload limits are maximized
Ensure forwarding is enabled for all applications and file types in WildFire file blocking profiles
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
Cortex XSOAR
Deploy XSOAR Playbook - Isolate Endpoint
Defense Evasion, Discovery, Impact
Disable or Modify Tools [T1562.001], File and Directory Discovery [T1083], Data Encrypted for Impact [T1486], Service Stop [T1489]
Cortex XDR
Enable Anti-Exploit Protection
Enable Anti-Malware Protection
Look for the following BIOCs alerts to detect activity*:
Table 1. Courses of Action for DearCry. †These capabilities are part of the NGFW security subscriptions service. * These analytic detectors will trigger automatically for Cortex XDR Pro customers.
Conclusion
DearCry is a new ransomware leveraging ProxyLogon vulnerabilities from Microsoft Exchange Servers. Furthermore, it is a perfect example of how threat actors can impact the threat landscape by taking advantage of newly disclosed vulnerabilities to make a quick profit. We strongly advise immediately updating all Microsoft Exchange Servers to the latest available patched versions released by Microsoft.
Palo Alto Networks customers are protected across our product ecosystem, with protections deployed in the following products and subscriptions:
It is imperative for customers to employ best practices in order to ensure Palo Alto Networks products are configured in a manner best suited for your protection.
Indicators associated with this Threat Assessment are available on GitHub, have been published to the Unit 42 TAXII feed and are viewable via the ATOM Viewer.
In addition to the above courses of action, AutoFocus customers can review additional activity by using the tag: DearCry.
Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit www.cyberthreatalliance.org.
On March 2, the world was introduced to four critical zero-day vulnerabilities impacting multiple versions of Microsoft Exchange Server (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858 and CVE-2021-27065). Alongside revealing these vulnerabilities, Microsoft published security updates and technical guidance that stressed the importance of patching immediately, while concurrently noting active and ongoing exploitation by an Advanced Persistent Threat (APT) they call HAFNIUM. Since the initial attacks, Unit 42 and a number of other threat intelligence teams have seen multiple threat groups now exploiting these zero-day vulnerabilities in the wild. Both the vulnerabilities themselves and the access that can be achieved by exploiting them are significant. It is therefore unsurprising that multiple attackers sought and continue to seek to compromise vulnerable systems before they are patched by network administrators. This has been going on at an unprecedented scale – as of March 8, based on telemetry collected from the Palo Alto Networks Expanse platform, we estimated there remained over 125,000 unpatched Exchange Servers in the world.
Based on the reconstructed timeline, it’s now clear that there were at least 58 days between the first known exploitation of this vulnerability on Jan. 3 and when Microsoft released the patch on March 2. Applying the patch is a necessary first step, but insufficient given the amount of time the exploit was in the wild. The act of patching will not remediate any access that attackers may have already gained to vulnerable systems. Organizations can look to our remediation guide for steps they can take to ensure they have properly secured their Exchange Servers.
As we enter the second week since the vulnerabilities became public, initial estimates place the number of compromised organizations in the tens of thousands, thereby dwarfing the impact of the recent SolarStorm supply chain attack in terms of victims and estimated remediation costs globally. Given the importance of this event, we are publishing a timeline of the attack based on our extensive research into the information currently available to us and our direct experience defending against these attacks. As the situation continues to unfold, we urge others to also share what they uncover so that we as a cybersecurity community get a complete picture as quickly as possible.
Microsoft Exchange Server Attack Timeline Summary
This story begins over six months ago when DevCore, a Taiwan-based security consulting firm, first initiated a project to explore the security of Microsoft Exchange Server products. In the two-month window between October and December 2020, DevCore researchers made considerable progress that ultimately led to the discovery of a pre-authentication proxy vulnerability on Dec. 10, 2020. This vulnerability was given the name ProxyLogon by DevCore and is now known publicly as CVE-2021-26855.
Following this initial discovery, on Dec. 27, 2020, DevCore researchers demonstrated that this vulnerability could be leveraged to perform authentication bypass, thereby granting its users administrator-level permissions on vulnerable Exchange Servers. Shortly after this discovery, on Dec. 30, 2020, DevCore also discovered a second post-authentication file write bug that could be chained together with the first vulnerability to gain privileged access to Exchange Servers and write files of an attacker’s choosing to any directory. This second vulnerability is now known publicly as CVE-2021-27065.
Given the time of year and the existence of a long New Year’s holiday weekend, DevCore reached out and notified Microsoft of the vulnerabilities on the following Tuesday (Jan. 5, 2021). At the time, the researcher credited with the discovery of the vulnerabilities tweeted publicly.
At that point, attacks were already appearing in the wild. Volexity, a US-based security firm, reported attacks involving the ProxyLogon vulnerability as early as Jan. 3. On Feb. 2, the firm also reported to Microsoft information about attacks that occurred on Jan. 6.
Concurrently, it is now believed that Dubex, a Denmark-based security firm, first noted active exploitation of the Microsoft Exchange UMWorkerProcess on Jan. 18, 2021. This vulnerability is now known as CVE-2021-26857. It was used by an adversary to install webshells on vulnerable servers consistent with the attacks noted by Volexity. It has been reported that Dubex notified Microsoft of its findings on Jan. 27, less than 10 days after initial discovery.
With two cybersecurity vendors providing evidence of active exploitation, DevCore followed up with Microsoft on Feb. 18, 2021. During the exchange, DevCore provided a draft advisory notice and requested details concerning the patch release timeline. At the time, Microsoft shared that they planned to release the patches on March 9.
On Feb. 27, 2021 Microsoft notified DevCore that they were almost ready to release the security patches. That same day, the cybersecurity community observed an uptick in unusual webshell activity, and over the following two days, evidence suggests multiple threat groups began active exploitation activities. ESET reported three separate groups (Tick, LuckyMouse and Calypso) and our own analysis of webshells deployed in this window has identified six unique passwords and clusters of activity that further support the claim of multiple threat groups. It is also worth noting that one of the passwords observed on Feb. 28, 2021 was the name “orange,” which may serve as a reference to the researcher who originally discovered the vulnerability.
On March 2, 2021, a week earlier than initially planned, Microsoft published security updates for the four vulnerabilities. In doing so, they also warned of active exploitation of these vulnerabilities by a group they named HAFNIUM and further described as a state-sponsored APT operating out of China.
In the days following the publication of the CVEs, the cybersecurity community has witnessed a surge of attacks as malicious actors seek to capitalize on the vulnerabilities before network defenders deploy patches. Over the past week, we have also identified the emergence of several new webshell passwords and clusters of activity that have overlapping victim populations. Thus, we currently assess that several additional threat actors with varying motives have launched efforts to exploit these vulnerabilities as well.
Finally, in terms of the timeline, it is important to consider that while the Microsoft security updates were released on March 2, 2021, applying these updates only protects organizations from continued or future exploitation of these vulnerabilities. The security updates do not provide any protection from previous exploitation that may have resulted in compromise prior to the publication of the updates.
As documented above, there is definitive evidence that these exploits were in active use as far back as early January, thus resulting in at least a two-month window of vulnerability. However, a lack of evidence of exploitation prior to January should not be misinterpreted as a lack of adversary activity.
Figure 1. High-level timeline of activity
Conclusion
Ongoing research illustrates that these vulnerabilities are being used by multiple threat groups. While it is not new for highly skilled attackers to leverage new vulnerabilities across varying product ecosystems, the ways in which these attacks are conducted to bypass authentication -- thereby providing unauthorized access to emails and enabling remote code execution (RCE) -- is particularly nefarious.
Unit 42 fully expects attacks leveraging these vulnerabilities to not only continue, but to increase in scope, likely including more varied attacks with different motivations, such as ransomware infection and/or distribution. Due to the fact that active attacks from various threat groups leveraging these vulnerabilities is ongoing, it’s imperative to not only patch affected systems, but also follow the guidance outlined from Unit 42’s previous remediation blog.
These vulnerabilities let adversaries access Exchange Servers and potentially gain long-term access to victims’ environments. While the Microsoft Threat Intelligence Center (MSTIC) attributes the initial campaign with high confidence to HAFNIUM, a group they assess to be state-sponsored and operating out of China, multiple threat intelligence teams, including MSTIC and Unit 42, are also seeing multiple threat actors now exploiting these zero-day vulnerabilities in the wild. Estimated number of potentially compromised organizations is in the tens of thousands globally – and very importantly, these vulnerabilities were being actively exploited for at least two months before the security patches were available. As a result, even if you patched immediately, your Exchange Servers could still be compromised. Further, based on telemetry collected from the Palo Alto Networks Expanse platform, we estimate there remain over 125,000 unpatched Exchange Servers in the world.
Below you will find a concise playbook that enterprises can follow to respond to this potential threat in their environments.
1) Locate all Exchange Servers and determine whether they need to be patched.
Exchange Online is not affected.
Vulnerable Exchange Server versions include 2013, 2016, and 2019. While Exchange 2010 is not vulnerable to the same attack chain as Exchange 2013/2016/2019, Microsoft has released a patch for CVE-2021-26857 for this version of the software. Microsoft has recently released additional guidance for older, unsupported versions of Exchange.
Microsoft is recommending to install updates on all Exchange Servers, prioritising those that are externally/internet facing. Even if Exchange Servers are not internet facing, the vulnerabilities can still be exploited if access to the network has been achieved through other methods.
Microsoft has published information about the updates for the following specific versions of Exchange Server:
Install the out-of-band security updates for your version of Exchange Server.
If you cannot update and/or patch an Exchange Server immediately, there are some mitigations and workarounds that may reduce the chances of an attacker exploiting an Exchange Server; these mitigations should only be temporary until patching can be completed. Palo Alto Networks Next-Generation Firewalls (NGFWs) updated to Threat Prevention Content Pack 8380 or later protect against these vulnerabilities if SSL decryption is enabled for inbound traffic to the Exchange Server. Cortex XDR running on your Exchange Server will detect and prevent webshell activity commonly used in these attacks.
The initial attack requires the ability to make an untrusted connection to Exchange Server port 443. You can protect against this by restricting access to the system from untrusted users. This can be achieved by only allowing access to the system from users who have already authenticated through a VPN, or by using a firewall to limit access to specific hosts or IP ranges. Using this mitigation will only protect against the initial portion of the attack. Other portions of the chain can still be triggered if an attacker already has access to the network or can convince an administrator to open a malicious file.
More information about using Palo Alto Networks products, including firewalls with security subscriptions, Cortex XSOAR for automation and Cortex XDR for endpoint protection, can be found in our Threat Assessment.
3) Determine whether an Exchange Server has already been compromised.
These vulnerabilities have been in the wild and actively exploited for over a month, with the earliest indications of exploitation leading back to Jan. 3. Any organization running the vulnerable software must evaluate if their server has been compromised. Patching the system will not remove any malware already deployed on the system. It would be prudent to assume Exchange Servers that exposed Outlook Web Access or Exchange Web Services to the internet are compromised until proven otherwise.
Check for suspicious process and system behavior, especially in the context of Internet Information Service (IIS) and Exchange application processes, such as PowerShell, Command shells (cmd.exe) and other programs executed in the applications’ address space. We describe how to use Palo Alto Networks Cortex XDR Pro endpoint protection to hunt for this attack in your environment in “Hunting for the Recent Attacks Targeting Microsoft Exchange.”
Microsoft has released PowerShell and Nmap scripts for checking your Exchange Server for indicators of compromise of these exploits. They have also released another script, available at the same link, that highlights differences in files from the virtual directories of your Exchange Server against those expected for your specific Exchange version. The Cybersecurity and Infrastructure Security Agency (CISA) has also published a list of tactics, techniques and procedures (TTPs).
As documented in the Unit 42 Threat Assessment Courses of Action table, the post-intrusion TTPs used by the initial actors conducting the Exchange attacks included the following:
Using Procdump to dump the LSASS process memory.
Using 7-Zip to compress stolen data into ZIP files for exfiltration.
Adding and using Exchange PowerShell snap-ins to export mailbox data.
Using the Nishang Invoke-PowerShellTcpOneLine reverse shell.
Downloading PowerCat from GitHub, then using it to open a connection to a remote server.
Since the initial attacks, we believe that other actors are trying to capitalize on the Exchange vulnerabilities, but their motivations and objectives may differ vastly, and so could their TTPs.
4) Engage an Incident Response team if you think you have been compromised.
If, at any point, you think your Exchange Server has been compromised, you should still take action to secure it against the vulnerabilities as described above. This will prevent additional adversaries from further compromising the system. Installing the out-of-band security updates for your version of Exchange Server is very important, but this will not remove any malware already installed on systems and will not evict any threat actors present in the network.
The potential impact of this situation is critical due to the ongoing activity described, the vulnerabilities exploited to deliver the attack and the adversaries who could be behind compromises. While exploits of these vulnerabilities may not halt business operations, access to sensitive information and systems is certainly possible, and should be assumed to have occurred. Access to corporate emails could also lead to followup phishing attacks.
If you believe you have been compromised, you should enact your incident response plan. If you need such services, our Palo Alto Networks Crypsis incident response team is available to help: crypsis-investigations@paloaltonetworks.com.
![The gating website took us to another website (track[.]backtoblack.xyz), which was a redirector itself. Eventually, we were routed to zoomhookups[.]com through a GET request with some parameters filled such as click_id, which can be used for monetization as shown in Figure 5.](https://unit42.paloaltonetworks.com/wp-content/uploads/2021/04/word-image-4.png)
![pharmalicensing[.]com, a website belonging to a company that helps connect businesses across the life sciences industry, had been compromised and used to host a phishing page for stealing users’ business credentials.](https://unit42.paloaltonetworks.com/wp-content/uploads/2021/03/word-image-118.png)
Get updates from Unit 42 