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.
While monitoring the Microsoft Exchange Server attacks in March 2021, Unit 42 researchers identified a PlugX variant delivered as a post-exploitation remote access tool (RAT) to one of the compromised servers. The variant observed by Unit 42 is unique in that it contains a change to its core source code: the replacement of its trademark word “PLUG” to “THOR.” The earliest THOR sample uncovered was from August 2019, and it is the earliest known instance of the rebranded code. New features were observed in this variant, including enhanced payload-delivery mechanisms and abuse of trusted binaries.
First discovered in 2008, PlugX is a second-stage implant that’s been used by Chinese cyberespionage group PKPLUG (aka Mustang Panda) and other groups. In addition to being used in multiple high-profile attacks over the years, including the significant U.S. Government Office of Personnel Management (OPM) breach in 2015, PlugX is also known for its modularity and plug-in-style approach to malware development.
Additional hunting and analysis led to the identification of several more samples along with an associated PlugX command and control (C2) infrastructure. This blog provides a technical overview of the PlugX variant discovered, indicators of compromise (IOCs) to identify it in networks and a tool developed by Unit 42 to handle payload decryption.
On March 19, 2021, attackers were observed exploiting an Exchange Server via a chain of zero-days (CVE-2021-26855 and CVE-2021-27065), known as ProxyLogon, originating from IP 101.36.120[.]227. Upon successful exploitation, a webshell was uploaded to a publicly accessible web directory, allowing code execution at the highest privilege level.
The attackers then used a technique known as “living off the land,” which uses trusted binaries to bypass antivirus detection. In this case, the Microsoft Windows binary bitsadmin.exe was used to download an innocuous file named Aro.dat (SHA256: 59BA902871E98934C054649CA582E2A01707998ACC78B2570FEF43DBD10F7B6F) from an actor-controlled GitHub repo to the target. (See Figure 1 for the download command executed.)
Figure 1. Bitsadmin command example.
Aro.Dat: Overview
The first one thousand bytes of Aro.dat (see Figure 2) indicate the file might be encrypted or possibly compressed. As it turns out, this data is nothing but random padding data likely added as a file header to evade AV signatures to thwart detection. The end of the filler data is null-terminated, which provides an identifier to the actual data entry point. Immediately following the NULL byte (0x00) is a set of x86 assembly instructions to unpack the file. In this sample, the x86 assembly starts at file offset 0x4EC with opcode 0x77. This translates to assembly mnemonic of JA (jump if above unsigned).
Figure 2 illustrates the Aro.dat file header up until the NULL byte. The data was truncated for brevity, as the bytes up until the NULL are meaningless. Red denotes the NULL byte, and green is where code execution begins.
Aro.dat is designed to remain undetected and cannot run without the aid of a specific loader. As with previous PlugX variants, code execution is achieved via a technique known as DLL side loading. Static analysis reveals that once loaded into memory, Aro.dat begins to unpack itself and initiates communication with a C2 server.
Aro.dat is, in fact, an encrypted and compressed PlugX payload. The decryption routine within Aro.dat closely resembles that of older PlugX variants (see Figure 3 below) in that it involves multiple decryption keys and bit shift operations. Once decrypted, it gets decompressed via the Windows API RtlDecompressBuffer into a Windows module (DLL). The compression algorithm is LZ compression (COMPRESSION_FORMAT_LZNT1).
Figure 3. Comparison of PlugX decryption routines
The highlighted entries shown in Figure 3 are the static decryption keys used by Aro.dat and an older 2012 PlugX sample (SHA256: A68CA9D35D26505A83C92202B0220F7BB8F615BC1E8D4E2266AADDB0DFE7BD15). The decryption routine differs slightly with each PlugX build by using different static keys and varying the use of addition and subtraction.
The decrypted, decompressed Aro.dat is an x86 Windows DLL or PE file.
Aro.Dat: Code Execution
The Aro.dat file contains the following string names: aross.dll, aro.exe and aro.dat. The association of these three files together provides insight into how code execution is likely achieved. VirusTotal has the following files:
Open-source research suggests Aro.exe is part of the “ARO 2012 advanced repair and optimization tool.” It is a freely available tool that claims to fix Windows registry errors. It is digitally signed, has known associations with a PlugX loader and dynamically loads Aross.dll. Aross.dll is the actor’s DLL file that is responsible for loading the encrypted payload file, Aro.dat. With this information, we can infer that these two files are necessary and responsible for loading the encrypted THOR payload, Aro.dat.
See Figure 4 for an illustration of how code execution is achieved.
Figure 4. DLL sideloading overview for Aro.dat
Aro.Dat: Runtime Operation
Once the decrypted payload runs in memory, it exhibits the same behaviors as previous PlugX implant variants. It starts by decrypting the embedded PlugX hardcoded configuration settings. The decryption algorithm and XOR keys are fairly consistent across multiple PlugX implants. Code behavior closely resembles that of the RedDelta PlugX that’s been reported by Insikt Group. One noticeable difference with this sample compared to all the other known PlugX malware families is the magic number check performed during the initialization of the PlugX plugins. Historically, that number has always been 0x504C5547, which corresponds to the PLUG value in ASCII encoding. In this sample, the magic number is 0x54484F52, corresponding to the THOR value in ASCII encoding.
Figure 5 below illustrates the differences.
Figure 5. DLL PlugX magic number comparison
The hardcoded PlugX configuration settings within the sample decoded to the following values (truncated):
As illustrated in Figure 6, this particular PlugX implant is configured for the following:
Four C2 domains of rainydaysweb[.]com
Communication with ports: 80, 443, 53 and 8000. Data is transmitted on both TCP and UDP protocols. Outputs data transmitted to debug (outputdebugstringW) to debugger (if attached). Example:
Figure 7. Debug output example
Uses the HTTP protocol. The initial handshake with the C2 is not HTTP, and it consists of random bytes of variable lengths. The implant expects 16 bytes of data for the return and, depending on the return value (command), will initiate HTTP communication. The PlugX SxWorkProc thread is responsible for handling HTTP communications. An example HTTP header:
Figure 8. HTTP POST example
Breakdown of Figure 8:
POST data is made of random bytes.
User-agent is a hardcoded value: Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 10.0; .NET4.0C; .NET4.0E; Tablet PC 2.0).
utmcn, utmcs, utmsr, and utmsc are hardcoded user-agent values.
To create a Windows system service using the name and description: HP Digital Image
Figure 9. PlugX sample running as HP Digital Image
Possible campaign ID of 1234
When running, system events such as process creation, date and time and username are logged to a hidden file named NTUSER.DAT, located in the C:\ProgramData\MSDN\6.0 directory. This file is encrypted with a two-byte key of 0x4F6F.
There are two other identifiable attributes for PlugX:
1. The hidden Windows class name, Static, shown in Figure 10. This window is used for inner-process communications.
Figure 10. PlugX Windows class name
2. The MZ and PE headers of the RWX in-memory module are removed and replaced with ASCII ROHT (THOR backwards), shown in Figure 11.
Figure 11. In-memory module artifact
This sample has the following PlugX plugins, which have an individual hardcoded date stamp, as illustrated in Table 1 below. Much has been said about these plugins in the past. In summary, they provide attackers various capabilities to monitor, update and interact with the compromised system to fulfil their objectives.
Plugin Name
Date Time Stamp Value
Disk
0x20120325
Keylog
0x20120324
NetHood
0x20120213
NetStat
0x20120215
Option
0x20120128
PortMap
0x20120325
Process
0x20120204
RegEdit
0x20120315
Screen
0x20120220
Service
0x20120117
Shell
0x20120305
SQL
0x20120323
Telnet
0x20120225
Table 1. PlugX plugins
This sample also appears to contain a key or a hard-coded date of 20180209, which is used within a structure and passed whenever a function object is called.
Links to PKPLUG
PlugX modules, such as Aro.dat, include hardcoded configuration information allowing for multiple C2 addresses. This provides fallback options for the backdoor in case some remote services are unavailable at the time of compromise. In this particular PlugX implant (SHA256: 59BA902871E98934C054649CA582E2A01707998ACC78B2570FEF43DBD10F7B6F), and as shown in Figure 6 above, all four C2 configuration options reference the domain name rainydaysweb[.]com.
Overlaps between the recently discovered PlugX samples with the THOR magic bytes (the infrastructure) and other entities associated with known PKPLUG activity are highlighted in Figure 12 below, stemming from the orange rectangle and the red square, respectively.
As previously mentioned, Aro.dat (SHA256: 59BA902871E98934C054649CA582E2A01707998ACC78B2570FEF43DBD10F7B6F) was downloaded from an actor-controlled GitHub repository to the target Microsoft Exchange Server using bitsadmin. As such, the specific component responsible for loading and decrypting the module is unknown. However, the connection from it to rainydaysweb[.]com is shown in the blue oval shape in Figure 12.
Several overlaps of related infrastructure and common malicious behaviors were found and are described below using reference number notation [x] that references parts of Figure 12.
PlugX sample (SHA256: 93D33626886E97ABF4087F5445B2A02738EA21D8624B3F015625CD646E9D986E)[1], first seen March 19, 2021, uses the traditional PLUG (not THOR) identifier and communicates with the same C2, rainydaysweb[.]com. This sample also shares some behavioral characteristics with other PlugX samples, namely registry activity specific to the creation of the key, HKLM\Software\CLASSES\ms-pu\PROXY[2]. Some of those samples make use of the C2 infrastructure linked to PKPLUG activity in the past, such as PlugX sample (SHA256: A15FED60E69EC07BFD01A23BEEC2C8E9B14AD457EA052BA29BD7A7B806AB63B4)[3] from late 2020 using C2 manager2013[.]com.
Other samples from the set using the common registry key, through the use of shared infrastructure, reveal further samples containing C2 communication information relating to the third-level domain, upload.ukbbcnews[.]com[4]. This domain is not and has never been a legitimate BBC domain and was registered to appear as such to victims. This domain resolved to IPv4 address 45.248.87[.]217 up until April 12, 2021, providing the C2 channel for PlugX sample (SHA256: 690C488A9902978F2EF05AA23D21F4FA30A52DD9D11191F9B49667CD08618D87)[5] with its THOR module mpsvc.ui (SHA256: 64E2FE0E9D52812D2DA956B1D92B51E7C215E579241649316CF996F9721E466E) from early August 2020.
Other "ukbbcnews" third-level domains (i.e. bbc., news. and www.)existed and resolved to the same 45.248.87[.]217 IPv4 address from as far back as May 2019 through March 2021. In 2018, the same third-level domains resolved to some IPv4 addresses in the 134835 ASN range, including 185.239.226[.]65, 185.239.226[.]76 and 185.239.226[.]14, which have been used as C2 channels for various PlugX samples, seemingly throughout 2018, 2019 and 2020. PlugX sample (SHA256: 3CDD33DEA12F21A4F222EB060E1E8CA8A20D5F6CA0FD849715F125B973F3A257)[6] from June 2018 shares behavioral traits, namely setting the value of registry key HKLM\SOFTWARE\Classes\KET.FAST\CLSID[7] to -1, with two other PlugX samples over the last three years.
Out of the set of three such PlugX samples known to Unit 42 that changed the value of that registry key, one sample (SHA256: A9511CDAA96ED59DE73A7A7C7DC375DE204BEE7A9511C5EE71BF013010324A91)[8] existed around the same timeframe (June 2018) using the domain tibetsl[.]com and many third-level domains from it for C2 communication. The third PlugX sample, (SHA256: 80DEED939A520696968335D1BB2A9FCCE7053C0156F679BA261824D0A2D44967)[9], from the set also used the THOR identifier. From November 2019, this sample and its configuration module aross.dat (SHA256: C5DCD3073904FAD5D9A8FE1026141A832E05C9CA03A88FEE96587921F42773D4) used 108.61.182[.]34 for its C2 communication, which resolved to the indonesiaport[.]info[10] domain between September 2019 and February 2020. The same domain has been used for C2 communications by several other PlugX samples (using the PLUG identifier) that Unit 42 tracks as related to PKPLUG, dating as far back as August 2017.
Another configuration module using the THOR identifier, acrobat.chm (SHA256: B5C0DB62184325FFBE2B8EF7E6F13F5D5926DEAC331EF6D542C5FA50144E0280)[11] loaded by PlugX sample Acrobat.dll (SHA256: 3C5E2A4AFE58634F45C48F4E800DC56BAE3907DDE308FF97740E9CD5684D1C53) was first seen at the end of October 2020. The C2 channel from the configuration is tools.scbbgroup[.]com, which at the time resolved to 167.88.180[.]131, and since early February 2021, it continues to resolve to 103.85.24[.]158 under the ASNs 6134 and 134835, respectively[12]. Other known PKPLUG infrastructure using additional IP addresses from the range under both ASNs are tracked by Unit 42 and other vendors.
Examples include www.ixiaoyver[.]com and www.systeminfor[.]com that resolved in April and May 2020 respectively to 103.85.24[.]190, which acted as C2 channels for several PlugX samples (using the PLUG identifier).
Shortly after the brief, two-day period when www.systeminfor[.]com resolved to 103.85.24[.]190, the resolution briefly changed to 167.88.180[.]32 (ASN 6134), which other PKPLUG-related domains resolved to throughout the course of 2020. One such domain was www.cabsecnow[.]com, which was used as a C2 channel for another PlugX sample (SHA256: A9CBCE007A7467BA1394EED32B9C1774AD09A9A9FB74EB2CCC584749273FAC01)[13] and configuration module Smadav.dat (SHA256: E2D21B5E34189FA1ACA39A13A405C792B19B6EDF020907FB9840AF1AAFBAA2F4) using the THOR magic bytes in August 2020.
The final PlugX sample using the THOR identifier [14] is SmadHook32.dll (SHA256: 125FDF108DC1AD6F572CBDDE74B0C7FA938A9ADCE0CC80CB5CE00F1C030B0C93) and its configuration module Smadav.dat (SHA256: CC1AFB373F8286C08869CD786FEE75B8002DF595586E00255F52892016FD7A4F) is the most recent THOR sample Unit 42 has discovered. First seen in March 2021, this sample's C2 references news.cqpeizi[.]com, which since late 2019 resolves to the loopback address 127.0.0[.]1.
PlugX: The Hunt for Others
With an understanding of how the encrypted payload files are constructed, Unit 42 researchers created a signature based on the x86 assembly instructions. These instructions are used to unpack the payload. (See Table 2 for a list of files discovered.)
During our research, we discovered other PlugX-encrypted payloads that have a different encoding scheme and file header. These samples are XOR encoded with the decryption key consisting of the bytes starting at file offset zero, up until the NULL byte. Typically, the key is 10 bytes in length. Once decrypted, the sample is that of a PE file (DLL). (Reference Table 3 for a list of files uncovered that follow this format.)
We’ve identified two other PlugX-encrypted payload files with different encoding schemes. These files were manually decrypted and confirmed to be PlugX variants. (See Table 4.)
Unit 42 PlugX Payload Decrypter
Unit 42 created a Python script that can decrypt and unpack encrypted PlugX payloads without having the associated PlugX loaders. It attempts to detect the type of PlugX-encrypted samples and then outputs the following:
Decrypted and decompressed PlugX module (DLL). Adds an MZ header to the file as the MZ header is not present in the in-memory module. It only applies to encrypted payloads that have the random byte header (THOR payloads).
Hardcoded PlugX configuration file (C2 information), if supported.
Thirteen years after its initial discovery, the PlugX malware family remains a threat. After 10+ years of consistent source code components, the developers made an unexpected change to its signature magic value from “PLUG” to “THOR.” New features were observed in this variant, including enhanced payload delivery mechanisms and abuse of trusted binaries. With the THOR identifier signature, Unit 42 will continue to search for additional samples and variants that may be associated with this new PlugX variant.
Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and systematically disrupt malicious cyber actors. Visit the Cyber Threat Alliance for more information
Unit 42 has discovered a specific single bit (Trap Flag) in the Intel CPU register that can be abused by malware to evade sandbox detection in general purposes. Malware can detect whether it is executing in a physical or virtual machine (VM) by monitoring the response of the CPU after setting this single bit.
Sandboxing is a popular technique used to detect whether a sample is malicious. A sandbox analyzes the behaviors of the binary as it executes inside a controlled environment. To overcome the challenge of analyzing a large number of binaries with limited computing resources, virtual machines are used to build sandboxes. To evade detection, malware will try to determine whether it is executing in a physical or virtual machine. When the malware finds out it is executing in a virtual machine, it will terminate its execution or provide fake outputs to hide its real intentions.
Some of the most common evasion techniques involve malware conducting various system checks against the environment it is executing in. For example, malware will often look for abnormal screen resolution, hard disk and physical memory size. Sandboxes can build countermeasures, such as returning fake information to the malware during these checks.
This blog documents how malware can detect the differences in CPU behaviors in a virtual or physical machine with only a single bit in the CPU register.
Single-Step Mode With a Single Bit — the Trap Flag (TF)
To detect the use of a VM in a sandbox, malware could check the behavior of the CPU after the trap flag is enabled.
The trap flag (TF) is the 8th single bit in the EFLAGs register of the Intel x86 CPU architecture. If the TF is enabled before a single instruction is executed, the CPU will raise an exception (single-step mode) after the instruction is completed. This exception stops the CPU execution to allow the contents of the registers and memory location to be examined by the exception handler. Before allowing code execution to continue, the CPU also has to clear the TF.
To determine whether a VM is used, malware can check whether the single-step exception was delivered to the correct CPU instruction, after executing specific instructions (e.g. CPUID, RDTSC, IN) that cause the VM to exit with the TF enabled. During VM exits, the hypervisor – also known as Virtual Machine Monitor (VMM) – will emulate the effects of the physical CPU it encounters.
The following sequence of instructions explains the CPU’s behavior after enabling the TF in a physical machine.
Figure 1. CPU instructions to enable TF.
The first three instructions enable the TF bit in the EFLAGs register of the CPU. RDTSC is executed with the TF enabled. In a physical machine, the exception would be delivered to the first no operation (NOP) instruction (0x00401073). Take note that the exception occurred on the instruction immediately after the execution of the instruction with TF enabled.
Figure 2. Execution in a physical machine.
Executing the same sequence of instructions in a VM would have a different effect. In a VM, executing RDTSC would result in a VM exit. The hypervisor will carry out its usual tasks of emulating the behaviors of the RDTSC instruction. However, an implementation of the hypervisor with incorrect emulation of the TF would result in the TF being ignored and the code execution will continue to the first NOP instruction. During the execution of the first NOP instruction, the TF is still enabled as the TF was not handled by the hypervisor. This results in an exception occurring on the second NOP instruction (0x00401073). The correct implementation will require the hypervisor to inject a debug exception after emulating the instruction that caused the VM exit and clearing the TF.
Figure 3. Execution in a virtual machine.
As a sandbox evasion technique, malware will use an exception handler in addition to the above instruction sequence to examine which instruction the exception occurred on. The next section describes a real-world example of a malware family that made use of this technique to evade sandboxes.
Real-World Example
Lampion is a malware family that was targeting users in Portugal. Lampion employed multiple system checks to evade sandbox detection. One of the techniques is making use of the single-step mode with TF, as discussed in the previous section.
Lampion implemented all its system checks with x86 assembly instructions and minimal Windows API calls. This allowed the Lampion samples to conceal their behavior from the sandboxes. The Lampion samples would terminate if the malware determined it was executing inside a VM. The system checks are also intertwined with multiple anti-reverse engineering techniques to hide from human analysts.
The following screenshot shows a snippet of instructions hidden in the Lampion sample that conducts the system check.
Figure 4. Instructions in Lampion used to evade sandboxes.
The following is pseudocode to demonstrate how Lampion carries out one of its sandbox system checks by enabling TF on an instruction that causes the VM to exit.
Figure 5. Pseudocode of Lampion carrying out anti sandbox check using TF.
The instruction right after the instruction RDTSC is NOP. The byte code for the NOP instruction is 0x90. The exception handler would traverse the ContextRecord structure to locate the address of the instruction in the Extended Instruction Pointer register (EIP) when the exception occurred. The instruction is then compared against the 0x90 byte and the malware will exit if the check fails.
The following screenshot shows the EIP=0x7F0E4E when the exception happened.
Figure 6. Address of the instruction where the exception occurred.
Malware vs Sandbox Authors
For many years, there has been an ongoing cat and mouse game between malware authors crafting evasion techniques to prevent effective analysis, and sandbox authors who research novel ways to defeat those evasions.
This is one of the main drivers that led us at Palo Alto Networks to build our own custom hypervisor for malware analysis. Since we have full control over the software stack, including the virtualization layer, we can react to new and emerging threats. In this particular case, once we had identified the issue with the incorrect emulation of the trap flag, our hypervisor team was able to test and deploy a fix. This evasion issue has since been resolved for any malware sample using this technique.
Palo Alto Networks customers are further protected from malware families using similar sandbox evasion techniques with Cortex XDR or the Next-Generation Firewall with WildFire and Threat Prevention security subscriptions. AutoFocus customers can track the malware discussed here using the Lampion tag. Other similar sandbox evasion techniques that rely on abusing Intel CPU instructions or registers will not work against WildFire.
![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 