Many traditional phishing detection systems rely on the presence of login forms within the HTML of the webpage to classify pages as phishing. Client-side cloaking is an increasingly common technique that attackers use to evade phishing detection systems by requiring complex user interaction before revealing the webpage’s phishing content, or by using JavaScript to inject phishing content into the page only after the page renders in the user’s browser.
To combat these evasion techniques, we trained a deep learning model to detect phishing webpages based on the JavaScript content contained within the script tags of an HTML page. The model, dubbed PhishingJS, runs in the Palo Alto Networks cloud-delivered Advanced URL Filtering service. It currently detects an additional 15,000 phishing URLs per week on sophisticated JavaScript-based attacks that many existing phishing detection systems struggle to detect.
Palo Alto Networks customers with the Next-Generation Firewall and the Advanced URL Filtering security subscription are protected against the sophisticated types of phishing attacks discussed here.
Client-Side Cloaking
Many existing phishing detection systems rely on the presence of login forms, brand logos and similar signals within the HTML of a webpage to determine whether the page is a phishing page.
Client-side cloaking is an increasingly common evasion technique used by cybercriminals to evade these phishing detection systems. These attackers often use JavaScript to dynamically render phishing content (the same types of content often picked up by detection systems) on the client side, sometimes requiring user interaction before revealing any signs of attempted credential theft. Since the phishing content does not appear in the HTML document until after the page renders, these phishing pages can be difficult for traditional phishing detection engines to catch.
In Figures 1-2, we can see an example of a phishing webpage employing client-side cloaking techniques. This page claims that there has been some unusual activity on the user’s Apple ID account and that the user needs to process a refund related to the activity.
Upon first visiting the webpage, there is no phishing form immediately apparent. Only after the user clicks the “Confirm Refund Request” button is the credential-stealing form revealed. Since many crawler-based phishing detection systems cannot handle these sorts of interactions, these types of phishing pages can often pass undetected.
Figure 1. https://appleid[.]uber[.]space/LoginFailed.php?sslchannel=true&sessionid=VRqELCgYcqDhDQ2KGKMPYt4FcEX0XO7Kz1wi2xZyCCQiA5fz9smSqmoWfnsEn9znu4ixcl3RkVzwRW5f. A phishing page employing client-side cloaking techniques.Figure 2. Same URL as Figure 1, with the credential-stealing form revealed after clicking “Confirm Refund Request.”
After investigating the source code behind the page, we see that most of the page content does not exist directly within the main body of the HTML. Rather, there is a large script tag at the bottom of the HTML source that uses the document.write(...) API to inject the bulk of the page content into the HTML document; this happens only after the page is rendered in the browser.
Note that this script is also highly obfuscated, likely in an attempt to avoid phishing detection engines. The obfuscated code runs through AES decryption before being passed into the document.write(...) call.
Figure 3. HTML source code for the page in Figures 1-2.
Sophisticated phishing pages like these may pose problems to traditional phishing detection engines. Therefore, we need to investigate additional machine learning (ML) techniques to classify pages like these as phishing.
How We Trained Our Model to Detect JavaScript-Based Phishing
We first created a training data collection pipeline to continuously gather phishing JavaScript samples from recent phishing URLs. We collected these samples from phishing URLs discovered from third-party sources and our phishing detection systems.
Once enough samples were collected, we trained a deep learning model on ~120,000 phishing and ~300,000 benign JavaScript samples. We validated the model in a staging environment before promoting it to production.
Traditional ML relies on subject matter experts to design a set of handcrafted features for the model to use as indicators of phishing or benign activity. On the other hand, our deep learning model iterates through the dataset to learn what patterns in the JavaScript code may indicate phishing (or otherwise suspicious) behavior. This ML-based pattern-matching makes the model more flexible than purely signature-based detection techniques, and also more robust to newer or lesser-known JavaScript-based phishing tactics that some researchers may not have seen before.
For each script tag, the model produces a score from 0 to 1, where 1 indicates high confidence in the script being related to some sort of phishing behavior, and 0 indicates high confidence in the script being benign. For example, highly obfuscated JavaScript code, or code that injects credential-stealing forms into the page, may cause the model to output a high phishing score. Benign JavaScript code will pass through the model without raising any red flags.
Once we have a phishing score from the model, we apply various thresholds to make our final verdict regarding whether to publish the given URL as phishing or not. The PhishingJS model contributes roughly 15,000 new phishing detections weekly, meaning that Palo Alto Networks customers – specifically those who subscribe to Advanced URL Filtering – will be protected from these sophisticated phishing attacks in the real world.
PhishingJS in the Real World
Here are some sample detections that our model has generated.
First, we can see that the model can detect phishing pages employing client-side cloaking, such as when the page requires the user to click a button before actually revealing the credential-stealing form. In Figures 4-5, we see an example of a phishing webpage impersonating a Dropbox login page. The user must first click a “Sign in with Gmail” or “Sign in with Outlook” button before being presented with a modal asking for their login information. This particular URL was detected as phishing with a score of 0.99998, meaning that the model was very confident in marking this page as phishing.
Figure 4. cooking4kor[.]ru/cvfd/?onstoreid=40uti89763. A phishing page employing client-side cloaking that our PhishingJS model detected.Figure 5. cooking4kor[.]ru/cvfd/?onstoreid=40uti89763. After user interaction.Next, we show that the model can also detect highly obfuscated JavaScript code responsible for generating phishing webpages. In Figure 6, we present a phishing webpage that is attempting to impersonate a SharePoint login site. This may look like a relatively straightforward phishing page upon first glance. However, upon inspecting the page’s source code, we see that the entire page is generated using a single JavaScript script tag. Similar to the example in Figure 3, this JavaScript snippet takes a highly obfuscated string, decodes it and then calls document.write(...) to inject the output into the webpage.
Figure 6. https://555305[.]selcdn[.]ru/564377/kc.htm#. A phishing webpage that uses JavaScript to dynamically render the content of the page.Since the HTML of the page lacks any immediately apparent body text or input forms, this page might evade many traditional phishing detection engines. However, by analyzing the JavaScript snippet itself, our PhishingJS model detected this model as phishing with a high-confidence score of 1.00000.
Figure 7. HTML source code for the phishing page in Figure 6.
We find that the model is capable of detecting highly interactive scam pages as well. In Figures 8-10, we show a scam page claiming that the user has won a free Samsung Galaxy S2; all the user needs to do to claim the prize is share the page with five groups or 20 friends on WhatsApp.
Figure 8. http://coffeeshop[.]store/janjijiwa?t=1621831119257. A highly interactive scam page that was detected by our PhishingJS model.Each time the user clicks the “Share” button, the page opens the user’s WhatsApp app and asks the user to share the page with another WhatsApp number. After each time the page is “shared,” the blue bar is incremented farther toward the right.
Figure 9. Same URL as Figure 8, after clicking the “Share” button.
Once the user has shared the page with the requisite number of friends, the user is prompted to complete the final registration step. Presumably, after clicking “Complete registration,” the user will be shown a form asking for some sensitive information so that the scammers can “ship the free phone” (which, to be clear, does not exist) to the user.
Figure 10. Same URL as Figure 8. After sharing the page with enough WhatsApp users, the user is prompted to “Complete registration.”
As seen in the figures above, this scam page requires very complex user interactions before explicitly revealing any credential-stealing forms. By analyzing the JavaScript of the page and using deep learning to look for suspicious patterns that may be indicative of phishing or credential-stealing activity, we can detect these pages as phishing and prevent our customers from falling prey to these sorts of attacks in the real world.
Conclusion
Traditional phishing detection engines can often struggle to detect the increasingly sophisticated phishing webpages that cybercriminals are now crafting. Specifically, they are often unable to detect instances of client-side cloaking, wherein the phishing page may require some user interaction before revealing the actual phishing content, or wait until the page is rendered in the browser before injecting phishing content into the HTML document.
By training a deep learning model to directly analyze the JavaScript contained within the webpage, we can catch these sophisticated JavaScript-based phishing attacks and prevent them from reaching our customers.
The Palo Alto Networks ML-powered Advanced URL Filtering service for the Next-Generation Firewall, which now has this JavaScript-based phishing detection capability, can help protect against these attacks.
The author would like to thank Wei Wang for helping to guide the PhishingJS project from start to finish; Wayne Xin and Jingwei Fan for helping to get the model into production; Brody Kutt for the original model architecture; and Seokkyung Chung, Yu Zhang, Zeyu You and Ziqi Dong for helping to review the model detections.
Azure Container Instances (ACI) is Azure's Container-as-a-Service (CaaS) offering, enabling customers to run containers on Azure without managing the underlying servers. Unit 42 researchers recently identified and disclosed critical security issues in ACI to Microsoft. A malicious Azure user could have exploited these issues to execute code on other users' containers, steal customer secrets and images deployed to the platform, and possibly abuse ACI's infrastructure for cryptomining. Researchers named the vulnerability Azurescape – the first cross-account container takeover in the public cloud.
Azurescape allowed malicious users to compromise the multitenant Kubernetes clusters hosting ACI, establishing full control over other users' containers. This post covers the research process, presents an analysis of the issue and suggests best practices for securing Kubernetes, with a focus on multitenancy, that could help prevent similar attacks.
Microsoft patched ACI shortly after our disclosure. Unit 42 has no knowledge of Azurescape exploited in the wild. As a precautionary measure, if you run containers on ACI, we recommend revoking any privileged credentials that were deployed to the platform before Aug. 31, 2021, and checking their access logs for irregularities.
Azure Container Instances (ACI) was released in July 2017 and was the first Container-as-a-Service (CaaS) offering by a major cloud provider. With ACI, customers can deploy containers to Azure without managing the underlying infrastructure. ACI takes care of scaling, request routing and scheduling, providing a serverless experience for containers.
Azure’s website described ACI by saying, "Develop apps fast without managing virtual machines or having to learn new tools – it's just your application, in a container, running in the cloud."
Internally, ACI is built on multitenant clusters that host customer containers. Originally those were Kubernetes clusters, but over the past year, Microsoft started hosting ACI on Service Fabric Clusters as well. The issues presented here affect ACI on Kubernetes, and the rest of the post will only reference that architecture. According to our tests, in which we deployed several thousand containers to the platform, at the time of disclosure Kubernetes hosted around 37% of newly created containers in ACI.
Figure 1. ACI hosted on multitenant Kubernetes clusters.
In multitenant environments like ACI, you need to enforce a strong boundary between tenants. In ACI, that boundary is the node virtual machine. Each customer container runs in a Kubernetes pod on a dedicated, single-tenant node. This Kubernetes multitenancy approach is often called node-per-tenant.
Azurescape Attack Scenario
ACI is built to defend against malicious neighbors. Since practically anyone can deploy a container to the platform, ACI must ensure that malicious containers cannot disrupt, leak information, execute code or otherwise affect other customers' containers. These are often called cross-account or cross-tenant attacks.
Figure 2. Cross-account attack scenario.
The following sections cover our research into cross-account attacks in ACI. We identified a cross-tenant attack through which a malicious Azure customer could escape their container, acquire a privileged Kubernetes service account token and take over the Kubernetes api-server, thus establishing complete control over the multitenant cluster and all customer containers running within it.
Escaping Our Container
CaaS offerings are notoriously hard to look into. Users are only exposed to their container environment, and access to the local network is disabled through firewalls. To better understand how CaaS platforms run our containers, we created WhoC. WhoC is a container image that reads the container runtime executing it. It's based on a rarely discussed design flaw in Linux containers allowing them to read the underlying host's container runtime. The idea is quite similar to the infamousCVE-2019-5736, except that instead of overwriting the host's runtime, you read it.
By deploying WhoC to ACI, we were able to retrieve the container runtime used in the platform. Unsurprisingly, we found runC, the industry standard container runtime. What caught us off guard was the version, as shown in Figure 3.
Figure 3. Container runtime used in ACI.
RunC v1.0.0-rc2 was released on Oct. 1, 2016, and was vulnerable to at least two container breakout CVEs. Back in 2019, we analyzed one of these vulnerabilities, CVE-2019-5736. Our blog post, “Breaking out of Docker via runC – Explaining CVE-2019-5736,” shared our analysis and a proof-of-concept (PoC) exploit for it.
Once we discovered the presence of this old version of runC in ACI, we took the PoC container image developed then, polished it and deployed it to ACI. We successfully broke out of our container and gained a reverse shell running as root on the underlying host, which turned out to be a Kubernetes node.
Figure 4. Exploiting CVE-2019-5736 to escape our ACI container.
While we escaped our container, we were still within the tenant boundary – the node VM. CaaS platforms are designed to withstand sophisticated attackers who possess kernel vulnerabilities enabling privilege escalation and container breakout. A malicious container breaking out is a somewhat expected threat, tolerated through node-level isolation.
Figure 5. Out of the container, still inside our dedicated node.
Scouting the Node Environment
Looking around the node, we could verify our container was the only customer container. Using the Kubelet credentials, we listed the pods and nodes in the cluster. The cluster hosted around 100 customer pods and had about 120 nodes. Each customer was assigned a Kubernetes namespace where their pod ran; ours was caas-d98056cf86924d0fad1159XXXXXXXXXX.
We saw that the node's Kubelet allowed anonymous access, so we tried to access Kubelets on neighboring nodes. All attempted requests to access neighboring nodes timed out, probably due to a firewall configuration that prevented communication between worker nodes.
Nodes had a reference to the cluster name in a kubernetes.azure.com/cluster label, with the following format: CAAS-PROD-<LOCATION>-LINUX-<ID>.
Figure 6. Cluster name.
We deployed a few breakout containers which landed on different Kubernetes clusters. Each cluster was found to have a unique cluster ID ranging between 1-125, indicating that each location (e.g. Western Europe) hosted a few dozen clusters.
Kubernetes 1-days
Next, we examined the cluster's Kubernetes version.
Figure 7. ACI Kubernetes version.
ACI was hosted on clusters running either Kubernetes v1.8.4, v1.9.10 or v1.10.9. These versions were released between November 2017 and October 2018 and are vulnerable to multiple publicly known vulnerabilities. Running older Kubernetes versions is considered bad practice, but it doesn't necessarily entail a security issue within ACI. If no past issues are exploitable from the context of a malicious node, then there's no security impact.
We started going over past Kubernetes issues, searching for ones that would allow our compromised node to escalate privileges or gain access to other nodes. We identified one that looked promising – CVE-2018-1002102.
Kubernetes CVE-2018-1002102
The api-server occasionally reaches out to Kubelets. For example, when servicing a kubectl exec <pod> <cmd> command, the api-server will defer the request to the appropriate Kubelet's /exec endpoint.
CVE-2018-1002102 marks a security issue in how the api-server communicated with Kubelets – it would accept redirects. By redirecting the api-server's requests to another node's Kubelet, a malicious Kubelet can spread in the cluster. Figure 8 shows the basic flow of the vulnerability:
Figure 8. CVE-2018-1002102 flow.
The prerequisites for exploitation are:
A vulnerable api-server version: ✓
A compromised node: ✓
A way to make the api-server contact the compromised node. For example, this can be accomplished by issuing a kubectl exec to a pod on the compromised node: ?
As it turns out, ACI also fulfilled the third prerequisite. ACI supports executing commands on uploaded containers via the az container execcommand, which mirrors kubectl exec.
az container exec --name <my-container> --exec-command <command>
We proceeded to create a custom Kubelet image that exploits CVE-2018-1002102, redirecting incoming exec requests to pods on other nodes. To maximize impact, we configured it to target the api-server pod, and finally, ran az container exec my-ctr --exec-command /bin/bash, with the expectation of establishing a shell on the api-server container. The command just failed.
After some debugging, we noticed the redirection operation only works if the target container is hosted on the same node. This effectively nullifies the attack, since we can't spread to other nodes. Examining the patch for CVE-2018-1002102, this was actually the fix for the vulnerability. At this point, something didn't add up. We had already verified the api-server version was vulnerable to CVE-2018-1002102, and we didn't understand why it appeared to include the fix.
Reexamining the exec requests arriving at the node helped shed some light on what was going on. We expected the requests to arrive from the api-server IP, as illustrated in Figure 8. Surprisingly, the requests originated from a pod dubbed the 'bridge' running in the default namespace.
Figure 9. Kubelet connections during an az container exec session.
We discovered that ACI moved the handling of exec requests from the api-server to a custom service. This was probably implemented by routing az container exec commands to the bridge pod instead of to the api-server.
Figure 10. Bridge pods handle execs in ACI.
The bridge image tag was master_20201125.1, indicating it was updated after CVE-2018-1002102. Judging from its recent build time and its refusal to redirect exec requests, it appears that CVE-2018-1002102's patch was ported to the bridge. Microsoft deserves credit for noticing a vulnerability affects their custom bridge pod and patching accordingly. Nicely done!
It's worth mentioning that CVE-2018-1002102 can also be exploited in other cases, for instance, when a client asks a malicious Kubelet to retrieve container logs (e.g. kubectl logs). This is actually relevant for ACI, where this functionality is implemented via the az container logscommand. But as with exec requests, ACI deferred the handling of log retrieval to a dedicated pod appropriately named log-fetch. And as with the bridge pod, a fix for CVE-2018-1002102 was also ported to the log-fetch pod, preventing exploitation.
Escalating to Cluster Admin
CVE-2018-1002102 was off the table, but we did notice something odd while debugging the exploit. The exec requests arriving at the node included an Authorization header carrying a Kubernetes service account token, as shown in Figure 11.
Figure 11. Bridge sends 'exec' request with service account token.
Finding a token here was surprising. As mentioned earlier, Kubelets in the cluster were configured to allow anonymous access, so there was no need for requests to authenticate via a token. Perhaps this was a relic of an older implementation.
Kubernetes service account tokens are unencrypted JSON Web Tokens (JWTs), so they're decodable. As seen below, the received token is a service account token for the 'bridge' service account. This makes sense given the request originated from the bridge pod.
Figure 12. Bridge service account token, decoded.
If you run Kubernetes, be careful to whom you send your service account tokens: Anyone who receives a token is free to use it and masquerade as its owner. Token thieves are likely to be very interested in the permissions of their stolen tokens. The api-server exposes two APIs that allow clients to query for their permissions, SelfSubjectAccessReview and SelfSubjectRulesReview. And kubectl provides kubectl auth can-i as a convenient way of accessing these APIs.
Here are the privileges of the 'bridge' token in the default namespace:
Looking at other namespaces, the permissions are consistent, indicating they're cluster-wide (as opposed to namespace-scoped). Below are the token's permissions in the kube-system namespace. Try to identify a permission that would allow us to spread in the multitenant cluster:
Seasoned Kubernetes security folks may have identified the pods/exec privilege, indicating that the token can be used to execute commands on any pod in the cluster – including the api-server pod! Figure 15 shows the token opening a shell on the api-server container:
Figure 15. Using the bridge's token to pop a shell on the api-server.
We just completed a dangerous cross-account attack. With code execution on the api-server, we're now cluster admins with full control over the multitenant cluster and all customer containers within it.
Azurescape Attack Summary
Let's summarize the steps through which a malicious Azure customer could have gained administrative privileges over multitenant Kubernetes clusters hosting ACI:
Deploy an image exploiting CVE-2019-5736 to ACI. The malicious image breaks out upon execution and establishes code execution on the underlying node.
On the node, monitor traffic on the Kubelet port, port 10250, and wait for a request that includes a JWT token in the Authorization header.
Issue az container exec to run a command on the uploaded container. The bridge pod will now send an exec request to the Kubelet on the compromised node.
On the node, extract the bridge token from the request's Authorization header and use it to pop a shell on the api-server.
The attack is demonstrated in the following video:
Video 1: From malicious container to full cluster admin.
Impact of the Attack
A malicious Azure user could have compromised the multitenant Kubernetes clusters hosting ACI. As cluster administrator, an attacker could execute commands in other customer containers, exfiltrate secrets and private images deployed to the platform, or deploy cryptominers. A sophisticated adversary would further investigate the detection mechanisms protecting ACI to try to avoid getting caught.
The Fix
We responsibly disclosed all the above findings to Microsoft. Consequently Microsoft released a patch to ACI. The bridge pod no longer sends its service account token to nodes when issuing exec requests, preventing the reported cross-tenant attack.
Another Route to Admin – Bridge SSRF
After reporting the token issue, we wanted to make sure there aren't other ways to escalate to cluster admin. After extensive research, we were able to identify such a way. At this point Microsoft reduced the share of ACI containers running on Kubernetes; only around 10% of regions defaulted to Kubernetes clusters. That being said, some features were only supported on Kubernetes, for example gitRepo volumes. If an ACI container used such features, it was deployed on a Kubernetes cluster. Other features meant containers were likely to land on Kubernetes. That was the case for containers in private virtual networks.
The second issue we discovered was a server-side request forgery (SSRF) vulnerability in the bridge pod.
When a bridge pod services an az container exec <ctr> <cmd> command, it sends a request to the appropriate Kubelet's /exec endpoint. The bridge constructs the request according to the API specification of the Kubelet's /exec endpoint, resulting in the following URL:
The bridge must somehow fill in the missing parameters enclosed in <>. As it turns out, the value of <nodeIP> is retrieved from the customer pod's status.hostIP field. That was quite interesting to discover, since nodes are authorized to update the status of their pods (in order, for example, to update their pod's status.state field to Running, Terminated, etc).
We tried changing our pod's status.hostIP field using the compromised node's credentials. It worked, but after a second or two the api-server corrected the hostIP field to its original value. Although the change didn't persist, nothing prevented us from repeatedly updating this field.
We wrote a small script that repeatedly updates our pods' status, and used it to set the status.hostIP field to 1.1.1.1. We then issued an az container exec command. The command failed, verifying the bridge sent the exec request to 1.1.1.1 instead of the real node IP. We started thinking about which specially crafted hostIP could trick the bridge into executing a command on other pods.
Simply setting the pod's status.hostIP to another node's IP wouldn’t have achieved anything. Kubelets only accept requests that point to a container they host. Even if the bridge sends the exec request to another Kubelet's IP, the URL will still point to our namespace, pod name and container name.
We then realized the api-server doesn't actually verify that the status.hostIP value is a valid IP, and would accept any string – including URL components. After a few attempts, we came up with a hostIP value that would trick the bridge into executing a command on the api-server container, instead of our container:
The # suffix ensures the rest of the URL is treated as a URI fragment and is effectively ignored. We set our pod's status.hostIP to this value and issued a command via az container exec. The attack worked! Instead of a shell to our container, we were presented with a shell to the api-server container. The full attack can be seen in the following video:
Video 2: Tricking the bridge into opening a shell on the api-server.
The impact here is exactly the same as with the previous attack – full administrative control over the multitenant cluster. We reported this issue to MSRC as well, resulting in a patch to ACI. The bridge now verifies that a pod's status.hostIP field is a valid IP before sending an exec request.
Conclusion
Cross-account vulnerabilities are often described as a "nightmare" scenario for the public cloud. Azurescape is evidence that they're more real than we'd like to think. Cloud providers invest heavily in securing their platforms, but it's inevitable that unknown zero-day vulnerabilities would exist and put customers at risk. Cloud users should take a defense-in-depth approach to cloud security to ensure breaches are contained and detected, whether the threat is from the outside or from the platform itself.
As part of the commitment of Palo Alto Networks to advancing public cloud security, we actively invest in public cloud research that includes advanced threat modeling and vulnerability testing of cloud platforms and related technologies. We hope such research can illustrate how cross-account attacks may look in the wild, which can translate into suitable mitigations and detection mechanisms.
We'd like to thank Microsoft’s MSRC for quickly patching the reported issues and professionally handling the disclosure process, as well as for the bounty rewards. Cooperative penetration testing and bug bounty programs help secure the cloud services we all rely on.
Preventing Similar Attacks on Kubernetes Environments
From the perspective of a Kubernetes defender, several best practices, mitigations and policies can help prevent or detect features of similar attacks:
Keep your cluster infrastructure up to date and prioritize patches by severity and context.
Refrain from sending privileged service accounts tokens to anyone but the api-server. If a recipient is compromised, an attacker can masquerade as the token owner.
Enable BoundServiceAccountTokenVolume. This recently graduated feature gate ensures token expiration is bound to its pod. When a pod terminates, its token is no longer valid, minimizing the impact of token theft.
Deploy policy enforcers to monitor and prevent suspicious activity in your clusters. Configure them to alert on service accounts or nodes that query the SelfSubjectAccessReview or SelfSubjectRulesReview APIs for their permissions. Prisma Cloud customers can download a relevant rule template and enforce it via the built-in admission control for Kubernetes. We recommend setting the rule to Alert. Others can rely on open-source tools such as OPA Gatekeeper.
To expand on the last point, we see adversaries actively abusing the SelfSubjectReview APIs to inspect the privileges of stolen Kubernetes credentials. Daniel Prizmant, a fellow researcher, recently observed the Siloscape malware leveraging these APIs to retrieve the permissions of the node it compromised, and then using them to determine whether to continue its campaign against the cluster. We reported this behaviour to MITRE, and it will be included in the next release of ATT&CK for Containers as the Permission Group Discovery technique.
Secure multitenancy in Kubernetes is challenging, even for cloud providers. Hosting services, cloud providers and CI/CD services implementing multitenancy on Kubernetes should consider the following when designing their platforms:
Refrain from exposing cluster credentials within the tenant boundary. Malicious tenants may abuse these credentials to fuel further escalation or collect information on other tenants and the platform itself.
Assume a malicious tenant will break out of its container/sandbox. Think from an attacker's perspective – What could be the objectives? What would be the first moves? Implement detection mechanisms accordingly. Detection schemes should be considered a requirement in hostile multitenant environments, necessary to combat advanced persistent threats (APTs) and zero-day vulnerabilities.
Even if a node is compromised, it shouldn't be able to move laterally and compromise other nodes. Ensure nodes are least privileged by enabling the NodeRestiction admission controller. Set up firewall rules to prevent communication between nodes hosting customer containers.
On Aug. 25, 2021, Atlassian released a security advisory for an injection vulnerability in Confluence Server and Data Center, CVE-2021-26084. If the vulnerability is exploited, threat actors could bypass authentication and run arbitrary code on unpatched systems. Since the release of this advisory, mass scanning activity has started to occur, seeking unpatched systems, and in-the-wild exploitation has begun. Unit 42 recommends customers upgrade to the latest release of Confluence Server and Data Center.
Vulnerable Systems
The Atlassian products vulnerable to CVE-2021-26084 are those using the following versions of Confluence Server and Data Center:
All 4.x.x versions.
All 5.x.x versions.
All 6.0.x versions.
All 6.1.x versions.
All 6.2.x versions.
All 6.3.x versions.
All 6.4.x versions.
All 6.5.x versions.
All 6.6.x versions.
All 6.7.x versions.
All 6.8.x versions.
All 6.9.x versions.
All 6.10.x versions.
All 6.11.x versions.
All 6.12.x versions.
All 6.13.x versions before 6.13.23.
All 6.14.x versions.
All 6.15.x versions.
All 7.0.x versions.
All 7.1.x versions.
All 7.2.x versions.
All 7.3.x versions.
All 7.4.x versions before 7.4.11.
All 7.5.x versions.
All 7.6.x versions.
All 7.7.x versions.
All 7.8.x versions.
All 7.9.x versions.
All 7.10.x versions.
All 7.11.x versions before 7.11.6.
All 7.12.x versions before 7.12.5.
Confluence Cloud customers are not affected by this vulnerability.
Mitigation Actions
We recommend that customers update Atlassian Confluence Server and Data Center to the latest version, 7.13.0 (TLS). You can find the newest release on Atlassian’s download center.
If you cannot install the latest upgrade, see the Mitigation section on the Atlassian security advisory for information on how to mitigate this vulnerability by running a script for the operating system your Confluence server is hosted on.
Conclusion
Palo Alto Networks provides protection against the exploitation of this vulnerability:
Next-Generation Firewalls with a Threat Prevention security subscription (running Applications and Threat content update version 8453) can automatically block sessions related to this vulnerability using Threat ID 91594.
Palo Alto Networks will update this Threat Brief with new information and recommendations as they become available.
Machine learning in security has a major challenge – it can't make mistakes. A mistake in one direction can lead to a risky slip of malware falling through the cracks. A mistake in the other direction causes your security solution to block good traffic, which is exorbitantly expensive for cybersecurity companies and a massive headache for consumers. In general, the amount of good (benign) traffic vastly outnumbers the amount of malicious traffic. Thus, minimizing errors on good traffic (called false positives) is key to building a good solution that makes few mistakes. Malware authors understand this and try to disguise their malicious code to look more like benign code. The most straightforward way to accomplish this is what’s known as an "append" attack (also known as an injection or bundling), wherein an attacker takes a (typically large) amount of benign content and injects malicious content into it. Since machine learning classifiers built with standard techniques are sensitive to their presence, the benign content added by benign append attacks can perturb a classification away from a positive malware verdict, sometimes causing the classifier to miss it entirely.
Our study, “Innocent Until Proven Guilty (IUPG): Building Deep Learning Models with Embedded Robustness to Out-Of-Distribution Content,” which we presented at the 4th Deep Learning and Security Workshop (co-located with the 42nd IEEE Symposium on Security and Privacy), proposes a generic prototype-based learning framework for neural network classifiers designed to increase robustness to noise and out-of-distribution (OOD) content within inputs. In other words, that study addresses a broader issue than the problems of machine-learning classifiers aiming to identify malware. However, the original motivation to create the Innocent Until Proven Guilty (IUPG) learning framework was to overcome append attacks on malware classifiers. Here, we illustrate IUPG by placing it firmly in the context of how it can be used to identify malware.
In the following sections, we provide more detail about benign append attacks and how they can be successful against even highly accurate classifiers, and how IUPG specifically addresses the issue. We provide the results of our experiments with IUPG and how it fits in with existing work. We close with examples of how Palo Alto Networks uses IUPG-trained models to proactively detect malicious websites, and, in particular, JavaScript malware on web pages.
Palo Alto Networks Next-Generation Firewall customers who use Advanced URL Filtering, DNS Security, and WildFire security subscriptions are better protected against benign append attacks through the use of IUPG.
What Is a Benign Append Attack?
Classification is an essential task in both machine learning and human intelligence. The idea is to correctly classify data points into a predefined set of possible classes. Malware classification is one common classification problem in which each input sample must be classified as either benign or malicious. A pervasive and largely unsolved problem in the space of deep learning-based malware classification is the tendency of classifiers to flip their verdict when malicious content is concatenated with benign content or even random noise. Content may be appended, prepended or injected somewhere in the middle, but the attack type is most often presented in the case of appends. Each of the three possibilities presents a similar challenge for a classifier. Thus, we treat them the same.
Figure 1. Visual explanation of a benign append attack. “M” refers to malicious and “B” refers to benign.
This attack type is often seen in the real world in the form of benign library injections. In that case, malicious code is injected into a large benign file. Again, the challenge for a malware classifier remains the same: It must pick out the “needle in the haystack” of malicious code while properly ignoring benign content despite its relative volume. Classifiers that are built to recognize and use features that correspond to the benign class as depicted in the training set will struggle with this task.
Our results suggest this attack is significantly successful against even highly accurate classifiers. Our deep learning JavaScript malware classifiers, built with categorical cross-entropy (CCE) loss, achieve well over 99% accuracy on our test set. Despite this, it took just 10,000 characters of random benign content appended onto malicious samples to successfully flip the verdict >50% of the time. This is particularly concerning given the extremely low cost of leveraging the attack. The adversary does not need to know any details about the victim classifier. At the same time, benign content is extremely plentiful and trivial to produce. If the adversary has access to sensitive information about the victim model, such as its loss function, the appended content can be designed with model-specific techniques, which generally increase the success rate further.
How Is Deep Learning Supposed to Overcome This?
In theory, to solve this problem perfectly, all content that is not directly indicative of malware must have a small enough impact on a classification mechanism such that a verdict will never be flipped to benign. At a high level, the approach we take is to encourage a network to exclusively learn and recognize uniquely identifiable patterns of the malicious class while being explicitly robust to all other content. An important observation is that malware patterns are highly structured and uniquely recognizable compared to the limitless possible benign patterns you can encounter in data (illustrated in Figure 2).
Figure 2. A visual argument explaining malicious versus benign class structure.
A key innovation of IUPG is to differentiate classes with and without uniquely identifiable structures (patterns) in their usage for learning. Here, the malware class has uniquely identifiable structures (we call it a “target” class), while the benign class is inherently random (we call it the “off-target” class). The IUPG learning framework is specifically designed to learn the uniquely identifiable structures within target classes. Off-target data helps to chisel down those learned features of target classes to that which is truly inseparable. This is all in an attempt to shrink the overall receptive field of a neural network (i.e. data patterns that are sensitive exclusively to malicious patterns). If no malicious patterns are found, only then is a benign verdict produced. This is to say, an unknown file is innocent until proven guilty.
Conventional, unconstrained learning is free to utilize benign patterns in the training data, which ultimately confers no information about the safety of a file as a whole. Owing to the near limitless breadth of possible benign patterns, we hypothesize these features of the benign class are unlikely to be useful outside of your train, validation and test splits (which often share the sampling strategy). At worst, they teach the classifier to be sensitive to benign content – leading to successful append attacks.
How Does IUPG Overcome Benign Append Attacks?
All the IUPG learning framework components are built around an abstracted network, N (pictured in Figure 3). Please reference our study for an in-depth explanation of each component.
Figure 3. Illustration of all IUPG components augmented onto the abstract network, N.
The IUPG learning framework helps to build networks that are able to perform classification in a new way that, among other things, helps to prevent successful benign append attacks. With IUPG, we are specifically concerned with classification problems that feature mutually exclusive classes, meaning each data point belongs to one class only. In short, both an input sample and a library of learned prototypes are processed by an IUPG network with each inference. The prototypes are learned to encapsulate prototypical information about a class. They act as a representative input of a class of data such that all members of that class share an exclusive commonality. Samples and prototypes are mapped by the network to an output vector space paired with a specially learned distance metric. IUPG networks learn the prototypes, the variables of the network and the distance metric, such that the output vector space orients all entities as pictured in Figure 4.
Figure 4. Illustration of the ideal output vector space with IUPG.Figure 5. Illustration of how IUPG loss operates on inputs that are mapped to the output vector space.
In the ideal mapping, class members and their assigned prototype(s) map uniquely to a common point(s) with a margin of space such that any possible input that isn’t a member of the class maps somewhere else. If a mapped sample is measured to be close enough to a prototype, it is predicted to be a member of the class to which that prototype was assigned. Pictured as a blue cloud in Figure 4, a background of noise, aka off-target data, helps to illuminate (and capture in the prototypes) what is truly inseparable about the target classes. IUPG can still be built without off-target data. We report stable or increased classification performance with several public datasets of this variety. However, certain problems with one or more structureless or inherently random classes are a natural fit to make use of this feature.
Figure 6. Illustration of pushing and pulling forces in the output vector space with multiple prototypes per target class.
In deep learning, a network’s loss function is used to calculate the error of a given model. Lower values of the loss function define what is the desired behavior compared to higher values. Minimizing a loss function (called training) updates the variables in the network to produce a lower loss value. Minimizing IUPG loss encourages the ideal mapping (illustrated in Figure 4) by orchestrating pushing and pulling forces between samples and every prototype in the output vector space, as illustrated in Figure 5. Note that off-target samples are pushed away from every prototype. Refer to our study for the full details on the mathematical structure of IUPG loss. As illustrated in Figure 6, when more than one prototype exists for a target class, we only operate on the closest prototype for that target class, as determined by the given distance metric.
Coming back to the question of classifying a sample as malware or benign, we specify several prototypes for the malicious class while defining the benign class as off-target. It is hopefully clear now why it is imperative to learn the uniquely identifying patterns of malware while encoding robustness to benign content. In the ideal case, the network exclusively captures the inseparable features of malware families, such that their activation is as strong an indicator of malware as possible and no other features lead to significant activation. In our experiments, the network and prototypes learn to recognize complex, high-level combinations of patterns that generalize across malware families and even orphan cases, yet still retain robustness to benign activation.
Below is a real-world example of the output vector space for a multiclass JavaScript malware family classifier, post-training. The network was trained to recognize nine different JavaScript malware families (listed in the legend), along with the off-target benign class. Each of the nine target malware family classes is grouped tightly around a single assigned prototype, while benign data is mapped more arbitrarily toward the center. This visualization was produced by using t-SNE on the mapped representations of validation data and the prototypes in the output vector space.
Figure 7. A plot of the output vector space of a multiclass JavaScript classifier, after training was completed. Prototypes are denoted with gray circles.
What Are the Experimental Results?
In our study, we explore multiple effects of using IUPG compared to the conventional CCE loss function. Note that all these effects are logically connected to the concept of building a network with increased embedded robustness to out-of-distribution (OOD) content. These are:
Stable or increased classification performance across an interdisciplinary variety of datasets and models. We hypothesize that this is primarily provided by building a network that is explicitly robust to noise. The prototyping mechanism also naturally deters the network from overfitting on small facets of training data samples.
Up to 50% decreased false-positive responses on synthetic noise and, more generally, OOD content. We hypothesize this is primarily provided by stricter, more “airtight” models of structured classes that are more robust to accidental activation on stray content.
Decreased performance loss due to recency bias in the presence of distributional shift. We hypothesize this is primarily due to defining the benign class as the off-target class. This builds a model that is less sensitive to distributional shifts in the benign class.
Decreased vulnerability to some noise-based adversarial attacks. Similar to what is mentioned above, we hypothesize this is primarily due to lessened activation on and modeling of the benign class. For our benign append attack simulations, the networks trained with IUPG flip their verdict up to a full order of magnitude times less than the network trained with CCE.
Please refer to our study for a thorough breakdown of these results and more. In particular, we also consider the opportunity to combine IUPG with existing adversarial learning and OOD detection techniques. We discover favorable performance upon the use of IUPG compared to conventional techniques. We want to emphasize this combinatory potential. We feel that this is the strongest path toward successfully thwarting real-life attacks on malware classifiers in future work.
Examples of Live IUPG Detections in Palo Alto Networks Products and Services
Palo Alto Networks uses IUPG-trained models to proactively detect malicious websites, and, in particular, JavaScript malware on web pages. From mid-April to mid-May, we detected over 130,000 malicious scripts and flagged over 240,000 URLs as malicious. Palo Alto Network customers attempted to visit those URLs at least 440,000 times, but were protected by Advanced URL Filtering.
Among others, we do see many cases of malicious redirectors or droppers injected into benign JavaScript on compromised websites. Those are usually small pieces of code that use various obfuscation techniques to hide the code intent from signature analysis or inspection by a human. Benign libraries are often minimized, which makes it hard to separate the malicious piece automatically. We’ve found that IUPG does a notably good job of it.
Attackers leverage the append attack technique either by injecting malicious scripts into popular JavaScript libraries (Figures 8 and 9) or by adding more white spaces (Figure 10). Popular choices for injection among attackers are various jQuery plugins and custom bundled files with website dependencies.
Figures 8a and 8b show a good illustration of why signature or hash matching is not enough and we have to deploy advanced machine learning and deep learning models to protect against “patient zero” malicious scripts. Both 8a and 8b are examples of the same malicious campaign, which is hard to catch as it generates many unique scripts and uses different obfuscation techniques for the injected piece. While the SHA256 of 8b was already known to VirtusTotal at the time of writing, the SHA256 of 8a, was new – in other words, previously undetected.
Figure 8a. One example of a malicious campaign that injects malicious redirectors into a large jQuery Easing library. Two malicious injections are shown prepended to the file. Usually, such malicious scripts are observed on URL paths mimicking legitimate jQuery (wp-content/themes/marchie/js/jquery.easing.1.X.js?ver=1.X). SHA256: a248259f353533b31c791f79580f5a98a763fee585657b15013d1bb459734ba8Figure 8b. One example of a malicious campaign that injects malicious redirectors into a large jQuery Easing library. Two malicious injections are shown prepended to the file. Usually, such malicious scripts are observed on URL paths mimicking legitimate jQuery (wp-content/themes/marchie/js/jquery.easing.1.X.js?ver=1.X). SHA256: cf9ac8b038e4a6df1c827dc31420818ad5809fceb7b41ef96cedd956a761afcdFigure 9. Malware injection mixed in a file with the legitimate Sidr and Superfish jQuery plugins. SHA256: a7007a7b89e5114cd1b532e5bcdaa1dfbe8b0c50ad30c3dbb4eb8fbfec18a746Figure 10. Malware injection with added white spaces and paddings aiming to fool machine learning classifiers. SHA256: e25953bd6701d196fc7f372476db2ce8b1c80a2714ca7fc075073609f0d0f919
In addition to redirectors and droppers, IUPG is efficient in detecting JavaScript malware, such as phishing kits, clickjacking campaigns, malvertising libraries or exploit kits. For example, a similar script as the one shown in Figure 11 was found on over 60 websites, such as regalosyconcurso2021.blogspot.{al, am, bg, jp, com, co.uk}. Note that the script is using heavy obfuscation techniques, but can nevertheless be accurately detected by an IUPG-trained model.
Figure 11. Obfuscated phishing JavaScript in HTML that generates a fake social media login page. SHA256: 3b3dcd8fbf6b359d4d72573441583712f259b54d6a2b59a15f50178fbf0567f5
Conclusion
We’ve introduced the Innocent Until Proven Guilty (IUPG) learning framework, explained how it’s designed to overcome the benign append attack, summarized results from our study presented at the 4th Deep Learning and Security Workshop and shared some interesting examples of using IUPG on real-world traffic. Palo Alto Networks continues to improve state-of-the-art malicious JavaScript detection. Our Next-Generation Firewall customers who use Advanced URL Filtering, DNS Security, and WildFire security subscriptions are better protected against benign append attacks through the use of IUPG.
Web-based consoles are widely adopted by management software and smart devices to provide interactive data visualization and user-friendly configuration. This is gaining momentum as enterprises' computer systems become more complex and more modern internet of things (IoT) devices are used at home. These web applications are usually located in internal environments or private networks protected by firewalls. Therefore, they usually have a high trust level for visitors. They typically assume all visitors are authorized and thus expose sensitive information or provide administrator privileges without strong application-level protection.
Although the web services in private networks are supposed to be isolated from the internet and the same-origin policy prevents arbitrary websites from interacting with internal servers, hackers can still take advantage of web-based consoles to exploit internal networks by abusing the domain name system (DNS) through a technique called DNS rebinding. This technique can expose the attack surfaces of internal web applications to malicious websites once they launch on victims' browsers.
In this blog, we present the mechanism and severity of the DNS rebinding attack with penetration examples. After that, we introduce the mainstream mitigations against this attack and their limitations.
Palo Alto Networks has launched a detector to capture DNS rebinding attacks from our DNS Security and passive DNS data. Our system provides scalable detection for various DNS rebinding payloads and reduces the false discovery rate by 85.09% compared to the traditional IP filtering solution. It ingests the DNS data in real time to identify penetration activities as soon as possible.
Allowing arbitrary cross-origin requests is known to be extremely dangerous. Therefore most modern browsers block these requests. However, DNS rebinding provides a way to bypass this restriction. This section introduces the importance of the same-origin policy and how the DNS rebinding technique works.
Same-origin Policy
Web applications usually require various resources such as JavaScript, images and CSS to render web pages. A web page can obtain these resources from the same server as itself or from different origins. Requesting cross-origin resources enables an application to benefit from shared resources such as third-party script libraries. However, allowing a website to access resources from arbitrary origins can be a disaster. Without access control, a malicious web page can abuse the trust granted to a legitimate user and send unauthorized requests to a critical web application on that person’s behalf. This exploit is known as cross-site request forgery (CSRF).
Modern browsers enforce the same-origin policy to mitigate this threat. This policy forbids a script from reaching web resources from different origins. Under this policy, a web page can still load cross-origin resources in its HTML tags. For example, it can embed an iframe showing third-party advertisements. However, malicious websites can't read the response content of cross-origin requests through scripts.
DNS Rebinding
The same-origin policy identifies different origins with the combination of URI scheme, hostname and port. Among these components, browsers rely on hostnames to recognize different servers on the internet. However, hostnames are not directly bound to network devices. Instead, they are resolved to IP addresses by DNS. Then, IP addresses bind to devices statically or dynamically. Since domain owners have complete control of their DNS records, they can resolve their hostnames to arbitrary IP addresses. The DNS rebinding attack abuses this privilege. After the victims' browsers load the attacking payloads from the hacker's server, attackers can rebind their hostnames to internal IP addresses pointing to the target servers. This allows attackers’ scripts to access private resources through malicious hostnames without violating the same-origin policy.
Figure 1. Mechanism of DNS Rebinding.Figure 1 demonstrates the mechanism of a DNS rebinding attack with a hypothetical example. In this example, the victim, Alex, has a private web service in his internal network with IP address 192[.]0.0.1. This server contains confidential data and is supposed to be accessed by Alex's computer only. On the attack side, Bob controls two servers: a DNS resolver (1[.]2.3.4) and a web server (5[.]6.7.8) hosting the malicious website. In addition, Bob registers a domain, attack[.]com, with its nameserver (NS) record pointing to 1[.]2.3.4.
When Alex opens attack[.]com in his browser, it sends a DNS request to Bob's resolver and retrieves the address of the malicious server, 5[.]6.7.8. Once loaded in Alex's browser, the malicious script in Bob's website attempts to trigger another DNS resolution for its own domain. However, this time the resolver will return 192[.]0.0.1 instead. So attack[.]com is rebound to the target IP address. After that, the malicious script can keep sending requests to attack[.]com, which eventually reach the private server. Since Alex's browser won't recognize these requests as cross-origin, the malicious website can read the returned secrets and exfiltrate stolen data as long as it's open on the victim's browser.
DNS Rebinding in Real-World Attacks
Using DNS rebinding, attackers can abuse victims' browsers as their proxy to extend the attack surface to private networks. This technique significantly increases the potential vulnerabilities exposed to hackers as more web applications launch on enterprise and home networks. In addition, the default trust level of internal service is high. Therefore, DNS rebinding can play a pivotal role in real-world attacks combining various penetration techniques and vulnerability exploits. This section demonstrates how it's involved in practical penetration with Singularity, an open-source DNS rebinding platform.
Private Network Penetration With DNS Rebinding
The initial step of the DNS rebinding attack is the same as other web-based attacks: tricking victims into opening malicious websites through various social engineering techniques such as sending phishing emails and cybersquatting.
Figure 2. The result of internal network scanning by Singularity.
After launching malicious websites on victims' browsers, hackers need to identify the private IP addresses and ports that host vulnerable services before executing the DNS rebinding attack. The attacking websites can scan the open web services in local networks with the WebRTC technique. Singularity implements a more straightforward strategy: directly send out cross-origin requests and measure how long it takes to receive error messages. If the requested server exists, the exception will be raised more quickly. Figure 2 shows how Singularity performs when scanning our experimental environment. It recognizes the internal services hosted on 10[.]0.0.6:80 and 10[.]0.0.6:8080 in seconds. This step exposes the available targets for DNS rebinding. Through the open ports, attackers can also infer what web applications are behind these IP addresses and whether they are vulnerable.
After locating the target services, the attacker's website can perform the DNS rebinding attack in its iframe. The first request retrieves the rebinding payload from the malicious hostname. This attacking script will keep triggering repeated resolution for its hostname until it rebinds to the target IP address. Then the iframe can keep communicating with the internal service without the victim's awareness.
In real-world attacks, one of the potential targets of DNS rebinding is network infrastructure devices with HTTP-based consoles. For example, personal routers could be vulnerable to the attack. Many of them are set up with default configuration and weak passwords. This means that would-be penetrators can easily guess their IP addresses and rebind malicious hostnames to them. After the attackers enter the network configuration panels, they could sniff the network packages in the victim's network, perform denial of service (DOS) attacks and hijack the traffic.
Figure 3. Trend of DNS rebinding-related CVEs.
Another kind of threat comes from smart devices, which are all around many homes and offices nowadays. Besides web-based consoles, DNS rebinding can target other Restful APIs and Universal Plug and Play protocols (UPnP) servers exposed to internal networks by modern IoT devices. These APIs are reserved for function implementation or maintenance. However, some of them lack enough protection against DNS rebinding. Once attackers compromise victims' browsers and rebind their hostnames to the target IP address, these services provide them certain privileges such as network scanning, exfiltrating sensor data and remote control without any authentication. DNS rebinding vulnerabilities have been found on multiple smart devices of high-profile companies including Google Home, Sono WiFi Speaker and Roku. As shown in Figure 3, there has been at least one CVE record related to DNS rebinding each year since 2015. The number of related CVEs has increased significantly since 2018.
Figure 4a. Target internal web application (Hadoop interface) rendered on victim’s browser.Figure 4b. Attacker’s website rendered on victim’s browser.Figure 4c. Target internal web application rendered on attacker’s browser.
For enterprises, internal management web applications are critical. They host confidential information and provide system management capabilities to administrators. Therefore, it's extremely dangerous having a DNS rebinding website running on a machine within company networks.
Here, we launch a DNS rebinding attack on our simulated environment to illustrate the risk. The target internal web application is an internal Hadoop web interface. As shown in Figure 4a, the victim can visit this UI with URL 10[.]0.0.6:8088/cluster and check the cluster status while it's not available externally. Figure 4b shows the rebinding request triggered by the attacker's website on the victim's browser. In this experiment, the malicious hostname is s-54.183.63.248-10.0.0.6-1609933722-fs-e.dynamic.dns-rebinding-attack[.]com. The HTTP request to the hostname was actually sent to 10[.]0.0.6, and it received the successful status code. After this, the attacker can use the victim's browser as a tunnel and directly interact with the target service. As shown in figure 4c, the attacker can obtain the same information that the victim can access from the Hadoop cluster through the malicious domain. Besides stealing information, the attacker also has the privilege to kill running jobs on the management page. As we saw in this example with Hadoop, many widely used development and management platforms could be exposed to threat actors equipped with DNS rebinding if not protected correctly.
Cross-origin Request Forgery Protection Bypass
Besides simply tunneling traffic for attackers, malicious websites can use the DNS rebinding technique to bypass token-based CSRF protection. While DNS rebinding hides the cross-origin traffic, CSRF directly sends cross-origin requests to take advantage of the target server's trust for the victim. CSRF is a well-known threat, and many web applications have implemented defenses against it. One mainstream protection strategy embeds a unique token to the initial response page. All the following requests need to be sent with this token to be accepted by the server. This solution is based on the same-origin restriction, which prevents malicious websites from reading the response content of cross-origin requests. Since attackers can't obtain the token from the response, they have no chance of sending out valid cross-site requests.
Figure 5. Target internal web application rendered on attacker’s browser.
However, browsers won't notice any cross-origin request under the DNS rebinding attack. This means they will allow malicious scripts to obtain the CSRF token from the initial responses and use it for follow-up request forgery.
We launched the remote command execution (RCE) payload of Singularity in our simulation environment to demonstrate this threat. This attack targets Rails, a web development framework written in Ruby. One of its reserved PUT APIs allows the requester to run arbitrary system commands on the server. Similar to the CSRF token, this API requires the visitor to generate the request URL with a dynamic session ID (the string marked in red in Figure 5), which is embedded on the main page. The web application will generate a new token on the fly and map one to each session. It's impossible to predict the valid API endpoint without reading responses from the server. However, the Singularity RCE payload can obtain the token from the index page after executing DNS rebinding. In the demo, we let the malicious site print the stolen session ID to the browser console. Then it successfully constructed the desired URL and used the vulnerable API to execute an arbitrary command on the server-side, which displays a "Hello from rebinding test" message on the server terminals. After the Singularity team published this exploit, Rails enforced server-side mitigation to validate the host field of all incoming requests.
DNS Rebinding Protection
Various strategies attempt to mitigate the DNS rebinding attack in each related network component. In this section, we introduce different defense mechanisms and their limitations. After that, we will present the basic idea of our DNS rebinding detector and its advantages.
Browser-based Mitigation
Modern browsers such as Chrome and Firefox have implemented the DNS pinning technique to defend against the DNS rebinding attack. This strategy forces the browser to cache the DNS resolution results for a fixed period regardless of the DNS records' time-to-live (TTL) value. Consequently, malicious websites can't rebind their hostnames by making repeated DNS requests within this period. This protection is convenient because it can be implemented in browsers without changing any other network infrastructure. However, it can only effectively block the time-varying attack, which is a traditional implementation of the DNS rebinding attack. In this implementation, the attackers assign an extremely low TTL to the DNS record of malicious hostnames. After being loaded in the victim's browser, the rebinding script waits for the record expiration and then sends a request to its hostname, expecting the browser to resolve it again and get the target IP address back. In this scenario, the DNS pinning technique ignores the low TTL and still uses the same result for the second request.
However, there are multiple ways to bypass DNS pinning protection. A simple way is to design the malicious script to send requests repeatedly until the browser cache expires. Then the malicious hostname will rebind to the target IP address. Then, the attacker's website can receive the expected response from the target service.
Figure 6. Mechanism of multiple A-records attack.A more sophisticated implementation called multiple A-records attacks can achieve DNS rebinding more stably and efficiently even with DNS pinning protection. Figure 6 presents the attacking procedures. In this case, the DNS behavior is different from the traditional attack: The victim's browser only resolves the malicious hostname once. But both the attacker's and the target's IP address are returned. When the malicious script sends the second request, the browser will try the public IP address first. But the attacker's web server remembers the victim's IP address and blocks the incoming traffic by firewall. This request failure forces the victim's browser to communicate to the private IP address and complete the DNS rebinding procedure.
DNS-based Mitigation
Another type of mitigation focuses on the DNS resolution stage. The secure DNS service, OpenDNS, drops the DNS responses pointing to RFC 1918 and loopback IP addresses. DNS caching software such as Dnsmasq and Unbound also implement similar filtering policies for private IP addresses.
This strategy is also a centralized protection solution, but it still has limitations. First of all, not all the secured DNS services have blocked the complete list of IP addresses pointing to private services. For example, the non-routable IP address 0[.]0.0.0 can represent the IP addresses of the local machine and can be targeted by a DNS rebinding attack. However, multiple filtering policies have missed it. Besides the private IP addresses, attackers can rebind their hostnames to internal hostnames with CNAME records. The victims' internal resolvers or their machines will finish the resolution to private IP addresses for the attackers. For example, a malicious hostname can be rebound to localhost. Then all following traffic will reach the local service. In summary, IP-based filtering fails to protect against all types of DNS rebinding attacks.
Furthermore, filtering out all private IP addresses could cause many cases of blocking false positives. We observed that some legitimate services present similar DNS resolution behaviors as DNS rebinding. For example, some IoT services rely on hostnames to direct traffic within private networks. This means their hostnames are resolved to internal IP addresses only and can be mistakenly blocked by this solution. Besides, some benign hostnames also resolve to both public and private IP addresses that violate this protection policy. For example, public services could have mirror servers in the maintainers' networks for continuous development and traffic optimization. Their hostnames have public A records pointing to public and private IP addresses. In these cases, the maintainers will talk to the internal server while the public server handles other traffic.
We measure the hostnames resolved to internal IP addresses in passive DNS data to quantify the impact of false blocking. In June 2021, 8.99% of total active hostnames pointed to private IP addresses. DNS-based mitigation would block all of their traffic. However, 99.84% of these hostnames never point to any public IP, which means they don't present the complete DNS rebinding behavior and shouldn't be blocked. The false discovery rate for DNS traffic of this mitigation is 85.09%.
Server-based Mitigation
Defenses on the web applications side can block DNS rebinding effectively. One of the solutions is implementing HTTPS communication on all private services. The HTTPS handshake stage requires the correct domain to validate the SSL certificate. During a DNS rebinding attack, browsers think they are communicating to the malicious domains while the SSL certificates from the internal servers are for different domains. Therefore, the attacking scripts can't establish SSL connections to the target services. Alternatively, implementing authentication with strong credentials on all private services is also effective. With this application-level protection, even if attackers launch DNS rebinding successfully, they can't access confidential information.
However, this kind of mitigation depends on the developer of internal services. This means it is not scalable. As third-party web applications populate in both home and enterprise environments, it's more difficult for the network owners to enforce protection to all potentially vulnerable servers. Meanwhile, threat hunters keep digging DNS rebinding vulnerabilities from third-party web applications – such as the Rails console RCE exploit mentioned in the previous section.
Real-time DNS Rebinding Detection
As our DNS Security service monitors our customers' DNS traffic to provide real-time protection, we have the opportunity to enforce sophisticated signatures to recognize the abnormal DNS query pattern of the DNS rebinding attack. We launched a detection system consuming DNS Security and passive DNS data to capture the indicators of compromise (IOCs) of ongoing rebinding attacks. The detector tracking DNS Security traffic can identify and deliver malicious hostnames in real time.
Our system aims to capture the sequential DNS resolution pattern instead of relying on isolated DNS responses. Its detection logic can identify DNS rebinding with high confidence while allowing hostnames that resolve to internal IP addresses only for legitimate usage. Besides the high detection accuracy, our system can cover all the varieties of DNS rebinding attacks mentioned previously, including time-varying, multiple A-records and CNAME-based attacks. Apart from attacks targeting internal IP addresses and localhost, it also recognizes malicious hostname rebinding to the internal hostnames of our customers.
Behind the detection module, we aggregate multiple layers of legitimate usage filters to prevent false positive detection. As mentioned above, many innocent hostnames could present similar resolution behavior as the DNS rebinding attack. It's hard to differentiate them from malicious hostnames without additional information. Our filters combine external knowledge such as passive DNS traffic, WHOIS records and customer feedback to exclude customers' internal hostnames and other benign services.
Conclusion
The DNS rebinding attack can compromise victims' browsers as traffic tunnels to exploit private services. With this technique, attackers can steal confidential information and send forged requests to victims' servers. Browsers, resolvers and web applications have applied various protection strategies to defend against it. However, there are advanced exploits that can bypass traditional defenses. In addition, it's harder to enforce complete protection as the internal network environment becomes more complex.
At Palo Alto Networks, we have launched a DNS rebinding detection system to protect our customers. It can effectively identify various implementations of DNS rebinding that leverage multiple types of DNS records and present different resolution behaviors. The system's filtering module can identify legitimate usage of internal IP resolution to prevent false blocking. After capturing potential penetration activities, our system will release the attacking hostname with the command and control category to Palo Alto Networks Next-Generation Firewall security subscriptions in real time.
Acknowledgments
Special thanks to Laura Novak and Daiping Liu for their help with improving the blog.
We have observed exploits in the wild for a recently disclosed command injection vulnerability affecting WebSVN, an open-source web application for browsing source code. The critical command injection vulnerability was discovered and patched in May 2021. A proof of concept was released and within a week, on June 26, 2021, attackers exploited the vulnerability to deploy variants of the Mirai DDoS malware. We strongly recommend that WebSVN users upgrade to the latest software version.
Like many source code browsing tools, WebSVN allows users to search through the revision history to find relevant code changes. These search requests are made by sending a query to the backend, which is written in PHP.
Figure 1. The user’s input is read from the “search” parameter in search.php.
In versions of WebSVN prior to 2.6.1, the user’s search query is not escaped when it is used in a shell command. Inside include/svnlook.php the function getListSearch is responsible for creating the shell command by concatenating the search query with command arguments.
Figure 2. The SVN command is created by concatenating it with the search query.
A function called runCommand inside include/command.php finally executes the command by passing it to PHP’s proc_open function. The documentation for this function contains the following warning regarding the command parameter:
Figure 3. PHP documentation.
Without properly escaping the user’s input, it is possible to achieve code execution by including special characters in the search query. To fix this vulnerability, the code was changed to sanitize the user input with escapeshellarg before concatenating it to the other command arguments.
Figure 4. Vulnerability patch.
Another possible solution is to allow proc_open to automatically escape and quote the command by passing an array of strings as the first argument. This approach might be considered more concise and easier to maintain. However, it would have required making bigger changes to the existing code, and it is not compatible with older versions of PHP, which is likely the reason this solution was not chosen.
Figure 5. Hypothetical code for safely running the shell command.
Exploitation in the Wild
Shortly after CVE-2021-32305 was made public, Unit 42 researchers observed attackers exploiting it in the wild. One example of an attack is shown here:
Figure 6. HTTP request.
The attacker uses command injection to download a shell script that will infect the system with malware. When abusing these types of web vulnerabilities, some important details about the target environment may be unknown to the attacker. These details include the operating system and processor architecture that the web server is running. The shell script used in the next step of the attack shows how the attacker can overcome this issue:
Figure 7. Shell script
Malicious Linux binaries are provided for 12 different architectures. Instead of detecting which one is correct for the target environment, a brute force approach is taken. The script simply downloads and attempts to execute the binaries for every one of the possible architectures, disregarding any incompatibility errors. Although WebSVN is a cross-platform PHP application capable of running on many operating systems, only Linux binaries are used in this attack.
Malware Analysis
Analysis of this malware reveals that it is used to perform distributed denial of service (DDoS) attacks and that it shares some of its code with the Mirai botnet family. To reduce the size of the executable files, each one is compressed with a modified version of the popular open-source packer, UPX. Because the packer is modified, it is less likely for reverse engineering tools to succeed in automatically unpacking the executable files, requiring more manual effort for analysis. Additionally, the malware achieves portability by statically linking all of its dependencies and making system calls directly inside the code.
After the malware is executed, it continuously tries to connect to its command and control (C2) server on port 666. Once it establishes a connection, it communicates using a custom text-based TCP protocol. It begins by informing the C2 of its architecture, and then it awaits commands from the operator.
Figure 8. Main loop for processing C2 commands.
The main purpose of this malware family is to perform DDoS attacks, and the effectiveness of an attack depends on the network protocols and techniques that are used. In the analyzed sample, there are eight types of attacks, each designed to be effective against a different type of target. The following table shows the commands the malware operator can send to initiate each one.
Command
Protocol
Description
OVHHEX
UDP
Targets servers hosted by OVH, a French cloud computing company.
UDPBYPASS
UDP
Attempts to bypass network mitigations by sending crafted packets at calculated time intervals.
NFOHEX
UDP
Floods the target with randomly generated hex-encoded data.
STD
UDP
Randomly sends packets from a list of three predefined payloads.
VSE
UDP
Targets game servers built with Valve Source Engine.
TCP
TCP
General attack for TCP-based protocols.
SYN
TCP
Sends SYN packets to imitate a TCP connection request.
ACK
TCP
Sends ACK packets to imitate acknowledgement messages.
Table 1. DDoS methods.
Conclusion
We observed exploits in the wild for a recently disclosed command injection vulnerability affecting WebSVN. In one particular attack, the vulnerability is used to deploy DDoS malware. Attackers will continue to exploit the latest vulnerabilities to expand their army of infected devices and increase the strength of their DDoS attacks. Customers are strongly advised to upgrade to the latest software version.
Palo Alto Networks Next-Generation Firewall customers are protected by the subscriptions:
With more and more companies choosing to allow for flexible (hybrid/remote) work environments post-pandemic, we investigated the unique cyberthreats employees working from home face.
Our analysis focused primarily on trends in our firewall traffic and phishing pages detected by our URL Filtering service from September 2019 to April 2021. We found that in early 2020, when employees were making the shift to working from home, there was a significant drop in traffic coming through our URL Filtering service, coinciding with a significant increase in the number of new phishing pages per week. This suggests that at the peak of remote work, right when the smallest percentage of end-user traffic was being protected by corporate firewalls, threat actors were putting out more phishing attacks than ever.
By comparing the rate of phishing traffic coming from our on-prem firewalls versus our cloud-delivered security platform, Prisma Access, we discovered that remote employees might be especially vulnerable to a wide variety of phishing attacks. Specifically, we saw that the percentage of traffic coming from phishing pages was more than 2.4 times greater in Prisma Access traffic than in on-prem firewall traffic. This emphasizes the need to have the proper defenses in place for employees who are either fully remote or working from home.
With phishing attacks continuing to rise globally, it’s more important now than ever that all employees are able to safely and securely browse the web, regardless of whether they are working in the office or from home. Tools like Prisma Access and GlobalProtect can help shield remote and/or hybrid employees from these cyberthreats by ensuring that they have access to the same security services afforded by Palo Alto Networks Next-Generation Firewalls.
Firewall Traffic Trends
We began our analysis by investigating trends in our URL Filtering traffic from before the pandemic, starting in September 2019. We observed a sudden and significant drop in traffic from March-April 2020, just as COVID was beginning its initial spread throughout the U.S., forcing organizations to shift to remote work.
Figure 1. Total observed URL Filtering traffic per week from September 2019-April 2021.
We then investigated how changes in customer traffic differed between our on-prem Next-Generation Firewalls and our cloud-delivered security platform, Prisma Access. We saw that weekly traffic from our on-prem firewalls (blue in Figure 2 below) dropped quite significantly – by about 45% – from March-April 2020. In contrast, weekly traffic from Prisma Access (orange in Figure 2) increased by more than 200% as employees suddenly shifted to working remotely. (The dips in December 2020 and December 2021 correspond to holiday breaks.)
This suggests that organizations relying solely on on-prem firewalls, without adjusting to increased remote work by deploying cloud-delivered security services, were far more vulnerable to a variety of cyberattacks since their now-remote employees were able to browse the web unprotected.
Figure 2. On-prem firewall traffic versus Prisma Access (cloud) traffic from September 2019-April 2021. Normalized such that the maximum weekly traffic is represented with a value of 1.00.
To further investigate this point, we looked into which industries experienced the greatest drops in total URL Filtering traffic from March-April 2020. We noticed that the education and high tech industries experienced especially large decreases in traffic during this period: education (~46% decrease), presumably due to school closures, and high tech (~35% decrease), presumably due to employers’ willingness to let employees work remotely given the industry’s inherently digital nature. All in all, nearly every industry we studied experienced a significant drop in URL Filtering traffic of roughly 30% or more during this time.
Figure 3. Total weekly traffic by industry from September 2019-April 2021.
These significant drops in observed URL Filtering traffic stress the importance of having access to security services regardless of where your employees or end users are physically located. Although our observed URL Filtering traffic dropped at the start of the pandemic, internet usage as a whole went up by ~25% in mid-March, according to the Wall Street Journal. (Total internet usage then dipped slightly in May, but still stayed higher than pre-pandemic levels). This suggests that despite the drop in traffic, people were not necessarily using the internet any less than before. Rather, people were on average using the internet evenmore than before, with a larger proportion of that internet traffic being unprotected by enterprise-grade firewalls, leaving end users more vulnerable than ever to a wide variety of cyberthreats.
Since the hybrid work model is likely here to stay post-pandemic (according to The Work Trend Index, a report published by Microsoft, over 70 percent of employees across a variety of industries want flexible remote work options to continue), organizations must rethink how to protect their workforces moving forward, which starts by making digital security an integral part of their hybrid and/or remote work plans.
Phishing-Related Trends
To study how attackers may have responded to this increase in remote work, we investigated the number of phishing URLs detected by our ML-powered URL Filtering service from September 2019-April 2021.
We observed an initial upward trend in new phishing URLs starting around February 2020, peaking around June 2020. Looking at Figure 4, we can see that the largest number of new phishing pages (orange) was observed just as URL Filtering traffic (blue) was at its lowest point (May-June 2020). This suggests that the high prevalence of remote work at this time coincided with a high rate of attempted phishing attacks.
Figure 4. Total URL traffic versus number of new phishing URLs from September 2019-April 2021
Next, we used keyword matching to determine which URLs were business-related (targeting various business communication and/or collaboration tools) and which phishing URLs were consumer-related (targeting well-known social media brands, consumer banking sites, etc.). We found that business-related and consumer-related phishing attacks increased by roughly 100% from February 2020 to June 2020. This suggests that the types of phishing attacks responsible for the spike during this time period did not necessarily change – but rather, the total volume of attempted phishing attacks increased across the board.
In addition, we can see from the upward trend toward the right side of Figures 4 and 5 that the rate of new phishing attacks shows no signs of slowing down anytime soon.
Figure 5. Business-related versus consumer-related phishing URLs per week from September 2019-April 2021.
Figure 6. office365invoicea[.]xyz/ce: A typical example of a business phishing webpage targeting Office365. This page requires that the user first interacts with the page to see the phishing form, possibly in an attempt to evade automated phishing detection engines.Figure 7. ww3ecure-authlogin4[.]ns02[.]info/Chase%20New/: A typical example of a consumer phishing webpage targeting Chase bank.Finally, we investigated which industries are the most affected by these phishing attacks. We did this by calculating the percentage of total traffic for organizations in each industry that came from phishing webpages from September 2019-May 2021.
Figure 8. Percentage of phishing traffic relative to the total traffic by industry from September 2019-May 2021.
We found that the telecommunications industry was by far the most heavily impacted by phishing attacks, with about 0.1% of total traffic coming from phishing webpages. Of note, the high tech and education industries (both of which experienced significant drops in firewall traffic during the pandemic) also happen to be among the top-five most heavily affected industries.
Figure 9. Percentage of phishing traffic relative to total traffic for on-prem firewalls versus Prisma Access from March 2020-April 2021.
Furthermore, we saw that the percentage of traffic coming from phishing pages was more than 2.4 times greater in Prisma Access traffic than in on-prem firewall traffic. While we can’t be certain of the underlying reasons behind this, one plausible explanation is that employees may be less on-guard against phishing links when working outside the office. If this is indeed the case, then that would make it doubly important that employees who are working remotely have access to adequate internet security like URL Filtering to protect them from online threats such as phishing attacks and other malicious webpages.
Securing Your Remote/Hybrid Workforce
With today’s work environment shifting more and more to the virtual sphere, and with more and more work happening outside the physical boundaries of an office or corporate campus, it’s often no longer enough to rely entirely on on-prem firewalls to keep end users protected while browsing the web.
We can see that attackers tried to make the most of this sudden spike in remote work by ramping up their rate of phishing attacks, going after end users’ corporate credentials, as well as their personal credentials. We are now observing more new phishing attacks per week now than ever before, and our findings suggest that remote employees may be especially vulnerable to these phishing attacks, emphasizing the importance of having the proper defenses in place.
For end users who have access to Palo AltoNetworks URL Filtering services (e.g. via Prisma Access or GlobalProtect), it is likely that many of these phishing URLs would have been blocked before even being rendered in the user’s web browser. For end users working from home without access to a Next-Generation Firewall or cloud-delivered security service, it is likely that more of these attacks would have been successful, and that many end users have been fooled into giving attackers either their business login credentials or sensitive personal information.
With more companies looking to adopt remote and/or hybrid work models in the future, it is more important than ever to ensure that all employees have secure access to the internet, no matter where they happen to be physically located.
Conclusion
We have seen that threat actors ramped up their rate of phishing attacks at the same time as the number of employees who were working from home increased. If employers want to maintain a secure workforce in this new hybrid/remote environment, it is crucial that employees who are working from home have the same access to adequate coverage from cyberthreats that employees who are working in the office do.
Palo Alto Networks remote-work offerings, including cloud-delivered security services such as URL Filtering and Threat Prevention, can protect employees from the latest phishing and malware attacks regardless of whether they are working from the office or remotely.
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’s 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 to your organization’s IT or InfoSec department
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 emails can be the start of ransomware attacks. If you think you may have been impacted by ransomware, please email unit42-investigations@paloaltonetworks.com or call (866) 486-4842 – (866) 4-UNIT42 – for U.S. toll free, (31-20) 299-3130 in EMEA or (65) 6983-8730 in JAPAC. The Unit 42 Incident Response team is available 24/7/365. You can also take preventative steps by requesting a Ransomware Readiness Assessment.
The author would like to thank Wei Wang, Huagang Xie, Mayuresh Ektare, Vaishnavi Grudanti and Mike Jacobsen for helping to set the direction for this research; Claud Xiao, Russell Holloway and Eric Chen for helping to gather the data used in the analyses; and Laura Novak, Jen Miller Osborn, Jim Finkle and Lakshmi Kandadai for their help in publishing the blog.
As part of Unit 42’s commitment to stop ransomware attacks, we conduct ransomware hunting operations to ensure our customers are protected against new and evolving ransomware variants. We monitor the activity of existing groups, search for dark web leak sites and fresh onion sites, identify up-and-coming players and study tactics, techniques and procedures. During our operations, we have observed four emerging ransomware groups that are currently affecting organizations and show signs of having the potential to become more prevalent in the future:
AvosLocker is ransomware as a service (RaaS) that started operations in late June, using a blue beetle logo to identify itself in communications with victims and “press releases” aimed at recruiting new affiliates. AvosLocker was observed promoting its RaaS program and looking for affiliates on dark web discussion forums and other forums. Like many of its competitors, AvosLocker offers technical support to help victims recover after they’ve been attacked with encryption software that the group claims is “fail-proof,” has low detection rates and is capable of handling large files. This ransomware also has an extortion site, which claims to have impacted six organizations in the following countries: the U.S., the U.K., the U.A.E., Belgium, Spain and Lebanon. We have observed initial ransom demands ranging from $50,000 to $75,000.
Hive Ransomware is double-extortion ransomware that started operations in June. Since then, Hive has impacted 28 organizations that are now listed on the group’s extortion site, including a European airline company and three U.S.-based organizations. Hive uses all tools available in the extortion toolset to create pressure on the victim, including the date of initial compromise, countdown, the date the leak was actually disclosed on their site, and even the option to share the disclosed leak on social media.
HelloKitty is not a new ransomware group; it can be tracked as early as 2020, mainly targeting Windows systems. However, in July, we observed a Linux variant of HelloKitty targeting VMware’s ESXi hypervisor, which is widely used in cloud and on-premises data centers. We also observed two clusters of activity. Across the observed samples, some threat actors preferred email communications, while others used TOR chats for communication with the victims. The observed variants impacted five organizations in Italy, Australia, Germany, the Netherlands and the U.S. The highest ransom demand observed from this group was $10 million, but at the time of writing, the threat actors have only received three transactions that sum up to about $1.48 million.
LockBit 2.0 (previously known as ABCD ransomware) is a three-year-old RaaS operator that has been linked to some high-profile attacks lately following the June launch of a slick marketing campaign to recruit new affiliates. It claims to offer the fastest encryption on the ransomware market. LockBit 2.0 has impacted multiple industries – 52 victims are listed on the group’s leak site. Its victims include organizations in the U.S., Mexico, Belgium, Argentina, Malaysia, Australia, Brazil, Switzerland, Germany, Italy, Austria, Romania and the U.K.
Here, we share information we've gathered from our observations of the behavior of these ransomware groups to help organizations defend against them.
AvosLocker is new ransomware that was first observed on July 4, 2021, and follows the RaaS model. The ransomware operator of the same name, avos, advertised their affiliate program on Dread (Figure 1). Dread is a Reddit-like dark web discussion forum featuring news and sub-dreads around darknet markets. The announcement of the program includes information about features of the ransomware and lets affiliates know that AvosLocker operators will take care of negotiation and extortion practices. The user Avos has also been observed trying to recruit individuals on the Russian forum XSS.
Figure 1. AvosLocker announcement in Dread.AvosLocker, when executed, first opens a Windows shell showing the progress of the encryption process. After encryption is complete, it then appends the .avos extension to the encrypted files and drops the ransom note GET_YOUR_FILES_BACK.TXT in every encrypted directory (Figure 2). We observed another AvosLocker sample that behaves exactly the same way as the initial observed sample, but also included a string called “Message from the agent” letting the victim know their files were exfiltrated.
The ransom note includes information and an ID used to identify victims, and instructs the victim to visit the AvosLocker TOR site (Figure 3).
Figure 3. AvosLocker landing page.
After submitting the ID, the victim will encounter a support chat and the request for ransom. From the available instances observed, we have seen payment requests as low as $50,000 and as high as $75,000 in Monero (XMR). As seen with other ransomware groups, AvosLocker increases the ransom price if the victim doesn’t pay in the designated time period, as shown in Figure 4.
Figure 4. AvosLocker support page.
While exploring their site, we discovered that this group has already affected seven organizations: two law firms, one in the U.K. and one in the U.S.; a logistics company in Spain; a real estate agency in Belgium; a holdings company in Turkey; a Syrian transportation organization and a city in the U.S. Some of the leaked data displayed on their site include private organization documents and personal identifiable information.
AvosLocker's first site post, on Jan. 1, 2021, was an announcement that the site was officially online (Figure 5). The user avos also announced they started leaking data on multiple sub-dreads as well. We believe this was done to attract more affiliates and traffic to their site.
Figure 5. AvosLocker leak site and multiple advertisements on Dread.
Hive Ransomware
Hive ransomware began operations in June 2021 and has already shown notable disregard for its victims’ welfare, attacking organizations including healthcare providers and mid-size organizations ill-equipped for managing a ransomware attack. Hive published their first victim on their leak site, Hive Leaks, in late June (Figure 6). Since then, 28 victims have been published on the Hive Leaks site, including a European airline company and three U.S.-based organizations, one each in hardware retail, manufacturing and law. The posts include the date and time the victim was affected.
Figure 6. Hive Leaks.
When this ransomware is executed, it drops two batch scripts. The first script, hive.bat, tries to delete itself, and the second script is in charge of deleting the shadow copies of the system (shadow.bat). Hive ransomware adds the [randomized characters].hive extension to the encrypted files and drops a ransom note titled HOW_TO_DECRYPT.txt containing instructions and guidelines to prevent data loss (Figure 7). The ransom note includes a generated login credential for the victim to chat with what the threat actors claim is their “sales” department. The TOR link directs the “customer” to a login page, and after the credentials are submitted, it opens up a chat room for communication between the operators and the victim (Figure 8).
Figure 7. Hive ransom note.
We noticed that the login credentials provided by the ransom note were for a specific victim. With this in mind, we then hunted for additional samples and found two more victims that were affected but not yet listed on the leak site at the time of writing. After logging in, the victim will see a chat where they can talk to the operators and get their decryptors (Figure 8).
Figure 8. Hive chat (left) and login page (right).
We don’t yet have information on how Hive ransomware is being delivered, but ransomware operators are known for buying access to certain networks, brute-forcing credentials or spear-phishing for initial access.
HelloKitty: Linux Edition
HelloKitty is a ransomware family that first surfaced at the end of 2020, primarily targeting Windows systems. The malware family got its name due to its use of a Mutex with the same name: HelloKittyMutex. The ransomware samples seem to evolve quickly and frequently, with different versions making use of the .crypted or .kitty file extensions for encrypted files. Some newer samples make use of a Golang packer that ensures the final ransomware code is only loaded in memory, most likely to evade detection by security solutions.
In July 2021, we came across a Linux (ELF) sample with the name funny_linux.elf containing a ransom note with verbiage that directly matched ransom notes seen in later samples of HelloKitty for Windows. This led to the discovery of other samples of this Linux strain of the HelloKitty ransomware, dating as far back as October 2020. However, starting in March, the samples began targeting ESXi, a target of choice for recent Linux ransomware variants.
Oddly enough, the preferred mode of communication shared by attackers in the ransom notes across the different samples is a mix between TOR URLs and victim-specific Protonmail email addresses. This could indicate different campaigns or even entirely different threat actors making use of the same malware codebase. Since the samples we found contained victim-specific ransom notes, we were able to get an idea of the ransomware’s targets. We observed six organizations impacted by Hello Kitty, including Italian and Dutch pharmaceutical organizations, a Germany-based manufacturer, an Australian industrial automation solutions organization, and a medical office and a stock broker in the U.S. One sample, oddly enough, didn’t contain any contact information in its ransom note.
We also observed that the ransom demanded by the operator varies depending on the impacted organization; we saw demands as high as $10 million and as low as $950,000 in Monero (Figure 9). The operators behind HelloKitty are also open to using bitcoin (BTC), but they charge higher for bitcoin transactions due to its associated fees. We were able to look up the BTC wallet address they provided for victims (bc1ql5f3m75qx3ueu2pz5eeveyqsw6pdjs3ufk8r20) and confirm that three transactions were made to that address, summing up to $1,477,872.41.
Figure 9 HelloKitty chats.
The samples found primarily made use of different combinations of the arguments described in Table 1.
Argument
Description
Value(s)
v
Verbose mode
0 or 1
d
Run the process as a daemon
0 or 1
e
When the flag is set, the ransomware only encrypts files with the extensions .vmdk, .vmx, .vmsd and .vmsn
It is not set by default, which means that all files under the start path that don’t match certain ransomware-specific file extensions will be encrypted
0 or 1
k
When this flag is set, the ransomware tries to kill VMs running on the host using the esxcli tool.
It is not set by default
0 or 1
m
Mode
5 (default) or 10 or 20 or 25 or 33 or 50
c
(Unsure of purpose)
Table 1. Arguments accepted by the Linux HelloKitty ransomware.
The following esxcli commands are executed to kill running VMs, when the k flag is set:
esxcli vm process list esxcli vm process kill -t=soft -w=%d %(PID) esxcli vm process kill -t=force -w=%d %(PID)
The malware samples log their output to a work.log file in their execution path.
Finally, the ransomware makes use of the Elliptic Curve Digital Signature Algorithm (ECDSA) for encrypting files using functions from the shared library libcrypto.so for encryption. The encrypted file is saved with the extension .crypt. Each encrypted file has a corresponding file with the extension .README_TO_RESTORE containing the ransom note. Additional details can be found in the appendix of this report.
LockBit 2.0
LockBit is another ransomware group that follows the RaaS model. According to their website, this ransomware affiliate program has been active since September 2019. While LockBit has been known for some time, we included this group in this blog because of their recent evolution to LockBit 2.0. In June 2021, the operators behind this ransomware revamped their site and rebranded as LockBit 2.0.
Since June 2021, they have compromised 52 organizations in accounting ,automotive, consulting, engineering, finance, high tech, hospitality, insurance, law enforcement,l egal services, manufacturing, non-profit energy, retail, transportation and logistics industries, utilities in the following countries: Argentina, Australia, Austria, Belgium, Brazil, Germany, Italy, Malaysia, Mexico, Romania, Switzerland, the U.K. and the U.S. All the posts by the threat actors on their leak site include a countdown until confidential information is released to the public, which creates additional pressure on the victim (Figure 10).
Figure 10. Affiliation program description (left) and leak site (right).
The threat actors behind this ransomware claim that their current variant is the fastest encryption software in operation. To attract more affiliates, they include a table comparing different ransomware families, including their previous variant (Figure 11).
Figure 11. Encryption speeds comparison released by LockBit.
When LockBit is executed, it starts encrypting files and appends the .lockbit extension. Additionally, the ransomware changes the icon of the encrypted file to the LockBit 2.0 logo (Figure 12.b). After encryption is complete, LockBit then drops the ransom note titled, Restore-My-Files.txt (Figure 12.a).
Similar to REvil, LockBit 2.0 ransomware modifies the victim’s desktop wallpaper if the encryption process is successful, making the victim aware of their compromise. The wallpaper also includes an advertisement aimed at encouraging insider threats that all organizations could fall prey to. (Figure 13).
Figure 13. Modified LockBit 2.0 wallpaper.
The advertisement states that the threat actors are interested in methods of access, such as RDP, VPN and corporate email credentials. In exchange, they offer a cut of paid ransom.
If the victim wants to communicate with Lockbit operators to get their data back, the operators include a “Decryption ID” and a TOR link (and their clearnet mirror: decoding[.]at) on the ransom note. This information allows the user to log in and start the negotiation process (Figure 14).
Figure 14. Support site login (left) and LockBit Support chat (right).
Conclusion
With major ransomware groups such as REvil and Darkside lying low or rebranding to evade law enforcement heat and media attention, new groups will emerge to replace the ones that are no longer actively targeting victims. Here, we shared information on some of the observed malicious activity of the ransomware groups trying to become the next key players. While LockBit and HelloKitty have been previously active, their recent evolution makes them a good example of how old groups can re-emerge and remain persistent threats. Unit 42 will continue to monitor these ransomware families – and new ones that may emerge in the future.
Palo Alto Networks customers are protected against these ransomware families with Cortex XDR or the Next-Generation Firewall with Threat Prevention and WildFire security subscriptions. Customers can use AutoFocus for tracking related entities using the AvosLocker, Hive, LockBit and HelloKitty tags, respectively. Full visualization of the techniques observed can be seen in the Unit 42 ATOM viewer.
Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and systematically disrupt malicious cyber actors. Visit the Cyber Threat Alliance for more information.
If you think you may have been impacted by any of these ransomware families, please email unit42-investigations@paloaltonetworks.com or call (866) 486-4842 – (866) 4-UNIT42 – for U.S. toll-free; (31-20) 299-3130 in EMEA; or (65) 6983-8730 in JAPAC. The Unit 42 Incident Response team is available 24/7/365. You can also take preventative steps by requesting a Ransomware Readiness Assessment.
Organizations are facing an increase in obfuscation behavior from on-site and remote employees attempting to bypass proxy servers to hide their online activities or exfiltrate data without detection. For example, an employee might use the “incognito” mode, download a personal virtual private network (VPN) or the Tor browser, or bypass the corporate VPN. In those cases, the information security team (InfoSec) needs complete network visibility to determine if that employee is solely guarding their own privacy, masking behavior that breaks organization policies or attempting to cover an attack.
Personal VPN services promise to enable secure, encrypted tunnels for user traffic. They provide services that prevent others from seeing through these tunnels by encrypting the internet connection and keeping users' application usage and browsing history private. VPNs may be used to bypass internet censorship and traffic policy enforcement. However, in practice, they obscure organizations’ visibility into networks.
Network visibility is important for a variety of reasons, including improved security by policy enforcement, a decrease in shadow IT, and speedy detection of malicious or suspicious activities. It can enhance application profiling for organizations and aid in well-informed decision-making.
Organizations often use tools such as Palo Alto Networks Next-Generation Firewalls to gain immense visibility into network traffic. Enterprises may attempt to obtain visibility down to the packet, application and user level.
Here, we assess personal VPN applications and their risk and threats to network visibility within organizations. We will touch on how these applications and services evade firewalls to bypass security and policy enforcement mechanisms.
Palo Alto Networks customers can maintain complete network visibility through the use of the Next-Generation FirewallApp-ID, which assists in the identification and sanitization of personal VPNs in networks.
Using Personal VPN on Corporate Networks: Key Risks
VPNs enable users to access network resources that may remain inaccessible otherwise. VPNs were developed to allow companies in different locations to connect their internal networks via encrypted channels through the internet. They are commonly used in workplaces to provide access to assets and devices for users who are not physically connected to a corporate network, such as remote workers. However, VPNs are now readily available to everyone – in some cases, free of charge. Nonetheless, average users often don't consider the risks of using personal VPNs on company devices.
Concerning data security and privacy with VPNs, in most cases, users have to simply trust their VPN providers, since providers operate the network tunnel. Moreover, providers can see which websites the user visits, including non-encrypted data, and the frequency of their visits. This data can be stored; some of it is valuable to advertising and marketing firms that use surfing behaviour to deliver ads to the right target audience. VPN providers could double-dip users and businesses by taking subscription money from users and selling users' web consumption data to the advertising industry. In more extreme cases, they might even supply user data to government authorities.
Using personal VPNs can introduce risks to networks. These risks involve threats that InfoSec teams mitigate in corporate environments via a defense-in-depth strategy to protect endpoints and prevent users from performing specific unauthorized tasks, either deliberately or accidentally.
Attackers constantly scan for vulnerable networks to compromise. If attackers succeed at compromising even one computer from an organization, the entire network could be at risk. Organizations use their domain name systems (DNS), enterprise data loss prevention (DLP), and proxy servers as countermeasures, each of which plays an important role in protecting users, data and communications. Circumventing any of those decreases network visibility and endangers the organization.
One of the primary uses of proxy servers is to prevent employees' access to browsing inappropriate and unsafe sites and monitor traffic. In addition, proxy servers protect corporate endpoints from communication with malicious command and control (C2) servers. However, through VPNs, users can bypass this protection. For example, if an employee's computer gets infected while using a VPN, the data sent to the C2 server will not be visible to the InfoSec team.
Insider threats pose almost as significant a risk to enterprise security as external intruders. Private or personal VPNs allow employees to bypass security measures and permissions that the InfoSec team put in place. VPNs can leave online activities vulnerable to hackers. In addition, the IT team loses its complete visibility into users' activities – for example, they hide when users browse unsafe or forbidden sites.
Known VPN Vulnerabilities
Not only does the underlying functionality of VPN products bring risks to the organization, but also, these products are often targeted by advanced persistent threats (APTs) due to their vulnerabilities. Unfortunately, cybercriminals all too often find ways to exploit known and patched vulnerabilities, banking on not all users having kept their patches up to date.
We took a list of the best VPN products of 2021 according to PC Magazine and checked the number of known vulnerabilities they have had in the past few years, as seen in Table 1.
Name
Number of Vulnerabilities
Vuln ID
Highest CVSS Severity
Private Internet Access VPN
12
CVE-2020-15590
CVE-2019-12579
CVE-2019-12578
CVE-2019-12577
CVE-2019-12576
CVE-2019-12575
CVE-2019-12574
CVE-2019-12573
CVE-2019-12571
CVE-2019-12572
CVE-2018-10190
CVE-2017-15882
V3.0: 7.8 HIGH
V2.0: 9.3 HIGH
NordVPN
3
CVE-2018-3952
CVE-2018-10170
CVE-2018-9105
V3.0: 9.8 CRITICAL
V2.0: 10.0 HIGH
IVPN
3
CVE-2020-7043
CVE-2020-7042
CVE-2020-7041
V3.1: 9.1 CRITICAL
V2.0: 6.4 MEDIUM
ExpressVPN
2
CVE-2020-29238
CVE-2018-15490
V3.1: 7.5 HIGH
V2.0: 5.0 MEDIUM
ProtonVPN
2
CVE-2018-4010
CVE-2018-10169
V3.0: 9.8 CRITICAL
V2.0: 10.0 HIGH
Hotspot Shield VPN
2
CVE-2020-17365
CVE-2018-6460
V3.1: 7.8 HIGH
V2.0: 7.2 HIGH
CyberGhost VPN
1
CVE-2018-10646
V3.0: 7.8 HIGH
V2.0: 7.2 HIGH
TunnelBear VPN
1
CVE-2018-10381
V3.0: 9.8 CRITICAL
V2.0: 10.0 HIGH
Table 1. Best VPN products of 2021 according to PC magazine, the number of known vulnerabilities in those services, and information on CVEs and severity.
How Do VPN Applications Try to Evade Firewalls?
Given that they can introduce vulnerabilities into an organization's network, it's concerning that the function of VPN applications includes trying to evade firewalls. VPNs cannot make online connections completely anonymous; however, VPNs typically tunnel into other protocols and use encryption techniques. VPN service providers can use secure VPN protocols such as Internet Protocol Security (IPsec), Transport Layer Security (SSL/TLS), Datagram Transport Layer Security (DTLS), Microsoft Point-to-Point Encryption (MPPE), Microsoft Secure Socket Tunneling Protocol (SSTP), Secure Shell VPN (SSH/OpenSSH), OpenVPN and WireGuard. However, these are all secure and well-defined protocols for legitimate use of VPNs, which comes with a disadvantage for personal VPN service providers. Because these are all known protocols, they can easily be blocked by organizations or governments. This poses a contradiction with the VPN provider's promise to their customer, which is 100% secure connectivity and availability.
VPN providers do their best to remain undetectable in the network, leveraging methods such as switching ports or servers or hopping from protocols. For example, VPN services that are based on OpenVPN give their users the option to change the transport protocol to Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). However, the demand for remaining undetected while maintaining full availability to serve customers goes further than that. Some VPN companies design their proprietary protocols precisely for circumventing organization or government blocks.
In this section, we review the evasion techniques that are used by some VPN products.
Self-Signed Certificate
Figure 1 illustrates how Hotspot Shield uses a bogus self-signed certificate to evade firewalls with its traffic. However, It can be identified with methods such as examining TLS Cipher Suite information, port number and observation of a pattern that is different from the genuine certificate.
Figure 1. Hotspot Shield uses a bogus self-signed certificate to evade firewalls.
“Tunnel Into HTTP Traffic”
Some VPN applications try to traverse firewalls by sending traffic that appears to be simple HTTP traffic. However, with close inspection, their characteristics can be identified, such as authentication header or encoding, HTTP request method or port number, along with other distinct information in the request headers. These can be used to identify such applications.
Figure 2 shows that SetupVPN, which has over two million users, uses the HTTP proxy-authorization header to authenticate users to its server. Deciphering the header presents helpful information about the SetupVPN application.
Figure 2. SetupVPN uses an HTTP Proxy-authorization header to authenticate users to its server.
Mimicking Common Protocols
VPN applications send traffic using well-known ports for their communication to evade firewalls and cause misidentification of the firewall implementation to pass through firewalls. For instance, with over 10 million users, Thunder VPN uses UDP port 53, known for its use for DNS, and TCP port 443, known for its use for the HTTP protocol over TLS/SSL.
Figure 3. Thunder VPN mimics SSL traffic by utilizing the port and the handshake type.
The above figure shows that the traffic on port 443 sent by Thunder VPN was misidentified as SSL in Wireshark. Thunder VPN mimics SSL traffic by utilizing the same port and handshake type.
Thunder VPN also uses port 53 to evade traffic using default DNS ports that are generally allowed in all networks. In addition, the DNS reserved flag Z is set to 1, which must be zero in all DNS queries and responses in the traffic originated by this application. The UDP traffic on port 53 sent by Thunder VPN is as shown in Figure 4.
Figure 4. Thunder VPN UDP traffic on port 53 with DNS reserved flag Z is set to 1.
Conclusion
With the rise of remote work as adopted by most corporations these days, network security teams should recognize the potential threats presented by personal VPN usage and adjust security policies accordingly.
The Palo Alto Networks App-ID technology provides customers with the ability to control applications and protocols in their networks. It allows information and network security teams to securely enable applications through policies that allow or deny applications contextually. This helps keep the attack surface as small as possible.
App-ID, which is now running on the Palo Alto Networks Next-Generation Firewall, can grant visibility into VPN apps and their underlying protocols in your network, including all the protocols mentioned in this article. App-ID can help security teams see who uses VPN applications in your entire network – as well as when and where – and enforce policies chosen by your organization. Currently, App-ID covers more than 70 of the most popular VPN services.
The App-ID team constantly reviews and releases updates for the latest versions of VPN applications to its customers. Due to the nature of these applications, their traffic changes frequently to evade firewalls.
Unit 42 researchers have been observing various malicious campaigns abusing either legitimate challenge and response services (such as Google’s reCAPTCHA) or deploying customized fake CAPTCHA-like validation. Recent security blogs on phishing campaigns and cybercriminals using reCAPTCHA and research papers like PhishTime and CrawlPhish show an increasing trend of CAPTCHA-protected phishing pages. Hiding phishing content behind CAPTCHAs prevents security crawlers from detecting malicious content and adds a legitimate look to phishing login pages.
In this blog, we show techniques to detect malicious content with security crawlers even in the presence of CAPTCHA evasion. In some cases, these techniques can even track and detect such campaigns. We see many malicious campaigns reuse CAPTCHA service keys, either to simplify their malware infrastructure or to avoid being blocked by the legitimate reCAPTCHA provider for creating too many CAPTCHA accounts and keys.
Our research paper “Betrayed by your Dashboard” (published in 2018 at TheWebConf) shows that web analytics IDs can be used to identify large-scale malicious campaigns, as attackers often use legitimate web analytics services. Here, we show how similar pipelines can be used to detect phishing pages through the association of CAPTCHA keys.
Looking at the top 10 most popular malicious CAPTCHA keys across broad phishing campaigns just over the last month, we blocked 7,572 unique URLs over 4,088 pay-level domains, protecting our customers from visiting them at least 202,872 times. At the same time, we see that such URLs are slower in appearing in third-party malicious feeds, presumably because of hidden phishing, scam and other malicious content.
At Palo Alto Networks, we focus on how we can detect and track malicious campaigns across various domains and URLs.
Phishing Example for Apple ID Credentials
Let’s look at the example (hxxp://utem[.]com/[.]YSou8XI) of a long-running phishing campaign that we have been monitoring since July 2020. It has been pushing phishing pages and targeting Microsoft Outlook, Apple and other login pages. Users see the following CAPTCHA challenge when they visit the page.
Figure 1. CAPTCHA challenge.
After solving a standard reCAPTCHA challenge, the browser will see a classic phishing page, shown in Figure 2 below. In this example, phishing content was generated dynamically on the same page, but more often a top-level redirection occurs.
Figure 2. Phishing page.
However, on the main page (before solving the CAPTCHA challenge), we observe the following sub-requests, which reveals the reCAPTCHA API key used in the URL parameters:
Figure 3. The sub-requests shown reveal the reCAPTCHA API key used in the URL parameters.
Such identifiers can be parsed out and searched for on other pages, which gives us the ability to find other phishing pages. For example, a webpage using the same ID was pushing Apple ID phishing too.
Figure 4. Phishing for Apple ID credentials.
Alternatively, CAPTCHA keys can be extracted from HTML. The example shown below was used in another recent Outlook phishing campaign:
Figure 5. HTML from a recent Outlook phishing campaign.
Such CAPTCHA keys are a strong signal for detecting malicious pages even without getting phishing content. Moreover, malicious CAPTCHA keys can be mined automatically using similar ground truth data and filtering pipelines, which were presented in the paper Betrayed by Your Dashboard: Discovering Malicious Campaigns via Web Analytics. However, we noticed that such sophisticated malicious pages are slow to appear in third-party malware and phishing feeds. As such, manually verified ground truth data gives more useful CAPTCHA keys or clustered CAPTCHA keys from an unlabeled feed of URLs.
Microsoft Phishing Example
Here we see op[.]g2yu-bere[.]xyz/?e=c2Nhc2VAY2l0Y28uY29t, where an attacker is attempting to phish for Microsoft account credentials. The CAPTCHA challenge makes it seem legitimate for both the users and security scanners. After the user solves the CAPTCHA, the attacker attempts to phish Office 365 credentials from the user.
Figure 6. Phishing page protected by CAPTCHA.
Is It Only About Phishing?
In addition to various phishing campaigns, beginning in October 2020 we started to observe more scam campaigns and malicious gateways using CAPTCHA evasion. Often, they show CAPTCHA challenges only if they suspect automation with other means (for example, based on IP and browser versions).
Grayware Campaigns
Another category of malicious pages protected by CAPTCHA is grayware. Survey and lottery scams are some of the most common grayware pages. In exchange for a fake payment or chance at winning the lottery, the user is lured into disclosing sensitive information, including address, date of birth, banking information, annual income, etc.
Figure 7. Survey scam examples.
Below is another example of a lottery scam page (win[.]click2win4life[.].com/api/offer) that uses CAPTCHA evasion with ID 6LfKnxEUAAAAAO1iXBX9FqL0w-68XqXGl3UPBF5p and attempts to collect user information.
Figure 8. Lottery scam examples.
Malware Delivery
We have seen recent examples of malware delivery pages abusing legitimate CAPTCHA services. For example, the URL hxxps://davidemoscato[.]com serves a malicious JAR file (PayeeAdvice_IN00231_Q1626801_32843.jar) that is hidden from security scanners by protecting the page with a CAPTCHA challenge.
Figure 9. Malware page protected by CAPTCHA.
Efficacy of CAPTCHA Signatures
We present the statistics of the 10 most popular malicious CAPTCHA IDs in a one-month period (April 18-May 18). The graph below shows the number of new detections per day for each ID. We see that on a daily average, 529 new URLs are found to use such malicious IDs. We received a total of 7,572 unique URLs from these top 10 IDs in a 30-day period.
Figure 10. Daily detections of top 10 IDs in 30 days (April 18 - May 18).
We ranked their popularity using the number of unique detections per day. Because we see that attackers use these IDs for a long time – more than 250 days in some cases – they are robust indicators of malicious activity.
ID Live Days:
CAPTCHA ID
Unique 30 day detections
Avg detections / day
ID live (days)
6LcEthAUAAAAANLeILVZiZpPDbVwyoQuQ7c3qlsy
3,290
228
264
6LcJK64UAAAAAKwjDYyWpakQ_5aFAb34tK-EkiDA
2,094
87
287
6Le-dsYUAAAAABJa32oIuo9LEPsur7OcBz-a9kyL
1,132
42
294
6LfKnxEUAAAAAO1iXBX9FqL0w-68XqXGl3UPBF5p
1,021
39
238
6Lc8-cQUAAAAAF60sMK0PjhPOA6ciyzy6cfnGcl0
784
38
294
6LeihuEUAAAAAEgMRhYQKQCxnJvsqIZnRghJAPcH
222
42
182
6LezpHMUAAAAALunasQAvKdhRwFC1oqRE0OZW8f4
216
23
295
6LdkVo0aAAAAAN5yxjGbJPH39rF--s6ZVsl_LxzE
201
10
43
6LdVFrgUAAAAAEMNq1ljl8HZSQ2sA8Hu6a8umPQr
191
7
287
6LfrPbMUAAAAAF2DLXNWH8-s0Ln08lXtaX9k1tRC
152
13
294
Table 1. Top 10 CAPTCHA IDs ranked by 30-day unique detections count.
It is also interesting to note that the three top-ranked CAPTCHA IDs alone account for 70% of the detections.
Figure 11. Cumulative detections ordered by popularity of CAPTCHA ID.
Impact of Detections
Let’s look at the impact these detections have on our customers. For the same 30-day timeframe, we observe that our customers attempted to visit these pages at least 202,872 times. The graph below shows the number of visits to the 10 most popular malicious URLs. Six of them belong to grayware, and four belong to malware categories. The grayware page that collects user information for a chance at the lottery (win[.]omgsweeps[.]info) accounts for 51% of the customer visits to these malicious pages.
Figure 12. Top 10 most visited malicious URLs by customers.
Other Detection Methods
We observe that CAPTCHA IDs are often not the only signal in the detected sites. In addition to the IDs, we can use some other methods to detect these malicious sites.
Static URL analysis: In some instances, we can identify malicious sites just by looking at the URL. Many campaigns reuse similar URL patterns, related domains, IPs or other signals. Based on previous examples seen with the same pattern as the URL, runswift-besthighlyfile[.]best/ZW2RR5af4KcKjjWeJS2qTOgg92QyTjh7NL0_4Yv8R98, we can mark it malicious.
Traffic analysis: In a few cases, we can look into the HTML traffic for malicious activity. For example, the malicious page, https:/syans2008[.]3dn[.]ru/news/barbi_princessa_rapuncel_skachat_igru/2013-10-23-1705, can be detected with the CAPTCHA ID, 6LcpAwsUAAAAAPif4MyLJQVv7r5Nr1Wv31NB86C6, or with the YARA rule below.
When simulating client-side behavior, we observe the HTML traffic with (SHA256: 781e16b89604cdcd37928009920654628cc95f6e1b34916fd47b880ff3c7cc92) that the page havnsardf[.]ga loads. The YARA rule above can uncover many cases of malicious JavaScript injections or downloads. This execution behavior is usually seen in situations in which attackers have taken over a web server and intend to inject malicious JavaScript from their servers into the victim web server.
Using content analysis: In some cases, malicious phishing content is already present in the HTML, but just not shown, or a custom/fake CAPTCHA is used. Such pages are usually JavaScript-rich, and detectable with malicious JavaScript analysis used at Palo Alto Networks. For example, the malicious site, yourstorecentre[.]com, protected by CAPTCHA ID, 6LcA2tEZAAAAAJj7FTYTF9cZ4NL3ShgBCBfkWov0, contains the malicious JS with SHA256: 68687db7ae5029f534809e3a41f288ec4e2718c0bbdefdf45ad6575b69fed823, which is shown to be malicious when analyzed.
Finally, the simplicity of making detections with CAPTCHA signatures has the benefit of being early in newer detections. For example, if we look up the site, lowautocasion[.]es, on third-party vendor feeds, it remained undetected by many standard methods until July 7, but was detected as malware by Palo Alto Networks Advanced URL Filtering using CAPTCHA signatures as early as May 18.
Conclusion
Mass phishing and grayware campaigns have become more sophisticated, using evasion techniques to escape detection by automated security crawlers. Fortunately, when malicious actors use infrastructure, services or tools across their ecosystem of malicious websites, we have a chance to leverage these indicators against them. CAPTCHA identifiers are one great example of such detection by association.
Palo Alto Networks continually monitors CAPTCHA IDs as one example of a malicious indicator, and we use it to detect phishing, malware and grayware pages. Palo Alto Networks Next-Generation Firewall customers with Advanced URL Filtering andWildFire security subscriptions are protected against such sophisticated phishing campaigns.
Signatures
Below is the list of top 10 popular Captcha ID signatures for the period April 18-May 18. 6LcEthAUAAAAANLeILVZiZpPDbVwyoQuQ7c3qlsy 6LcJK64UAAAAAKwjDYyWpakQ_5aFAb34tK-EkiDA 6Le-dsYUAAAAABJa32oIuo9LEPsur7OcBz-a9kyL 6LfKnxEUAAAAAO1iXBX9FqL0w-68XqXGl3UPBF5p 6Lc8-cQUAAAAAF60sMK0PjhPOA6ciyzy6cfnGcl0 6LeihuEUAAAAAEgMRhYQKQCxnJvsqIZnRghJAPcH 6LezpHMUAAAAALunasQAvKdhRwFC1oqRE0OZW8f4 6LdkVo0aAAAAAN5yxjGbJPH39rF--s6ZVsl_LxzE 6LdVFrgUAAAAAEMNq1ljl8HZSQ2sA8Hu6a8umPQr 6LfrPbMUAAAAAF2DLXNWH8-s0Ln08lXtaX9k1tRC
We’d like to thank Unit 42 for helping us with this blog. Special thanks to Bahman Rostamyazdi, David Fuertes, Taojie Wang, Tao Yan and Hector Debuc for helping us with the data.
Unit 42 researchers have discovered a new variant of eCh0raix ransomware targeting Synology network-attached storage (NAS) and Quality Network Appliance Provider (QNAP) NAS devices. To achieve this, attackers are also leveraging CVE-2021-28799 to deliver the new eCh0raix ransomware variant to QNAP devices. While eCh0raix is known ransomware that has historically targeted QNAP and Synology NAS devices in separate campaigns, this new variant is the first time we’ve seen it combining functionality to target both QNAP and Synology NAS devices, demonstrating that some ransomware developers are continuing to invest in optimizing the tools used to target devices common in the small office and home office (SOHO).
We’re regularly seeing attacks with the eCh0raix ransomware variant, which has been active in the wild for nearly a year. As recently as June, victims have reported paying a modest ransom.
We’re releasing our findings about this new variant of eCh0raix to raise awareness of the ongoing threats to the SOHO and small business sectors. Coverage of the ransomware crisis tends to focus on threats to large enterprises and government agencies, which are facing increasingly aggressive and disruptive ransomware attacks. However, the SOHO and small business sectors can contain a large attack surface for threat actors – for example, some 250,000 QNAP and Synology NAS devices are exposed to the public internet, according to data from the Cortex Xpanse platform.
SOHO users are attractive to ransomware operators looking to attack bigger targets because attackers can potentially use SOHO NAS devices as a stepping stone in supply chain attacks on large enterprises that can generate huge ransoms.
Additionally, SOHO users typically do not employ dedicated IT or security professionals, which makes them less prepared to block ransomware attacks than larger organizations.
We recommend the following best practices for protecting home offices from ransomware attacks:
Update device firmware to keep attacks of this nature at bay. Details about updating QNAP NAS devices against CVE-2021-28799 can be found on the QNAP website.
Create complex login passwords to make brute-forcing more difficult for attackers.
Limit connections to SOHO connected devices from only a hard-coded list of recognized IPs to prevent network attacks that are used to deliver ransomware to devices.
On April 22, QNAP released a security advisory to disclose a vulnerability within their Hybrid Backup Sync (HBS 3) software. This software provides backup, restoration and synchronization functions between local, remote and cloud storage spaces. The vulnerability has been confirmed as an improper authorization vulnerability. Once exploited, it allows remote attackers to log in to the devices. CVE-2021-28799 is assigned to this vulnerability.
On June 21, we caught an attack targeting QNAP HBS3 with an exploit of CVE-2021-28799. While this vulnerability has been exploited to deliver QLocker in the past, this is the first instance we know of in which it is being exploited to deliver eCh0raix (also known as QNAPCrypt) ransomware. The payload of the malicious request is shown in Figure 1. The attack tried to utilize a hard-coded session ID "jisoosocoolhbsmgnt" to bypass authentication and execute a command on the device, aiming to fetch malware from the remote server 64[.]42[.]152[.]46 and run it on the victim device. The payload is still live at the time of this writing.
Figure 1. CVE-2021-28799 exploit.
While eCh0raix has historically targeted QNAP devices, further analysis of the payload led to the discovery that this is a new variant of the ransomware that also targets Synology devices, thereby increasing its attack surface.
Timeline of the New eCh0raix Ransomware Variant
To the best of our knowledge, details on the eCh0raix ransomware samples targeting these Synology devices were unknown until now. Instances of Synology devices infected by eCh0raix have been reported from as far back as 2019, but the only previous research connecting the Synology attacks to eCh0raix actors is based on decryptors that were found.
The first sample we saw of this new ransomware variant combining functionality to target both QNAP and Synology devices is from September 2020. It’s possible that is when the combined variant was authored. Before then, the attackers likely had separate codebases for campaigns targeting devices from each of the vendors. This is also confirmed by the use of rct_cryptor_universal as the project name in the new variant, going by the compilation paths present in GoLang binaries (/home/dev/GoglandProjects/src/rct_cryptor_universal). Prior samples of eCh0raix use the project name qnap_crypt_worker.
We observed other eCh0raix samples between June and September 2020 using the rct_cryptor_universal project name, but the first full-blown sample with two separate code flows, based on a syno flag (explained below), is from September 2020.
Going by posts from victims in forums, it appears the eCh0raix ransomware is quite active. The attackers have found success extorting ransom out of victims, an example of which can be seen on BleepingComputer.com, where the ransom was paid as recently as June 16, 2021.
Querying Cortex Xpanse for NAS devices gives us a rough estimate of the number of devices from each vendor connected to the internet (i.e. the attack surface for this ransomware). Xpanse tells us there are approximately 240,000 internet-connected QNAP NAS devices. In contrast, Xpanse found approximately 3,500 Synology NAS devices – a much smaller number. This tells us the additional target doesn’t significantly increase the ransomware’s attack surface.
Technical Analysis
The new variant accepts an additional syno flag as an input parameter. The two accepted flags are explained below in Table 1.
Flag Name
Description
Significance
s
start path
A string value that determines the path on the targeted device where the ransomware encrypts files. The default value is “/”. The exploit we observed in the wild specified this value as “/share/” (see Figure 1). This value is also ignored if the syno flag is set, in which case the start path value is a hardcoded list of paths.
syno
is syno?
This is a Boolean value accepted by this new variant. By default, it is not set, but if explicitly set using the syno input parameter, a hardcoded path is used for encrypting files. The hardcoded path used is /volume[X] (where X takes on values from 0 to 9). This essentially means that the ransomware tries to encrypt the first 10 numbered volumes on the device. This aligns with the name of the flag syno since Synology NAS devices specifically store their data under volumes.
Table 1. Input arguments supported by the new variant.
CheckIsRunning: After launch, the ransomware first checks whether another instance of the process is already running. This is done by checking for a [SampleName].pid file in the temporary directory on the system. The temporary directory location is determined either by the value of the TMPDIR environment variable, or /tmp is used if the environment variable is not set. If found, the ransomware tries to read an integer value from this file and kill the corresponding process ID on the system. If it fails to kill the existing process, it prints a message: “Program is running. Exiting…” and exits. If no existing running process is found, or the ransomware succeeds at killing a previously running process, it initializes the .pid file in the temporary directory with the value of its own process ID.
checkReadmeExists: Next, the binary checks for the presence of a ransom note file. In the original variant, this file was named README_FOR_DECRYPT.txt. However, this new variant uses the filename README_FOR_DECRYPT.txtt (with the extra trailing ‘t’). Perhaps the typo is an easy way for the attackers to distinguish between campaigns. This thread in the QNAP user forum starting March 21, 2021, shows this new variant has been active and contains victims’ accounts from instances of successful infection.
If this file already exists on the device, the binary exits.
getInfo: If a preexisting ransom note file is not found and program execution continues, the ransomware attempts to connect to a Tor URL via a hard-coded SOCKS proxy – see Indicators of Compromise (IoCs) below. This URL serves as the command and control (C2) server and returns a JSON object containing:
The AES key used to encrypt files on the system.
The ransom note.
A Bitcoin address that is included in the ransom note.
We managed to find one of the C2 URLs still live, which returned a response with the JSON object described above, as seen in Figure 2.
Figure 2. C2 response.
An interesting thing to note is that the new variant uses a different URL format for communicating with the C2 using an API key, instead of using Campaign ID numbers as the previous variant did (see Table 3 for variant comparison).
If the sample fails to connect to the C2 or receive a meaningful response, it exits with the rather amusing log message, “AES public key not set!” (AES is a symmetric encryption algorithm, thus the concept of public or private keys is moot in this case.)
main: Following all these steps, the ransomware iterates through the list of files at a path determined by the flag values (syno and s) explained in Table 1. Any files in this path containing the following strings are ignored:
/proc
/boot/
/sys/
/run/
/dev/
/etc/
/home/httpd
/mnt/ext/opt
.system/thumbnail
.system/opt
.config
.qpkg
/usr/syno
/tmp
/volume1/@appstore/PhotoStation
.@analytic
qnapSystem.php
README_FOR_DECRYPT.txtt
.@backup_config
.antivirus
.ldapdb
.@backup_qbox
.appDB
.locks
.@backup_qfiling
.idmap
.log
.@qmariadb
.php_session_sys
.qbox
Table 2. Files excluded from encryption.
The encryption algorithm used is the same as that used by the original variant (AES CFB), and the same extension (.encrypt)is appended to encrypted files, with the eCh0raix string used as a marker in the files to verify successful decryption by decryptors. However, this new variant doesn’t generate the AES key locally, but rather receives it directly from the C2.
The new variant also implements encryption in two stages based on file extensions. The ransomware first iterates through files with the following 42 extensions and encrypts them:
We hypothesize that this is a higher-priority subset of extensions focusing on data that would be of value to the average user. Thus, it is more likely for the ransom to be paid to recover this data. These extensions are likely encrypted first to prioritize valuable data in case the ransomware fails to complete its encryption process.
After the encryption of files with the first set of extensions, files matching a longer list of 530 unique file extensions are encrypted. These are included in the appendix. We noticed the .docx extension is included on both lists, so those files would get encrypted twice.
The original variant targeted a total of 563 unique extensions, all encrypted as part of the same routine (also included in the appendix).
Encryption is carried out in two steps, focusing on a short list of higher priority extensions first.
AES Encryption Key received from C2
42+530 unique file extensions targeted.
Encryption carried out in one go.
AES Encryption Key generated locally
563 unique file extensions targeted.
Saves ransomware PID in a temporary directory?
Yes
No
Kills certain running processes?
No
Yes
Table 3. Variant comparison.
Conclusion
The discussion of this new variant of eCh0raix ransomware provides an example of the ongoing threats to the SOHO and small business sectors. These sectors represent a large attack surface for threat actors – for example, some 250,000 QNAP and Synology NAS devices are exposed to the public internet, according to data from the Cortex Xpanse platform.
SOHO users are attractive to ransomware operators looking to attack bigger targets because attackers can potentially use SOHO NAS devices as a stepping stone in supply chain attacks on large enterprises that can generate huge ransoms.
Additionally, SOHO users typically do not employ dedicated IT or security professionals, which makes them less prepared to block ransomware attacks than larger organizations.
We recommend the following best practices for protecting home offices from ransomware attacks:
Update device firmware to keep attacks of this nature at bay. Details about updating QNAP NAS devices against CVE-2021-28799 can be found on the QNAP website.
Create complex login passwords to make brute-forcing more difficult for attackers.
Limit connections to SOHO connected devices from only a hard-coded list of recognized IPs to prevent network attacks that are used to deliver ransomware to devices.
Palo Alto Networks customers are protected from eCh0raix ransomware and CVE-2021-28799 by the following products and services:
Next-Generation Firewalls with a Threat Prevention security subscription can block the attacks with best practice via Threat Prevention signature 91323.
WildFire accurately detects and blocks these attacks.
Cortex Xpanse provides attack surface management for your connected assets.
Cloud environments are more susceptible to attacks today than they were at the end of last year, according to new research from Unit 42. We identified significant increases in the number of organizations that did not enable multi-factor authentication (MFA), failed to rotate access keys or used overly permissive service accounts in their instances with cloud service providers (CSPs). That puts those organizations at increased risk of experiencing a high-profile security incident caused by compromised identity and access management (IAM) accounts for CSP environments.
These findings supplement our Unit 42 Cloud Threat Report, 2H 2020. In that October 2020 report, we analyzed the security risks IAM misconfigurations can pose to cloud environments. We decided to follow up that research to see how trends have changed over the past eight months, particularly in light of the highly significant MFA ramifications of the SolarStorm attack and the Microsoft Exchange Server attacks.
It is important to note that our findings result from an organization’s misconfiguration of their respective CSP’s settings and are not the result of the services provided by the CSP.
Between January and June 2021, Unit 42 researchers found that cloud environments are more susceptible to attacks today than in October 2020. Most notably, researchers made additional discoveries, including:
A 60% increase in the number of organizations that configure Google Cloud storage buckets so they are accessible to all users, putting their data at higher risk.
A 42% increase in the number of organizations that did not enable MFA settings for root accounts on the Amazon Web Services (AWS) platform.
A 22% increase in the number of organizations using AWS, where access keys are not rotated for more than 90 days.
These findings (MFA disablement, no routine key rotation operations and the provisioning of over-privileged accounts) indicate the need for organizations to tighten their DevOps security operating procedures.
It is highly recommended that all organizations invest in cloud-native security platforms, such as Palo Alto Networks Prisma Cloud, to routinely monitor cloud environments for IAM misconfigurations both within production and development environments.
MFA Misconfigurations
The findings regarding those who do not enable MFA in cloud environments only pertain to a CSP’s native IAM capabilities and not those provided by a third-party identity provider (IdP). CSP root accounts present a critical security bottleneck in terms of an organization’s cloud IAM security. The CSP root account is the first account created within a cloud environment. It is an all-powerful account holding “the keys to the kingdom,” including allowing and managing any IdP configuration. This is important to point out, as a compromised CSP root account could circumvent any security measure put in place by an IdP.
It is a security best practice to configure the organization’s CSP root account with MFA to safeguard it, which includes the organization’s cloud environment itself. While there are instances where MFA can be bypassed (e.g. phishing attacks, insecure protocols and vulnerabilities), these types of attacks are incredibly costly for attackers. Microsoft found that the “[u]se of anything beyond the password significantly increases the costs for attackers, which is why the rate of compromise for accounts using any type of MFA is less than 0.1% of the general population.” According to IDC, 90% of enterprises will rely upon a cloud infrastructure to meet production requirements by 2022. To help secure that cloud infrastructure, following MFA best practices will help ensure organizations do not suffer avoidable identity security exposures.
MFA, also referred to as two-factor authentication (2FA), is the process of providing two or more forms of authentication before being granted access to an application. The three forms of authentication are:
Something you know.
Password.
Passphrase.
Something you have.
Hardware security key.
Software token application.
SMS token.
Something you are.
Biometric scan or iris scan.
Voice authentication.
When MFA is enabled and a user requests access to an application, the user will be required to successfully provide two or more authentication checks before being given access. This typically involves supplying a password (something you know) and entering a token value (something you have).
In the previously mentioned CTR, 2H 2020, Unit 42 researchers examined MFA misconfigurations where organizations had not properly enabled or configured MFA resources for their root and standard user accounts. Unfortunately, these statistics have worsened since October 2020, as shown in Table 1. An explanation for the downward trend in these numbers could be that it is due to organizations failing to properly configure user accounts, which may lie outside of their IdP platform. This means, for organizations that are using an IdP (e.g. Okta, Auth0, SailPoint or OneLogin), they may not have disabled those IAM accounts created within the cloud platform itself. This would include the IAM account that was used to establish the IdP integration.
Critical Misconfiguration
Oct. 2020
June 2021
Percentage Increase
Orgs using Oracle Cloud where MFA is disabled for IAM users
N/A
92%
N/A
Orgs using Alibaba Cloud where MFA is disabled for RAM* user
62%
85%
+27%
Orgs using AWS where MFA was not enabled for IAM users
47%
69%
+32%
Orgs using AWS where MFA was not enabled for root accounts
24%
42%
+42%
Table 1. Organizations not enabling MFA for IAM accounts. *RAM - Resource Access Management is the identity and access control service within the Alibaba cloud that enables users’ central management and their permissions.
Whereas Amazon Web Services (AWS), Oracle Cloud and Alibaba Cloud have incorporated the IAM authentication functionality within the cloud platform itself, Google Cloud and Microsoft Azure use their proprietary IdP services with their cloud platforms to perform IAM authentication. Google Cloud uses the proprietary Google Accounts service, and Azure uses Microsoft’s Azure Active Directory (AD) service. If organization administrators wish to enable MFA for their Google Cloud accounts, please refer to this Google Workspace guide. If organization administrators want to enable MFA for their Azure cloud accounts, please refer to this Azure AD Multi-Factor Authentication guide
Additional Misconfigurations
Diving into the IAM access key rotation findings, Unit 42 researchers found a roughly 20% global increase in cloud organizations failing to perform access key rotation operations between October 2020 and June 2021. This was found within organizations using Google Cloud and AWS platforms.
Much like passwords, new CSP access keys should be rotated every 90 days to ensure that they will not remain active for long periods if the keys are leaked or stolen. Access keys become compromised if they are accidentally uploaded to code repository sites such as GitLab or GitHub or placed on a cloud instance that later becomes compromised. As can be seen within Table 2, organizations using AWS, Google Cloud and Oracle Cloud platforms exhibited notable occurrences of long-lived access keys. (Each of the cloud providers offer access to configuration settings to protect the cloud infrastructure from this issue, though not all users enable them.)
Due to the increase in cloud demand and complexity paired with the overall low severity rating of long-lived credentials, it is likely that organizations are choosing to address other cloud development operations, such as on-prem to cloud migrations or application development, rather than addressing long-lived credential misconfigurations. However, access key rotation is one of the few use cases that presents an ever-increasing risk severity. The longer credentials remain unchanged and the more cloud infrastructures being built that use those credentials, the more damaging their exposure could be to the organization should those credentials become leaked.
Critical Misconfiguration
Oct. 2020
June 2021
Percentage Increase
Orgs using AWS where access keys are not rotated for 90+ days
68%
83%
+22%
Orgs using Google Cloud where account keys have not rotated for 90+ days
62%
73%
+18%
Orgs using Oracle Cloud where API keys have not rotated for 90+ days
N/A
85%
N/A
Orgs using Oracle Cloud where Auth Tokens have not rotated for 90+ days
N/A
19%
N/A
Table 2. Organizations not rotating access keys.
Each of the primary CSPs offers methodologies for automating the process of access key rotation. Please see the following links for more details: Alibaba Cloud, AWS, Azure, Google Cloud and Oracle Cloud.
Excessive Permissions
Finally, Unit 42 researchers revisited the likelihood of organizations with excessive permissions, which allowed for IAM accounts and roles. The most notable IAM excessive privilege issue centers around the misuse of the AWS AssumeRole functionality. (While AWS provides configurations to protect against AssumeRole misuse, not all users enable them.) This service has received a great deal of attention from both Unit 42 researchers and CSO Online industry best practice articles, and even SolarWinds has a tie into misconfigured AssumeRole services. Due to this level of attention, researchers are beginning to see a decrease in the number of organizations that are overly privileging AssumeRole configurations, which has decreased by 67% in just six months (see Table 3).
Critical Misconfiguration
Oct. 2020
June 2021
Percentage Increase/Decrease
Orgs using AWS where an IAM policy allows AssumeRole permission across all services
30%
18%
-67%
Orgs using Google Cloud where an IAM user has service account privileges
61%
62%
+2%
Orgs using Google Cloud where an account has overly permissive service account privileges
20%
24%
+17%
Orgs using Google Cloud where storage buckets are publicly accessible to all users
11%
27%
+60%
Table 3. Organizations allowing overly permissive IAM privileges.
While the reduction in over-privileged AWS AssumeRole services is good news, we believe it is time to switch our collective attention to correcting other IAM security concerns within other CSP environments. For example, this includes overly permissive IAM service accounts within Google Cloud environments, which have increased in frequency by 17%, as well as locking down publicly accessible Google Cloud storage resources, which have increased in frequency by a massive 60% over the last six months.
Conclusion
CSP root accounts pose a critical security risk to cloud environments. Providing proper security protection for these accounts should be an urgent priority for any organization operating in the cloud. Organizations improperly configuring and maintaining their cloud environments could experience grave consequences. Unit 42 researchers strongly recommend that organizations limit operational functionality from CSP root accounts to only configuring an IdP platform. The CSP root account should have MFA enabled, preferably via an MFA hard token, and that root account should never be used, except for emergencies. Any and all administrative functions must be performed through a newly designated IdP-based administrative account.
Unit 42 researchers also found an increase in the number of organizations not rotating their IAM access keys and the number of organizations deploying overly privileged IAM accounts and roles. Similar to rotating user passwords, access keys must be rotated at least every 90 days to maintain minimal risk. Finally, the principle of least-privilege should be applied when creating and maintaining all IAM entities, be they users, roles or group privileges. The critical IAM misconfigurations discussed can be detected and alerted on, out of the box, within Prisma Cloud. The platform allows organizations to maintain awareness of their cloud environment configurations, especially for those organizations using a multi-cloud setup.
Recommendations
Ensure that the CSP root account has MFA enabled, preferably with a hardware token.
Use the CSP’s root account to set up the IdP configuration and never use that root account for any other function.
Create an IAM administrative account configured through the IdP to perform all administrative functions.
Microsoft recently added additional security checks that address the Windows container escape that we discovered last year. This is the same escape that enabled Siloscape, the first known vulnerability targeting Windows containers, which we discovered earlier this year.
To address the issue, Microsoft focused on the key function that enabled the container escape, which prevents exploitation. Now, there will also be a check for whether the function is being called from inside a container. If so, it will be blocked. These new changes Microsoft introduced directly prevent Siloscape’s attack technique.
However, these security checks do not completely get rid of the risk of running Windows Server containers for certain purposes. As discussed in a previous blog, we do not recommend using Windows containers as a security feature, which is consistent with guidance from Microsoft.
Palo Alto Networks Prisma Cloud protects customers from Siloscape attacks. In addition, Prisma Cloud Compute will alert customers who have old versions of their hosts that are vulnerable to known CVEs.
Technical Overview of the Issue and the Patch
Recap of Windows Container Escape Technique
As covered in detail in previous posts, an attacker who wants to abuse this issue to create a symbolic link to the host’s drive, and escape the container, needs to call the undocumented function NtSetInformationSymbolicLink with the correct parameters. Such a call will make the attacker’s chosen symbolic link global, thus pointing to the host’s objects instead of the container’s objects. A global symbolic link from inside the container can point to the host's filesystem, registry or basically any named object under the Root Directory Object.
Figure 1. Execution flow of the container escape.
To successfully use NtSetInformationSymbolicLink the caller has to have SeTcbPrivilege privileges. The regular container’s user is indeed Administrator but doesn’t have the necessary privileges.
In order to obtain SeTcbPrivilege privileges an attacker can use the main container’s process, CExecSvc.exe, which has the relevant privileges. An attacker can use CExecSvc.exe’s context to gain its privileges in numerous ways, such as Thread Impersonation or good old DLL injection.
The Fix
Figure 2. NtSetInformationSymbolicLink before (left) and after (right) the patch.
The patch is easy to understand and straightforward. Any call to NtSetInformationSymbolicLink from a thread inside a container (server silo) will be blocked with the STATUS_PRIVILEGE_NOT_HELD error code. This is done using the PsIsCurrentThreadInServerSilo function, which, as its name suggests, checks whether the current thread is associated with a process inside a server silo.
Is My Kubernetes Cluster Protected?
Figure 3. A failed attempt to globalize a symbolic link on an updated Windows Server 2019 machine, using NtObjectManager.
Windows Server 2019 is the only Windows operating system supported by Kubernetes and was also included in the patch. All versions of Windows Server 2019, including the very first one, 1809, received the fix and are protected from this issue.
If you are using a cloud provider to host your Kubernetes cluster, make sure there are no pending updates for your nodes. On the other hand, if you are hosting your cluster on your own, make sure your nodes have the latest updates installed.
Conclusion
Although this fix provides great relief since it closes the known exploits in the wild, it does not completely get rid of the risk of running Windows Server containers for certain purposes. As discussed in my previous blog, users should follow Microsoft’s guidance recommending not to use Windows containers as a security feature. Microsoft recommends using strictly Hyper-V containers for anything that relies on containerization as a security boundary. Any process running in Windows Server containers should be assumed to have the same privileges as admin on the host, which in this case is the Kubernetes node. If you are running applications in Windows Server containers that need to be secured, we recommend moving these applications to Hyper-V containers.
Nevertheless, and even though containers will always be less secure than a real Virtual Machine with a separate kernel, this fix is a move in the right direction, helping to make Windows containers as secure as their Linux counterparts.
Palo Alto Networks Prisma Cloud protects customers from Siloscape attacks. In addition, Prisma Cloud Compute will alert customers who have old versions of their hosts that are vulnerable to known CVEs.
Figure 4. Choosing action for unexpected processes on Prisma Cloud.
Prisma Cloud’s Runtime Protection feature learns the machine’s behavior and creates a set of rules for processes. Once the learning is complete, the user can choose the action for new, unexpected processes attempting to execute. The user can choose to alert, prevent or completely block the execution.
Unit 42 recently shared information about a new attack surface targeting Microsoft Internet Information Services (IIS) and SQL Server at Black Hat Asia 2021. In our presentation, we introduced a previously undisclosed technique to execute SQL queries on the remote database in IIS and SQL Server under SQL injection or ad hoc scenarios. We also discussed three typical cases picked from around 100 Jet vulnerabilities that we discovered in a three-month period. Here, we cover the details of the technique, which allows threat actors to remotely attack IIS and SQL Server to gain SYSTEM privilege by using Microsoft Jet Database Engine vulnerabilities.
In response to this research, Microsoft released a complex patch to mitigate this attack surface. However, the patch is turned off by default and most Jet vulnerabilities are still not patched. We highly recommend that our customers proactively turn on mitigation to disable remote tables access in the registry and stay cautious of these kinds of attacks. Besides that, the mitigation for the attack surface in Access Connectivity Engine (ACE) still remains imperfect, and we are working with Microsoft to release a complete patch for both MS Jet and ACE.
The new attack surface is caused by the remote database access supported in Microsoft Jet Database Engine, including MS Jet Red (Jet Red Database Engine) and ACE (Access Connectivity Engine). It is a practical feature, but can also bring potential security issues. When misused, the feature allows attackers to execute SQL queries on the fully controlled database file on the remote attacker’s controlled server. Once the remote legitimate database file is replaced with a malformed database file, executing SQL queries on it could break the code precondition and assumptions in Microsoft Jet/ACE, leading to vulnerabilities in many Jet components.
The overall impact and break in security boundaries from these Jet vulnerabilities depend on where the SQL query is executed. The typical attack scenarios are SQL injection and ad hoc. In these two scenarios, attackers can execute any SQL queries on the malformed databases in the IIS and SQL Server. The resulting Jet vulnerabilities will impact the IIS and SQL Server. In detail, users can assign a remote database when executing SQL queries on tables by adding a database path ahead of the table in MS Jet and using OPENDATASOURCE,OPENROWSET or addlinkedserver in ACE, as shown in Figure 1.
Figure 1. Remote database access SQL in Access and SQL Server.
Inside MS Jet and ACE, CreateFile is called to open the remote database file in IIS and SQL Server. Given that the input path of the remote database is a UNC path, both Server Message Block (SMB) and Web-based Distributed Authoring and Versioning (WebDAV) will be used to open the remote database, as shown in Figure 2.
Figure 2. The hidden feature for CreateFile(UNC) in IIS and SQL Server.
SQL injection and ad hoc are just two of the possible attack scenarios. Similarly, IIS and SQL Server are only two of the potential victims. Any components supporting MS Jet and ACE on Windows could be vulnerable, as long as the component allows users to execute any query on the controllable database with MS Jet and ACE.
Vulnerabilities in IIS and SQL Server
The remote database access gives attackers the capability of replacing a legitimate database with a malformed database. According to our research, replacing the database is one of the keys to finding vulnerabilities in MS Jet and ACE. Assuming that code development and testing in MS Jet and ACE might not consider the situation of the database being malformed, we had the idea of mutating both SQL queries and database files. With that fuzzing strategy, we have discovered around 100 vulnerabilities in MS Jet and ACE, as shown in Figure 3. Most of them can be used to attack IIS and SQL Server under SQL injection and ad hoc scenarios.
Figure 3. ~100 MS Jet vulnerabilities.
In our presentation, we proved that just one byte change in the database file can lead to an MS Jet vulnerability, as shown in Figure 4.
Figure 4. The power of one byte mutation of the database.
Microsoft Patch
With the Patch Tuesday update for Windows released in May 2021, Microsoft assigned CVE-2021-28455 to our discovery and patched the new attack surface we reported. The patch introduces an option for users to disable remote database access in the MS Jet component and ACE component. Instead of patching every single JET vulnerability, it mitigated the whole attack surface disclosed in our presentation in multiple applications that use MS Jet, such as IIS and Access.
As we can see in Figure 5, there is a new field at offset 904h in the rgtib structure (represented by ebx register) for remote database access. It is set to 1 by default in the _ltibAllocate function, which means it is enabled by default.
Figure 5. Default value set for new field AllowQueryRemoteTables in the rgtib structure.
Then the UtilRegQueryValue2 function is called in the ErrReadRegistry function to get the value of the registry key – AllowQueryRemoteTables – under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\engines registry entry. After that, it stores the value to the AllowQueryRemoteTables field of the rgtib structure shown in Figure 6.
Figure 6. Get AllowQueryRemoteTables field from the registry in the UtilRegQueryValue2 function.
After that, two functions ( _ErrGetOutputDatabaseId and _ErrQEMCompileQuery) check the AllowQueryRemoteTables field in the rgtib structure (represented by ecx register), as figure 7 depicts.
Figure 7. Check the AllowQueryRemoteTables field in the rgtib structure.
As we can see in figure 8, if the AllowQueryRemoteTables field is set to 0, then the _ErrGetOutputDatabaseId function will return an error and the ErrTryOpenDatabase function will not be invoked to open the database file, regardless of whether the database file is remote or local. This effectively mitigates the remote database access attack surface.
Figure 8. AllowQueryRemoteTables field check in the _ErrGetOutputDatabaseId function.
However, this feature is not turned on by default. To disable remote database access, users need to add a registry, named AllowQueryRemoteTables, in corresponding registries as described in this Microsoft document and set the dword value to 0.
Next-Generation Firewall Mitigations for CVE-2021-28455
Palo Alto Networks Next-Generation Firewall customers can configure their Security Policy Rule settings to protect themselves from attacks related to CVE-2021-28455 by blocking WebDAV traffic from traversing from the trusted to untrusted zones.
How to configure App-ID to drop WebDAV packets:
Step 1: Create a Security Policy Rule.
1. Select Policies > Security and Add a new rule.
2. Enter a Name for the rule and add an optional Description.
Figure 9. Configuring Security Policy Rule.
3. On the Source tab, add “trust” to the Source Zone.
Figure 10. Configuring Source Zone.
4. On the Destination tab, add “untrust” to the Destination Zone.
Figure 11. Configuring Destination Zone.
5. On the Application tab, add WebDAV to the Applications.
Figure 12. Configuring applications.
6. On the Actions tab, use Drop action in Action Setting.
Figure 13. Configuring actions.
7. Click OK.
Step 2: Commit your changes.
Conclusion
IIS and SQL Server are examples of fundamental components in the Microsoft ecosystem that have been widely deployed in many production systems and services. Microsoft Jet Database Engine, including MS Jet and ACE, are over 20 years old, and a vast majority of the Jet modules have been found to be easily exploitable due to limited exploit mitigations. The remote database access feature connects the Jet vulnerabilities with IIS and SQL Server components, thereby downgrading their security to the same level as the Jet Database Engine. Attackers could potentially leverage this feature to attack IIS and SQL Server and get SYSTEM privilege remotely from a single SQL injection.
Palo Alto Networks recommends all of our customers follow the Microsoft guidance and disable remote database access to mitigate this severe attack surface. This can help prevent attackers from using Jet vulnerabilities to compromise IIS and SQL Server. Palo Alto Networks Next-Generation Firewalls can help mitigate such attacks by using App-ID and the Threat Prevention security subscription.
Ransomware is one of the top threats in cybersecurity and a focus area for Palo Alto Networks. In the current threat landscape, ransom payments are rising and organizations are seeking to protect themselves from threat actors. In the 2021 Unit 42 Ransomware Threat Report, we detailed the observations and the trend of top ransomware families from January 2020-January 2021. This post supplements that information based on observations from the first three months of 2021, and will discuss the propagation of different ransomware families we observed in the wild and the different types of extortion used. We hope the information will help readers get a clear picture of current directions in ransomware trends.
Ransomware Trends in Early 2021
In the first quarter (Q1) of 2021, Unit 42 detected 113 different ransomware families in the wild. Based on the statistical data, the top 15 ransomware families only cover 52.3% of total ransomware cases. This demonstrates the diversity of ransomware and emphasizes how difficult it is to expand ransomware detection coverage with static profiling. Figure 1 shows the proportion of ransomware sample numbers for different families that Unit 42 detected in the wild. Among all, 6.7% of the ransomware samples are Virlock, which has been active since 2014. Virlock has the largest number of variants due to its file-infector-like behavior.
Figure 1. Ransomware variant numbers, showing the proportion of ransomware sample numbers for different families that Unit 42 detected in the wild.
Higher malware variant numbers don't necessarily imply a higher prevalence. Some ransomware families don’t deliver different variants every time, but the infection ratio per sample is high, meaning attackers delivered the same malware to huge numbers of victims. Figure 2 shows a completely different result from Figure 1 and stems from only counting ransomware samples from cases in which more than five hosts were infected with the same malware. From this lens, the top three families observed are Ryuk (31.7%), Sodinokibi (20%) and Maze (15%).
Figure 2. Top ransomware families based on prevalence.
Emails are still the most efficient method to deliver and propagate ransomware. Figure 3 shows ransomware arrives via different application protocols. The majority of ransomware is delivered by email. Web browsing is the second most common entry vector for ransomware infections. The process of delivering malware by a URL can include various techniques. For example, the URL links can be posted on forums or chat group software, sent by IM applications, offered via fake freeware for download or attached in emails. Web hosting ransomware can also be downloaded and successfully installed through a multi-layered infection chain among different file types. For example, AlumniLocker is first delivered as a phishing PDF. It leads to downloading a ZIP archive that contains an LNK downloader. This downloads and executes an obfuscated PowerShell script to finally install the ransomware.
Figure 3. Arrival protocols used to deliver ransomware and their prevalence.Figure 4. File Type Breakdown.
Figure 4 breaks down which file types we saw in the course of ransomware detection and their prevalence. 32-bit EXE is the most common ransomware file type we observed. Other file types are often used as the first stage of infection or downloaders, such as archives, documents and scripts. Most ransomware is delivered via email with an attached archive; the ransomware is compressed in the archived files with or without password protection. “Resume” or “portfolio document” are examples of archive file names, and the archive contains one or more pieces of malware with fake document file icons. One example here is Makop, contained in a 7z archive along with an infostealer malware (SHA256: DE6DFA018773E07C218EF1DF62CE0D99A708841BF1DDFB4C6AD7E323D5D666A4). A script file is also used to download or install ransomware. For example, GandCrab uses JScript as a downloader, leveraging Windows Background Intelligent Transfer Service (BITS) to download the payload in the background (Figure 5). We also observed that Mailto (AKA NetWalker) tends to deliver ransomware in a highly obfuscated PowerShell script. Exploit documents are seldom seen for delivering ransomware. One example is an exploit RTF that led to downloading and installing Makop ransomware remotely.
Figure 5. GandCrab uses an HTTP BITS file transfer service to download a payload in the background.
Besides encrypting files on infected hosts, the main feature of ransomware is, of course, the demand for ransom. Since ransomware threat actors have had years to evolve their techniques, there are now several different ways for attackers to receive payments and provide the "service" they claim to offer. Usually, after the ransomware successfully installs, it pops up a message box or leaves text files to explain how to pay the ransom – the ransom note. Some ransomware locks the victim's screen and only displays the ransom note.
Unit 42 has reviewed ransom notes from different ransomware families. Most ransom notes request payment in cryptocurrency or mention reaching out via the darknet, though some other contact methods also appear.
Payment in Cryptocurrency
In these cases, the ransom note asks victims to pay a specific amount in cryptocurrency – Bitcoin (BTC), Monero (XMR), etc. — to a specific wallet address. Two ransomware families that utilize these types of ransom notes are Virlock and WanaCrypt0r.
Payment Through the Darknet
Some ransomware families, including Babuk, Sodinokibi, Cerber, Mailto, Ryuk and others, seldom show the ransom amount or cryptocurrency wallet address. Instead, they instruct victims to install TOR and reach out to them on the darknet. Usually, they host a website for victims to input the identification key found in the ransom note, upload encrypted files for decryption – and pay the ransom.
Other Methods of Ransom Payment
Ransom notes from Makop, Dharma, Ryuk, DearCry and others, sometimes ask victims to reach out to them via email. The email addresses given are usually from untraceable email accounts. At other times, a threat actor lets the victim chat with them directly on group chat software. The victims can find the threat actor’s user name through specific group chat software or follow a chat group link in the ransom note.
Ransom Payment Operations
Ransom payment operations are complicated and highly automated processes. Attackers can create a lot of cryptocurrency wallets automatically; they can even make a unique wallet address for each victim. Once a ransom is received, the ransom will be involved in the multiple transactions that are managed to distribute and aggregate the ransom across thousands of virtual wallets. For example, the Xorist ransomware (SHA256: 4979A10B81C41ECC0FC3A0F376ADE766CE616D2301639F74E0277047CC40E3D6) demanded £1,000 for a ransom; the bitcoin wallet address was 1BFqrLCDwwrxueY7FFDn8DqeoasPJignxt. However, this wallet had not really received any ransom payments when the malware was delivered. The wallet got involved in the operation of mixing and tumbling among several other virtual wallets. This is a pretty common operation when attackers want to withdraw or disperse currency from ransom payments into other wallets. During the operation, 25.1 BTC from 538 wallets was sent to 1NDyJtNTjmwk5xPNhjgAMu4HDHigtobu1s (SHA256: CE11703DEF517306326C48A67A7C859A3DE0F18E2451DF226CE171389A5B7953), which is a wallet owned by Binance cryptocurrency exchange. (ref: Binance on Twitter ). The 25.1 BTC amount was worth $1.18 million at that time, and now is about $876,000.
Ransomware Families: Low and High Profile
Since Virlock only requests a $250 ransom, it does not draw too much public attention. Other ransomware families, however, target enterprises and ask for multimillion dollar ransoms, which garners much more media attention. Based on the way Virlock spreads the ransom amount it demands, it is likely designed to target consumers or home users.
After infection, Virlock hides the file extension through modification of the registry (HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\HideFileExt= 1, HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Hidden= 2). The encrypted file icon will look the same as usual, but after opening the infected file, the ransom note will pop up. Virlock uses, but isn’t limited to, PDF, DOC, PPT, JPG, BMP,GIF, RAR, 7Zip, Zip and EXE files. Figure 6 is a screenshot of a recently captured Virlock ransom note. The attacker asked for $250 and required payment as 0.004 BTC (suggesting that at the time the ransom note was written, 1 BTC equaled approximately $62,500). At the time of infection experiments, 1 BTC equaled approximately $54,649, suggesting that the exchange rate in the ransom note is not updated on the fly. Some Virlock variants ask for more ransom, such as 0.771 BTC, 1.008 BTC or more.
Figure 6. Virlock ransom note.
The top three samples we observed spreading in early 2021 were Ryuk, Maze, and Sodinokibi. These three contribute 7.2% out of the total infected numbers we collected.
Ryuk will change the infected file extension to .RYK, and leave a ransom note called RyukReadMe.html. One of the reasons Ryuk causes so much damage is because it will scan the local network and try to infect other machines through Server Message Block (SMB) protocols. Ryuk will even send out Wake-on-LAN packets to wake up systems that have been configured with this feature.
Figure 7: Ryuk sample sent Wake-on-LAN
Conclusion
In this research, we discussed ransomware family trends we observed in the first three months of 2021. First, we reviewed the trends from prevalent ransomware families, then we discussed the most common file types used as attack vectors leveraged by ransomware. Lastly, we gave an example of ransom operations and updates about top ransomware families.
Ransomware threats are a serious challenge. Employing effective backup strategies and disaster recovery procedures is important. Palo Alto Networks customers are further protected from ransomware. Cortex XSOAR can automatically and instantly coordinate with network security, malware analysis and threat management solutions to ensure customers remain protected. Cortex XDR endpoint protection stops malware, exploits and ransomware before they can compromise endpoints. With AI-powered Inline analysis, the Next-Generation Firewall stops exploits that lead to infection, and WildFire’s always up-to-date machine learning models monitor behavior to preemptively detect unknown ransomware.
If you think you may have been impacted by ransomware, please email unit42-investigations@paloaltonetworks.com or call (866) 4-UNIT42 to get in touch with the Unit 42 Incident Response team.
![The diagram demonstrates the mechanism of a DNS rebinding attack with a hypothetical example. In this example, the victim, Alex, has a private web service in his internal network with IP address 192[.]0.0.1. This server contains confidential data and is supposed to be accessed by Alex's computer only. On the attack side, Bob controls two servers: a DNS resolver (1[.]2.3.4) and a web server (5[.]6.7.8) hosting the malicious website. In addition, Bob registers a domain, attack[.]com, with its nameserver (NS) record pointing to 1[.]2.3.4.](https://unit42.paloaltonetworks.com/wp-content/uploads/2021/08/word-image-62.png)
![The diagram illustrates how a multiple A-records attack works. The lefthand part of the diagram shows what happens for the private network and the righthand side displays what happens for the public network. Steps illustrated are 1. Victim browser asks the malicious DNS resolver, What is the IP of attack[.]com, 2. Malicious resolver responds, The IP of attack[.]com is as follows. 3. a malicious web server sends the victim's browser a malicious rebinding script, 4. The victim browser sends a second request, now going to the malicious web server, 5. This establishes cross-origin communication between the private web server and the victim browser.](https://unit42.paloaltonetworks.com/wp-content/uploads/2021/08/word-image-68.png)
![office365invoicea[.]xyz/ce: A typical example of a business phishing attack targeting Office365. This page requires that the user first interacts with the page to see the phishing form, possibly in an attempt to evade automated phishing detection engines.](https://unit42.paloaltonetworks.com/wp-content/uploads/2021/08/word-image-53.png)
![ww3ecure-authlogin4[.]ns02[.]info/Chase%20New/: A typical example of a consumer phishing attack targeting Chase bank.](https://unit42.paloaltonetworks.com/wp-content/uploads/2021/08/word-image-54.png)
![The screenshot shows a message posted in Dread, a dark web discussion forum. It announces an affiliate program for AvosLocker, one of the four emerging ransomware groups we identified. The message is titled, "AvosLocker - Ransomware [ACCEPTING AFFILIATES]"](https://unit42.paloaltonetworks.com/wp-content/uploads/2021/08/word-image-19.png)
When this ransomware is executed, it drops two batch scripts. The first script, 
Get updates from Unit 42 