In May 2021, Palo Alto Networks launched a proactive detector employing state-of-the-art methods to recognize malicious domains at the time of registration, with the aim of identifying them before they are able to engage in harmful activities. The system scans newly registered domains (NRDs) and detects potential network abuses. However, the proactive detector has limitations; created to only focus on new domains, it cannot obtain and analyze malicious indicators appearing after a domain's creation. In addition, in the cases of adversaries leveraging or compromising aged domains to carry out attack traffic, the proactive detector fails to capture the emerging threats because the malicious domains are out of the scope of being considered NRDs.
In addition to scanning for potential abuses at the time of registration, we have another great opportunity to detect malicious domains proactively when they start carrying attack traffic. A malicious domain may be registered long before it serves its attacking campaign and exposes indicators of abuse. Once the domain starts carrying malicious traffic, we can observe its DNS requests from passive DNS. To block network threats at this early stage, we developed a new proactive detector that ingests newly observed domains (NODs) to discover potential threats among them. The new detector leverages various machine learning techniques to expose suspicious behaviors based on various information about NODs, including their latest WHOIS records and DNS traffic.
This blog will illustrate how we collect and analyze the enriched features available for NODs to detect emerging threats. Our detector scans 2.6 million NODs and captures around 2,300 suspicious domains every day. To evaluate the performance, we cross-checked the detected domains against other threat intelligence from VirusTotal. 33.08% of the NODs detected by our system were also labeled as malicious by other sources later. But our detector's average discovery time is 4.79 days earlier than any VirusTotal vendor. Furthermore, we will explain the new system's benefits with case studies about various network abuses such as command and control (C2), phishing and unethical search engine optimization (SEO) practices. We will discuss how the proactive detector captured and blocked these threats based on different indicators for cybercriminal activities.
Palo Alto Networks collects passive DNS data from multiple sources, including our DNS Security service, as well as external providers from all around the world. Our cloud-based passive DNS system can ingest and process about 13 million DNS logs each day. The data ingestion pipeline catches the latest DNS data every hour and extracts the domains that haven't been seen carrying traffic before. These domains will be forwarded to the proactive detector to identify emerging threats. Our system can capture and scan about 2.6 million NODs daily.
Figure 1. Daily NOD amount and the percentage flagged as suspicious.
For each NOD, our centralized data collector will actively crawl all related information, including the latest WHOIS record and all DNS traffic requesting the domain and its subdomains. To leverage a variety of malicious indicators, we developed individual machine learning models to analyze different information. Specifically, we built a reputation system to evaluate WHOIS records, applied multiple classification models to DNS-related features, and used the bigram model to analyze hostnames. These models captured about 2,323 unique potentially malicious NODs every day. Figure 1 shows the daily NOD amount and detection rate from April 27-May 2, 2022.
Figure 2. Malicious NOD Dormant Period CDF.
To analyze attackers' behaviors, we compare the registration date of potentially malicious NODs and the date when they start hosting DNS traffic to see how long they keep silent before activation. Figure 2 presents the cumulative distribution function (CDF) of their dormant periods. The malicious domains start carrying traffic 5.57 days after their registration on average. However, during the period studied, our detector captured 152 NODs involving network abuses more than one year after creation – some domains can lie dormant for a significant amount of time before beginning malicious activity.
Figure 3. Early discovery time CDF.
Of all suspicious NODs detected by the new proactive system, 37.11% were labeled as confirmed malicious 30 days later by Palo Alto Networks or other threat intelligence vendors in VirusTotal. Figure 3 shows the CDF of how many days before any vendor on VirusTotal the proactive detector was able to flag malicious domains. On average, our detector can capture these malicious domains and isolate their traffic 4.79 days before any VirusTotal vendor blocks them. Furthermore, we can discover 19.47% of malicious NODs more than a week earlier than others.
Broader Visibility Into Emerging Internet Threats
One major benefit of our new proactive malicious NOD detector is that it extends visibility into emerging attacking domains. The previous proactive detector scans threats among NRDs only. However, not all top-level domains (TLDs) disclose their new domains to the public. For example, hundreds of country-level TLDs are maintained by governments. Access to their complete domain list or WHOIS database is restricted.
Let's take a malicious domain within the .ga TLD, for instance. Our proactive detector captured and labeled the NOD payment-downlaods[.]ga as grayware on March 4. .ga is the country code TLD for Gabon. This TLD offers free domain registration, but its domains’ creation dates are not available in the WHOIS records. Therefore, we cannot directly confirm .ga NRDs based on the registration information. Monitoring passive DNS data is the primary way to detect recently active .ga domains. We caught payment-downlaods[.]ga carrying C2 traffic 12 days after we first observed its DNS traffic. The domain served Android Package Kit (APK) spyware that attempted to steal private information including SMS messages (SHA256: e9ad04ae0201307e061cdae350c392a6b4537876991b2c97857ea71086fa0496).
Besides textual characteristics, the WHOIS record is another important feature that can be used for proactive malicious domain detection. It can expose various network abuse warning signs such as registrants, registrars and name servers. Our malicious NOD detector will actively crawl new domains’ WHOIS records for analysis once we observe their DNS traffic.
For example, our detector blocked a phishing domain within the .ml TLD as soon as we observed it in passive DNS data on May 10. The centralized WHOIS database for .ml is not publicly available, so the detectors focusing on NRDs failed to inspect this domain. However, once it began to carry traffic, the proactive malicious NOD detector crawled its WHOIS record and found the name server is offshoreracks[.]com, which provides an offshore and anonymous hosting service. Besides this questionable name server, the NOD's registrar also has a bad reputation. The NOD is a squatting domain mimicking a major international banking group based in Italy. The phishing website copied the text from the official site but with fake contact information. Interestingly, despite mimicking an Italian bank, the website uses Turkish, so it's likely intended to target Turkish victims.
Capture More Malicious Indicators
Unlike the WHOIS record that is available once a domain is created, some indicators for cybercriminal activities will only be exposed after a malicious domain starts carrying attacking traffic. Therefore, our detector also analyzes the DNS traffic of NODs to capture any suspicious behaviors.
Figure 4. Black hat SEO page hosted on DGA subdomain of twtyowq[.]tk.One of the abnormal DNS traffic patterns that is highly related to network threats is the presence of a large number of subdomains produced by domain generation algorithms (DGAs). Attackers could use these subdomains to exfiltrate stolen information or perform black hat search engine optimization (SEO) with wildcard DNS. Our proactive detector leverages this indicator to identify potentially abused NODs.
Let's take a pop-up advertising campaign that we detected as an example. This campaign was distributed through .tk domains such as twtyowq[.]tk, bsdybwo[.]tk and bwafduj[.]tk. The creation time of .tk domains is unavailable so we cannot obtain any NRDs under this zone. However, when we first saw these domains' DNS traffic, each of them had hundreds of DGA subdomains hosting scam pages asking for notification permission and redirecting visitors to unwanted ads (see Figure 4).
Figure 5. Gambling website hosted on jxc786[.]com.Besides explicit DGA subdomains, our detector digs deeper into NODs' DNS logs to expose DGA traffic hidden behind them. For example, the domain jxc786[.]com was registered on April 23, but we didn't see any evidence of cybercriminal activity at that time. However, it started pointing to b136jishiang01hy.bakbitionb[.]com on May 22. bakbitionb[.]com is the infrastructure domain for a gambling campaign. In passive DNS, this domain has hundreds of DGA subdomains associated with different gateway domains through CNAME records. If visitors directly open these DGA subdomains in their browsers, they will be redirected to baidu[.]com for cloaking. However, traffic from gateway domains such as jxc786[.]com will reach the gambling website shown in Figure 5.
Figure 6. Fake iCloud account recovery page hosted on asuna-sao[.]us.The proactive detector can also discover and block levelsquatting subdomains from NODs’ passive DNS records. The levelsquatting technique includes a legitimate website’s domain as a subdomain in order to trick visitors into thinking they have arrived at the legitimate website. It is commonly used in conjunction with phishing attacks.
For example, our system recognized multiple subdomains of asuna-sao[.]us as levelsquatting hostnames masquerading as Apple Inc and labeled the domain as dangerous. The domain was registered on April 12 and started receiving traffic for subdomains like www.flnd-appleld.asuna-sao[.]us, www.lcloud-supoort.asuna-sao[.]us and www.apple-flnd.asuna-sao[.]us on the same day. These hostnames all deliver the same phishing page, which tries to steal Apple ID credentials (Figure 6).
Capture Aged Malicious Domains
In previous writing on strategically aged domains, we reported that some had been registered years before they were actively involved in cybercriminal campaigns. These domains didn't reveal any indicator for network abuses when they were created. Monitoring NODs gives us a second chance to capture aged malicious domains.
Figure 7. Advertisement page hosted on createruler[.]com.When crawling NODs' WHOIS records, we discover that many aged domains have recent WHOIS record changes before they are involved in network abuses. For example, createruler[.]com was registered in May 2022. Its WHOIS was updated on June 3, 2022. Then the domain started hosting a rogue advertising page, as shown in Figure 7. Our proactive detector analyzed its latest WHOIS record and classified it as suspicious based on its use of a highly abused name server. The name server is a parking service provider that monetizes domains' traffic through advertisement networks. This kind of parking site could expose visitors to various threats, such as malware distribution, potentially unwanted program (PUP) distribution and phishing scams.
The proactive detector also captured some domains repeatedly leveraged by network threats. For example, we captured a squatting domain mimicking a major digital payment network based in the United States. It used to serve a phishing campaign in 2020 and expired in 2021. But the adversary registered it again on March 13, 2022. Our detector observed it started carrying traffic and recognized it as a potentially malicious NOD on Sept. 2, 2022. The domain hosts a rogue website that tags the legitimate target domain on the index page and tries to collect the visitor's contact information. This website is highly suspicious and likely to be engaged in network fraud.
Conclusion
At Palo Alto Networks, we extract NODs from passive DNS and proactively detect potential cybercriminal activities among them. The new detector leverages various machine learning techniques to capture indicators for network abuses from WHOIS records, DNS traffic and lexical features. The system extends our visibility on emerging network threats and identifies new kinds of suspicious behaviors. As a result, it can discover about 2,323 potentially malicious domains as soon as they become active every day and protect our customers on average 4.79 days before the domains are confirmed to be involved in attacking campaigns.
Palo Alto Networks identifies the detected domains with the grayware category through our cloud-delivered security services for Next-Generation Firewalls, including URL Filtering and DNS Security. Our customers receive protections against damage from risky domains mentioned in this blog, as well as additional risky domains captured by our system.
Ransom Cartel is ransomware as a service (RaaS) that surfaced in mid-December 2021. This ransomware performs double extortion attacks and exhibits several similarities and technical overlaps with REvil ransomware. REvil ransomware disappeared just a couple of months before Ransom Cartel surfaced and just one month after 14 of its alleged members were arrested in Russia. When Ransom Cartel first appeared, it was unclear whether it was a rebrand of REvil or an unrelated threat actor who reused or mimicked REvil ransomware code.
In this report, we will provide our analysis of Ransom Cartel ransomware, as well as our assessment of the possible connections between REvil and Ransom Cartel ransomware.
Indicators of compromise and Ransom Cartel-associated tactics, techniques and procedures (TTPs) can be found in the Ransom Cartel ATOM.
We updated this blog on Oct. 15 based on further analysis, additional evidence and discussion around the complexities of redirects from REvil’s dark web leak site. Updated sections include our History of the REvil Disappearance and the Ransom Cartel Overview.
In October 2021, REvil operators went quiet. REvil’s dark web leak site became unreachable. Around mid-April 2022, individual security researchers and cybersecurity media outlets reported a new development with REvil that could signify the gang’s return. REvil’s name-and-shame blogs at the dnpscnbaix6nkwvystl3yxglz7nteicqrou3t75tpcc5532cztc46qyd[.]onion and aplebzu47wgazapdqks6vrcv6zcnjppkbxbr6wketf56nf6aq2nmyoyd[.]onion domains started redirecting users to a new name-and-shame blog available at blogxxu75w63ujqarv476otld7cyjkq4yoswzt4ijadkjwvg3vrvd5yd[.]onion/Blog.
Later the same day, the redirect was removed (as noted by vx-underground). At the time, it was not possible to make a definitive attribution stating which group was behind the redirect because the new name-and-shame blog did not claim any name or affiliation.
At the start of the redirect, no breached organizations were listed on the site. Over time, the threat actors began adding records that had appeared on “Happy Blog,” mostly from late April to October 2021. They also included the old file-sharing links previously used by REvil as proof of compromise.
The newly established blog listed Tox Chat ID for communication with the ransomware operator. The blog hinted at its operators’ connection to REvil with the claim that the newer group offered “the same, yet improved software.”
Unit 42 initially believed that this blog was linked to Ransom Cartel and that the “improved software” the threat actors referred to was a new Ransom Cartel variant. However, after further analysis and seeing more evidence, we believe it is also possible that the name-and-shame blog and Ransom Cartel are two separate operations.
Whether this blog is operated by Ransom Cartel or a different group, what is clear is that, while REvil may have disappeared, its malicious influence has not. The operator of the newly established blog appears to have some type of access to REvil or ties to the group. At the same time, our analysis of Ransom Cartel samples (detailed in the sections below) provides strong evidence of ties to REvil as well.
To read more about REvil, its disappearance and the redirect, please refer to our blog, Understanding REvil.
Ransom Cartel Overview
We first observed Ransom Cartel around mid-January 2022. Security researchers at MalwareHunterTeam believe the group to have been active since at least December 2021. They observed the first known Ransom Cartel activity and noticed several similarities and technical overlaps with REvil ransomware.
There are a number of theories about the origins of Ransom Cartel. One theory in the community suggests that Ransom Cartel could be the result of multiple groups merging. However, researchers at MalwareHunterTeam have put forward that one of the groups believed to have merged has denied any connection with Ransom Cartel. Additionally, Unit 42 has seen no connection between these groups and Ransom Cartel other than that many of them have connections to REvil.
At this time, we believe that Ransom Cartel operators had access to earlier versions of REvil ransomware source code, but not some of the most recent developments (see our Ransom Cartel and REvil Code Comparison for more details). This suggests there was a relationship between the groups at some point, though it may not have been recent.
Unit 42 has also observed Ransom Cartel group breaching organizations, with the first known victims observed by us around January 2022 in the U.S. and France. Ransom Cartel has attacked organizations in the following industries: education, manufacturing, and utilities and energy. Unit 42 incident responders have also assisted clients with response efforts in several Ransom Cartel cases.
Like many other ransomware gangs, Ransom Cartel leverages double extortion techniques. Unit 42 has observed the group taking an aggressive approach, threatening not only to publish stolen data to their leak site, but also to send it to the victim’s partners, competitors and the news in an effort to inflict reputational damage.
Ransom Cartel typically gains initial access to an environment via compromised credentials, which is one of the most common vectors for initial access for ransomware operators. This includes access credentials for external remote services, remote desktop protocol (RDP), secure shell protocol (SSH) and virtual private networks (VPNs). These credentials are widely available in the cyber underground and offer threat actors a reliable means to gain access to victims' corporate networks.
These credentials can also be obtained through the work of ransomware operators themselves or by purchasing them from an initial access broker.
Initial access brokers are actors who offer to sell compromised network access. Their motivation is not to carry out cyberattacks themselves but rather to sell the access to other threat actors. Due to the profitability of ransomware, these brokers likely have working relationships with RaaS groups based on the amount they are willing to pay.
Unit 42 has seen evidence that Ransom Cartel has relied on this type of service to gain initial access for ransomware deployment.
Unit 42 has also observed Ransom Cartel encrypting both Windows and Linux VMWare ESXi servers in attacks on corporate networks.
Tactics, Techniques and Procedures Observed During Ransom Cartel Attacks
Unit 42 observed a Ransom Cartel threat actor using a tool called DonPAPI, which has not been observed in past incidents. This tool can locate and retrieve Windows Data Protection API (DPAPI) protected credentials, which is known as DPAPI dumping.
DonPAPI is used to search machines for certain files known to be DPAPI blobs, including Wi-Fi keys, RDP passwords, credentials saved in web browsers, etc. To avoid the risk of detection by antivirus (AVs) or endpoint detection and response (EDR), the tool downloads the files and decrypts them locally. To compromise Linux ESXi devices, Ransom Cartel uses DonPAPI to harvest credentials stored in web browsers used to authenticate to the vCenter web interface.
We also observed the threat actor using additional tools, including LaZagne to recover credentials stored locally and Mimikatz to steal credentials from host memory.
In order to establish persistent access to Linux ESXi devices, the threat actor enables SSH after authenticating to vCenter. The threat actor will create new accounts and sets the account’s user identifier (UID) to zero. For Unix/Linux users, a UID=0 is root. This means any security checks are bypassed.
The threat actor was observed downloading and using a cracked version of a legitimate tool called PDQ Inventory, which is a legitimate system management solution that IT administrators use to scan their network and collect hardware, software and Windows configuration data. Ransom Cartel used this as a remote access tool to establish an interactive command and control channel and to scan the compromised network.
Once a VMware ESXi server is compromised, the threat actor launches the encryptor, which will automatically enumerate the running virtual machines (VMs) and shut them down using the esxcli command. Terminating the VM processes ensures that the ransomware can successfully encrypt VMware-related files.
During encryption, Ransom Cartel specifically seeks out files with the following file extensions: .log, .vmdk, .vmem, .vswp and .vmsn. These extensions are associated with ESXi snapshots, log files, swap files, paging files and virtual disks. Post-encryption, the following file extensions have been observed: .zmi5z, .nwixz, .ext, .zje2m, .5vm8t and .m4tzt.
Ransom Notes
Unit 42 has observed two different versions of ransom notes sent by Ransom Cartel. The first note was first observed around January 2022, and the other one first appeared in August 2022. The second version appeared to be completely rewritten, as shown in Figure 1.
Figure 1. Ransom Cartel ransom notes. The note on the left was first observed in January 2022; the note on the right was first observed in August 2022.
It's interesting to note that the structure of the first ransom note used by Ransom Cartel shares similarities with a ransom note sent by REvil, as shown in Figure 2. In addition to the use of similar wording, both notes employed the same format of a 16-byte hexadecimal string for the UID.
Figure 2. Ransom Cartel ransom note shown on the left, compared to a ransom note sent by REvil shown on the right.
Ransom Cartel TOR Site
Ransom Cartel’s website for communication with victims was available via a TOR link provided in the ransom note. We’ve observed multiple TOR URLs belonging to Ransom Cartel, which likely indicates that they had been changing infrastructure and actively developing their website. A TOR private key is needed to access the website.
When the key is entered, the following page is loaded:
Figure 3. Ransom Cartel TOR site landing page.
Upon entering the TOR site through the Authorization button, a screen requesting input of the details included in the ransom note is requested.
Figure 4. Ransom Cartel website, requesting the ID and key provided in the ransom note.
Once authorization is completed on the TOR site, the page shown in Figure 5 appears. The site includes details such as ransom demand, in both US dollars and bitcoin, and the Bitcoin wallet address.
Figure 5. Ransom Cartel TOR site.
Technical Details
Two Ransom Cartel samples were used during this analysis:
File one SHA256: 55e4d509de5b0f1ea888ff87eb0d190c328a559d7cc5653c46947e57c0f01ec5 File two SHA256: 2411a74b343bbe51b2243985d5edaaabe2ba70e0c923305353037d1f442a91f5
Both of the samples contained three total exports:
Rathbuige ServiceMain SvchostPushServiceGlobals
The samples also contain a DllEntryPoint, should the DLL be executed without specifying an export. The DllEntryPoint leads to a function that iterates over a call to the Curve25519 Donna algorithm 24 times. Once the iteration ends, the sample will query the system metrics, specifically for the SM_CLEANBOOT value. If this value is anything other than 0, the ransomware will proceed to spawn another instance of itself via rundll32.exe, specifying the Rathbuige export.
SM_CLEANBOOT Values
Description
0
Normal Boot
1
Fail-Safe Boot
2
Fail-Safe with Network Boot
Table 1. SM_CLEANBOOT values.
The Rathbuige export starts by creating the following mutex:
Global\\266ee996-e1ac-4eaa-9bdb-0b639d41b32d
Once the mutex is created, the sample begins to decrypt and parse its embedded configuration. The configuration is stored as a base64-encoded blob, whereby the first 16 bytes of the base64-encoded blob is the RC4 key used for decrypting the rest of the blob once it has been decoded.
Figure 6. Ransom Cartel encrypted configuration.
Once decrypted, the configuration is stored in JSON format and consists of information such as encrypted file extension, the threat actors' public Curve25519-donna key, a base64-encoded ransom note, and a list of processes and services to terminate prior to encryption.
Figure 7. Example of decrypted Ransom Cartel configuration.
A breakdown of the keys and their values within the configuration can be seen in Table 2.
Configuration Key
Value
pk
Attacker public key
dbg
Debug mode
wht
Allow listed items
Folders to avoid
Files to avoid
Extensions to avoid
prc
Processes to terminate
svc
Services to terminate
nname
Name of ransom note file
nbody
Ransom note content
ext
Encrypted file extension
Table 2. Configuration structure.
dbsnmp
raw_agent_svc
onenote
steam
VeeamNFSSvc
synctime
infopath
msaccess
tbirdconfig
mspub
ocomm
excel
EnterpriseClient
ocssd
agntsvc
winword
ocautoupds
thebat
sql
bedbh
dbeng50
powerpnt
wordpad
xfssvccon
VeeamTransportSvc
CagService
bengien
visio
outlook
DellSystemDetect
encsvc
benetns
pvlsvr
isqlplussvc
VeeamDeploymentSvc
vsnapvss
sqbcoreservice
firefox
mydesktopservice
oracle
mydesktopqos
beserver
thunderbird
vxmon
Table 3. Targeted process list.
BackupExecVSSProvider
BackupExecManagementService
AcronisAgent
veeam
VeeamDeploymentService
ARSM
BackupExecAgentAccelerator
MSExchange$
PDVFSService
MSSQL$
VeeamTransportSvc
memtas
MSExchange
vss
stc_raw_agent
BackupExecDiveciMediaService
CAARCUpdateSvc
mepocs
svc$
WSBExchange
sophos
VSNAPVSS
MVarmor64
MSSQL
sql
BackupExecRPCService
backup
MVArmor
BackupExecAgentBrowser
VeeamNFSSvc
BackupExecJobEngine
CASAD2DWebSvc
bedbg
AcrSch2Svc
Table 4. Targeted service list.
mod
cpl
ps1
cab
com
ani
diagcab
adv
themepack
shs
sys
rom
cur
ldf
msu
mpa
spl
msi
msc
wpx
386
diagcfg
lock
prf
deskthemepack
bin
ico
diagpkg
nomedia
idx
ics
hlp
msp
msstyles
key
cmd
scr
exe
drv
hta
nls
dll
lnk
icns
ocx
theme
bat
icl
rtp
Table 5. Avoided extensions.
Following decryption of the configuration, certain system information is gathered, including the username, computer name, domain name, locale and product name. This information is then formatted into the following JSON structure:
Table 6 describes the purpose of each key within the structure.
Key
Value
ver
Version of the ransomware, hardcoded. In both samples set to 0x65 (101)
pk
Public key found within the configuration
uid
Unique identifier calculated via CRC-32 hashing certain machine information
sk
Encoded session secret
unm
Username
net
Computer name
grp
Computer domain
lng
Computer locale
bro
Does keyboard locale match any hardcoded locale value – true/false
os
Product name
bit
System architecture
dsk
Disk information
ext
Ransomware extension
Table 6. Hardcoded JSON format keys and values.
Once the gathered data has been formatted into the JSON structure, it is then encrypted using the same procedure that Ransom Cartel follows to generate session_secret blobs, which will be discussed shortly; put simply, it involves AES encryption, utilizing the SHA3 hash of a Curve25519 shared key for the AES key.
Once encrypted, it is written to the registry key SOFTWARE\\Google_Authenticator\\b52dKMhj, with the sample first attempting to write to the HKEY_LOCAL_MACHINE hive, before writing to HKEY_CURRENT_USER if the right permissions are not possessed. Once the data has been written to the registry, it is then base64-encoded and embedded within the ransom note, replacing the {KEY} placeholder.
Once the configuration has been parsed and stored within the registry, the command line provided to the ransomware is parsed. There are a total of five possible arguments, as shown in Table 7.
Argument
Description
-nolan
Instruct the sample not to attempt any form of network drive encryption
-nolocal
Prevent the encryption of all local volumes
-path
Target specific file path to encrypt
-silent
Appears to instruct the ransomware to avoid terminating running processes and services, and it begins encrypting files immediately
-smode
Causes the ransomware to use BCEdit in order to enable Safe Boot; check out this article on REvil’s use of “Windows Safe Mode” encryption for a discussion about this particular technique.
Table 7. Ransom Cartel accepted arguments.
With that, let’s move on to analyzing the session secret generation procedure.
Ransom Cartel first checks to see if the registry already contains previously generated values; if so, it will read those values into memory. Otherwise, it will generate a total of two session secrets at runtime, with each secret containing 88 bytes of data.
First, a public and private key pair will be generated using the code from this Curve25519 repository (session_public_1 and session_private_1). When generating the first session secret, another session key pair is generated, (session_public_2 and session_private_2) and session_private_2 is paired with attacker_cfg_public (the public key embedded within the configuration) to generate a shared key. This shared key is then hashed with the SHA3 hashing algorithm. The resulting hash is used as an AES key with a random 16-byte initialization vector (IV) for encrypting a data blob consisting of four null bytes followed by session_private_1.
Figure 8. Diagram of session secret generation procedure.
From there, the encrypted blob is hashed using CRC-32, and then appended with the values session_public_2, the AES IV, and the calculated CRC-32 hash. The resulting value is session_secret_1. The second generated session secret follows the exact same procedure; however, instead of using attacker_cfg_public, it utilizes an embedded public key (attacker_embedded_public_1) within the binary to generate the shared key.
One final embedded public key (attacker_embedded_public_2) is used to encrypt the data formatted into the JSON structure described above.
This method of generating session secrets was documented by researchers at Amossys back in 2020; however, their analysis focused on an updated version of Sodinokibi/REvil ransomware, indicating a direct overlap between the REvil source code and the latest Ransom Cartel samples.
Once the session secrets have been generated, they are written to the registry, alongside session_public_1 and attacker_cfg_public.
Path
Name
Value
SOFTWARE\\Google_Authenticator\\
WRZfsL
attacker_cfg_public
SOFTWARE\\Google_Authenticator\\
RB4y
session_public_1
SOFTWARE\\Google_Authenticator\\
Kbcn0
session_secret_1
SOFTWARE\\Google_Authenticator\\
BSjHn
session_secret_2
Table 8. Registry paths and values used by Ransom Cartel.
At this point, all the required information is gathered and generated so that file encryption can begin.
For each file, a unique file public and private key pair are generated (file_public_1 and file_private_1), once again using Curve25519 Donna. file_private_1 and session_public_1 are paired together to generate a shared key, which is hashed using SHA3. The generated hash is used as the encryption key for Salsa20 (a symmetric encryption algorithm), and a random eight-byte nonce is generated using CryptGenRandom. The CRC-32 hash of file_public_1 is calculated, and then four null bytes are encrypted using the generated Salsa20 matrix.
Certain elements of the above data are then retained and used as part of the encrypted file footer; each file footer is 232 bytes in length and is made up of the following:
session_secret_1 (88 bytes)
session_secret_2 (88 bytes)
file_public_1 (32 bytes)
salsa_nonce (eight bytes)
crc_file_public_1 (four bytes)
encryption_type (four bytes)
block_spacing (four bytes)
encrypted_null (four bytes)
Similarly to the session_secret generation, this structure is identical to that of the REvil samples analyzed by Amossys, further showing that there have been very few changes to the REvil source code when developing Ransom Cartel samples.
Figure 10. File encryption setup process.
Ransom Cartel and REvil Code Comparison
The Ransom Cartel samples analyzed revealed similarities with REvil ransomware.
The first notable similarity between Ransom Cartel and REvil is the structure of the configuration. Examining a sample of REvil from 2019 (SHA256: 6a2bd52a5d68a7250d1de481dcce91a32f54824c1c540f0a040d05f757220cd3), the resemblance can be seen. However, the storage of the encrypted configuration is slightly different, opting to store the configuration in a separate section within the binary (.ycpc19), with an initial 32-byte RC4 key followed by the raw encrypted configuration, whereas with the Ransom Cartel samples, the configuration is stored within the .data section as a base64-encoded blob.
Figure 11. REvil configuration storage.
Once the REvil configuration has decrypted, it utilizes the same JSON format, but contains additional values such as pid, sub, fast, wipe and dmn. These values indicate additional functionality within the REvil sample, which could mean that either the Ransom Cartel developers removed certain functionality or they are building off of a much earlier version of REvil.
Figure 12. Decrypted REvil configuration.
As discussed previously, another major overlap is the code reuse across the two samples of Ransom Cartel. Both use an identical encryption scheme, generating multiple public/private key pairs, and creating session secrets using the same procedure found within REvil samples.
Both use Salsa20 and Curve25519 for file encryption, and there are very few differences in the layout of the encryption routine besides the structure of the internal type structs.
Figure 14. REvil file encryption setup function.
A particularly interesting difference between the two malware families is that REvil opts to obfuscate their ransomware much more heavily than the Ransom Cartel group, utilizing string encryption, API hashing and more, while Ransom Cartel has almost no obfuscation outside of the configuration, hinting that the group may not possess the obfuscation engine used by REvil.
It is possible that the Ransom Cartel group is an offshoot of the original REvil threat actor group, where the individuals only possess the original source code of the REvil ransomware encryptor/decryptor, but do not have access to the obfuscation engine.
Ransom Cartel Tactics, Techniques and Procedures
Below is a list of TTPs observed being used by Ransom Cartel affiliates:
TTPs
Notes
TA0001 Initial Access
T1078. Valid Accounts
Uses legitimate VPN, RDP, Citrix or VNC credentials to maintain access to an environment.
T1133. External Remote Services
Uses legitimate VPN or Citrix credentials to maintain access to an environment.
TA0002 Execution
T1072. Software Deployment Tools
Deploys PDQ Inventory Scanner tool.
T1059.001. Command and Scripting Interpreter: PowerShell
Uses PowerShell to retrieve the malicious payload and download additional resources such as Mimikatz and Rclone.
T1059.003 Command and Scripting Interpreter: Windows Command Shell
Uses cmd.exe to execute commands.
TA0003 Persistence
T1003.008. OS Credential Dumping: /etc/passwd and /etc/shadow
Attempts to dump the contents of /etc/passwd and /etc/shadow to enable offline password cracking.
T1136.001. Create Account: Local Account
Creates new users’ accounts.
T1098. Account Manipulation
Adds newly created accounts to the administrators group to maintain elevated access.
T1547.001. Boot or Logon Autostart Execution: Registry Run Keys/Startup Folder
Adds registry run keys to achieve persistence. In some cases, we observed using the following command: start cmd.exe /k runonce.exe /AlternateShellStartup
T1197. BITS Jobs
Uses BITSAdmin to download and install payloads.
TA0004 Privilege Escalation
T1068. Exploitation for Privilege Escalation
Exploits Print Nightmare vulnerability.
TA0005 Defense Evasion
T1222.002. File and Directory Permissions Modification: Linux and Mac File and Directory Permissions Modification
Uses the chmod +x command to grant executable permissions to the ransomware.
T1112. Modify Registry
Modifies the Registry to disable UAC remote restrictions by setting SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy to 1.
T1070.001 Indicator Removal on Host: Clear Windows Event Logs
Uses wevtutil to clear the Windows event logs.
T1218.011. System Binary Proxy Execution: Rundll32
Uses Rundll32 to load and execute malicious DLL.
T1562.004. Impair Defenses: Disable or Modify System Firewall
Deletes rules in the Windows Defender Firewall exception list related to AnyDesk
T1070.004. Indicator Removal on Host: File Deletion
Deletes some of its files used during operations as part of cleanup, including removing applications such as 7z.exe, tor.exe, ssh.exe
T1070.003. Indicator Removal on Host: Clear Command History
Clears Windows PowerShell and WitnessClientAdmin log file.
T1027. Obfuscated Files or Information
Uses encoded PowerShell commands.
TA0006 Credential Access
T1003.001. OS Credential Dumping: LSASS Memory
Uses Mimikatz to harvest credentials.
T1555.003. Credentials from Password Stores: Credentials from Web Browsers
Compromises users’ saved passwords from browsers.
TA0007 Discovery
T1046. Network Service Discovery
Uses tools such as PDQ Inventory scanner, Advanced Port Scanner and netscan (which also scanned for the ProxyShell vulnerability).
T1083. File and Directory Discovery
Searches for specific files prior to encryption.
T1135. Network Share Discovery
Enumerates remote open SMB network shares
T1087.001. Account Discovery: Local Account
Accesses ntuser.dat and /etc/passwd to enumerate all accounts.
TA0008 Lateral Movement
T1021.004. Remote Services: SSH
Uses Putty for remote access.
T1550.002. Use Alternate Authentication Material: Pass the Hash
Dumps password hashes for use in pass the hash authentication attacks.
T1560.001. Archive Collected Data: Archive via Utility
Uses 7-Zip to compress stolen data for exfiltration.
TA0010 Exfiltration
T1567.002. Exfiltration Over Web Service: Exfiltration to Cloud Storage
Uses Rclone to exfiltrate data to cloud sharing websites (such as PCloud and MegaSync).
TA0011 Command and Control
T1219. Remote Access Software
Uses AnyDesk to remotely connect and transfer files.
T1090.003. Proxy: Multi-hop Proxy
Routes traffic over TOR and VPN servers to obfuscate their activities.
T1105. Ingress Tool Transfer
Downloads and uploads files to and from the victim’s machine.
TA0040 Impact
T1486. Data Encrypted for Impact
Encrypts system data and adds the random extension to encrypted files. The following extensions have been observed (.zmi5z, .nwixz, .ext, .zje2m, .5vm8t, .m4tzt).
Table 9. Tactics, techniques and procedures for Ransom Cartel activity.
Malware, Tools and Exploits Used
Execution
Credential Access
Discovery
Privilege Escalation
Lateral Movement
Command and Control
Exfiltration
PowerShell
Windows command shell
Mimikatz LaZagne DonPAPI
PDQ Inventory scanner Advanced Port Scanner netscan.exe
Print Nightmare
Putty
AnyDesk Cobalt Strike
Rclone
Table 10. Malware, tools and exploits used.
Conclusion
Ransom Cartel is one of many ransomware families that surfaced during 2021. While Ransom Cartel uses double extortion and some of the same TTPs we often observe during ransomware attacks, this type of ransomware uses less common tools – DonPAPI for example – that we haven’t observed in any other ransomware attacks.
Based on the fact that the Ransom Cartel operators clearly have access to the original REvil ransomware source code, yet likely do not possess the obfuscation engine used to encrypt strings and hide API calls, we speculate that the operators of Ransom Cartel had a relationship with the REvil group at one point, before starting their own operation.
Due to the high-profile nature of some organizations targeted by Ransom Cartel and steady stream of Ransom Cartel cases identified by Unit 42, the operator and/or affiliates behind the ransomware likely will continue to attack and extort organizations.
Palo Alto Networks customers receive help with detection and prevention of Ransom Cartel ransomware in the following ways:
WildFire: All known samples are identified as malware.
185.239.222[.]240 TOR Exit Node 108.62.103[.]193 TOR Exit Node 185.129.62[.]62 TOR Exit Node 185.143.223[.]13 Bulletproof hosting server 185.253.163[.]23 PIA VPN exit node
Indicators of compromise and Ransom Cartel-associated TTPs can be found in the Ransom Cartel ATOM.
Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
In early August, GTSC discovered a new Microsoft Exchange zero-day remote code execution (RCE) that was very similar to ProxyShell (CVE-2021-34473, CVE-2021-34523 and CVE-2021-31207).
The exploit was discovered in the wild in what appeared to be a SOC investigation into suspicious activity of one of GTSC’s customers. Once they determined the scope of the vulnerabilities, GTSC reported the vulnerability to the Zero-day Initiative (ZDI) to enable further coordination with Microsoft. The vulnerabilities were assigned CVE-2022-41040 and CVE-2022-41082 and rated with severities of critical and important respectively. The first one, identified as CVE-2022-41040, is a server-side request forgery (SSRF) vulnerability, while the second one, identified as CVE-2022-41082, allows remote code execution (RCE) when Exchange PowerShell is accessible to the attacker.
The exploit does require authentication; however, the authentication required is that of a standard user and, based on how easy it is to collect user credentials these days, this is not a high bar to overcome. Microsoft has yet to release a patch for these vulnerabilities. In the meantime, they provided mitigations in a blog responding to GTSC’s disclosure of these vulnerabilities.
Palo Alto Networks customers receive protections from and mitigations for ProxyNotShell in the following ways:
Next-Generation Firewalls or Prisma Access with a Threat Prevention security subscription can block sessions related to CVE-2022-41040.
A Cortex XSOAR response pack and playbook can automate the mitigation process.
Cortex Xpanse can help identify and detect Microsoft Exchange servers that may be a part of your attack surface.
Cortex XDR will report related exploitation attempts.
XQL queries provided below can be used with Cortex XDR to help track attempts to exploit these CVEs.
Malicious URLs and IPs have been added to Advanced URL Filtering.
The Unit 42 Incident Response team can provide personalized assistance.
GTSC’s SOC discovered the following URL requests in a customer’s Microsoft Internet Information Services (IIS) logs:
The URL requests appear to be identical to the ProxyShell requests seen last year. Compare the above request with the following excerpt from Mandiant’s blog reporting on the discovery of ProxyShell last year, and you’d think this must be an unpatched server exploited by ProxyShell.
GTSC reviewed the Exchange server version and confirmed the Exchange servers were up to date and the vulnerabilities were indeed new zero days. GTSC also confirmed the attackers were able to get PowerShell execution during the attack. This also resembles ProxyShell. Once attackers gained access to the server, they installed webshells to obtain persistent access to the network. GTSC reported the vulnerability to the Zero-day Initiative (ZDI) to enable further coordination with Microsoft. The vulnerabilities were assigned CVE-2022-41040 and CVE-2022-41082 and rated with severities of critical and important respectively. The first one, identified as CVE-2022-41040, is a server-side request forgery (SSRF) vulnerability, while the second one, identified as CVE-2022-41082, allows remote code execution (RCE) when Exchange PowerShell is accessible to the attacker.
Please refer to GTSC’s excellent blog for details on the webshells, malware analysis, indicators of compromise (IoCs) and commands discovered during their investigation. Microsoft has stated that the vulnerabilities affect Microsoft Exchange Server 2013, Exchange Server 2016 and Exchange Server 2019. They also state that “Exchange Online has detections and mitigations to protect customers. As always, Microsoft is monitoring these detections for malicious activity and we’ll respond accordingly if necessary to protect customers.”
Current Scope of the Attack
It does appear there are multiple victims of this attack. However, from what has been publicly reported, the attacks still seem to remain isolated. GTSC stated in their blog, “GTSC's direct incident response process recorded more than one organization being the victims of an attack campaign exploiting this 0-day vulnerability.”
Microsoft, in a blog response to GTSC’s, stated “MSTIC observed activity related to a single activity group in August 2022 that achieved initial access and compromised Exchange servers by chaining CVE-2022-41040 and CVE-2022-41082 in a small number of targeted attacks.”
Both GTSC and Microsoft’s observed attacks used the China Chopper webshell and Microsoft’s MSTIC attributes the attacks, with medium confidence, to one attack group. Although the attacks still appear to be isolated, based on the history of ProxyShell and the difficulty of patching Exchange servers, we believe this vulnerability will garner widespread attention from threat groups. Therefore, we expect working exploits and proofs of concept (PoCs) will soon be available to aid in the exploitation of these vulnerabilities. That being said, Unit 42 has not yet seen any evidence of attempted exploitation within our customer telemetry.
Interim Guidance
Microsoft has yet to release a patch for these vulnerabilities. In the meantime, they provided mitigations that rely on the usage of a URL Rewrite rule to identify and block exploitation attempts as well as disabling remote PowerShell access for non-admins.
GTSC provided the same guidance in their blog as well. If you feel you may have been targeted and keep IIS logs, GTSC recommends running the following PowerShell command to search for evidence of attempted exploitation of your Exchange servers:
Cortex XDR customers can search for signs of exploitation by employing the queries included in the following section of this brief. The queries include evidence of certutil connections to public IPs, evidence of DLL and EXE writes to C:\Users\Public\, evidence of China Chopper webshell activity, and the addition of suspicious files to Exchange directories.
Unit 42 Managed Threat Hunting Queries
The Unit 42 Managed Threat Hunting team continues to track any attempts to exploit these CVEs across our customers, using Cortex XDR and the XQL queries below. Cortex XDR customers can also use these XQL queries to search for signs of exploitation.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// Description: Detect certutil netcons to public IP addresses. May be observed
// post-exploit in latest Exchange 0-day attacks for connection checks
Based on the amount of publicly available information, the ease of use and the extreme effectiveness of this exploit, Palo Alto Networks highly recommends following Microsoft’s guidance to protect your organization until a patch is issued to fix the problem. Palo Alto Networks and Unit 42 will continue to monitor the situation for updated information, release of proof-of-concept code and evidence of more widespread exploitation.
Palo Alto Networks customers can leverage a variety of product protections and updates to identify and defend against this threat.
Next-Generation Firewalls (PA-Series, VM-Series and CN-Series) or Prisma Access with an Advanced Threat Prevention security subscription can automatically block sessions related to CVE-2022-41040 using Threat ID 91368 (Application and Threat content update 8624).
Cortex XSOAR has released a response pack and playbook for the ProxyNotShell CVEs to help automate and speed the mitigation process.
This playbook automates the following tasks:
Collection of Microsoft mitigation tools, detection rules and Microsoft Global Technical Support Center (GTSC) indicators
Extraction of these indicators and tagging to incidents
Hunting for exploitation patterns using Cortex XDR-XQL queries
Hunting for exploitation patterns using the following SIEM products:
Azure Sentinel
Splunk
QRadar
Elasticsearch
Indicator hunting using PAN-OS, Splunk and QRadar
Mitigation actions such as deploying detection rules and recommended workarounds
Figure 1. Portion of the playbook illustrating collection and extraction of indicators and rules.Figure 2. Portion of the playbook illustrating SIEM threat hunting.Figure 3. Portion of the playbook illustrating Cortex XDR-XQL Threat Hunting.
Cortex Xpanse has the ability to identify and detect Microsoft Exchange servers that may be a part of your attack surface or the attack surface of third-party partners connected to your organization.
Cortex XDR agent running on version 7.7 with content version 710-19877 and above will report the exploitation attempt of the exploitation chain that we have identified.
To ensure you are receiving alerts and monitoring any exploitation attempts:
Verify that you are using Cortex XDR agent version 7.7 (or newer)
Verify that your agent is on content update 710-19877 (or newer)
Perform an agent heartbeat
Restart Microsoft Internet Information Services (IIS) using the command: “iisreset”
A new Behavioral Threat Protection (BTP) rule has been added to notify XDR customers about exploitation attempts:
As part of the Cortex XDR multi-layer protection approach, additional already existing Behavioral Threat Protection rules are capable of detecting and preventing the dropping of malicious webshells from a Microsoft Exchange server; those will come into effect until the rule above goes into block mode in the near future.
If you think you may have been compromised or have an urgent matter, you can get in touch with the Unit 42 Incident Response team or call:
North America Toll-Free: 866.486.4842 (866.4.UNIT42)
EMEA: +31.20.299.3130
APAC: +65.6983.8730
Japan: +81.50.1790.0200
As further information emerges or additional detections and protections are put into place, Palo Alto Networks will update this publication accordingly.
Unit 42 recently observed a polyglot Microsoft Compiled HTML Help (CHM) file being employed in the infection process used by the information stealer IcedID. We will show how to analyze the polyglot CHM file and the final payload so you can understand how the sample evades detection.
Multiple attack groups such as Starchy Taurus (aka APT41) and Evasive Serpens (formerly tracked as OilRig, also known as Europium) have abused CHM files to conceal payloads written using PowerShell or JavaScript. Here, we describe an interesting attack that allows attackers to avoid the need for long lines of code, which can make it easier for malicious files to evade detection by security products. Polyglot files can be abused by attackers to hide from anti-malware systems that rely on file format identification. The technique involves executing the same CHM file twice in the infection process. The first execution exhibits benign activities, while the second execution stealthily carries out malicious behaviors.
This particular attack chain was discovered in early August 2022 and delivered IcedID, also known as Bokbot, as the final payload. This information stealer, IcedID, is well-known malware that has been attacking users since 2019.
Polyglot files are binaries that have multiple different file format types. The file would have a different behavior depending on the application that was used to execute it.
The attack that was discovered in early August 2022 starts with a phishing email that includes an attached zip file named erosstrucking-file-08.08.2022.zip. The zip file decompresses into an ISO image file named order-130722.28554.iso. Inside the ISO file is a CHM file called pss10r.chm (SHA256: 3d279aa8f56e468a014a916362540975958b9e9172d658eb57065a8a230632fa). The polyglot CHM file is used to display help documentation. When the user launches the CHM file (pss10r.chm), a harmless help window is displayed.
Figure 1. Decoy HTML help window.
To dump the contents of the CHM file, we used 7zip. The file of interest is PSSXMicrosoftSupportServices_HP05221271.htm.
Figure 2. Contents of the decoy HTML help window.
Most of the code in the HTML file is used for generating the decoy window. However, concealed within the HTML code is a single-line command to execute the same CHM file again. The command calls Mshta.exe to execute itself (pss10r.chm) a second time. Mshta.exe is a utility that executes Microsoft HTML Application (HTA) files. HTAs are full-fledged applications created using HTML.
Figure 3. A line of HTML code in PSSXMicrosoftSupportServices_HP05221271.htm that calls Mshta.exe to execute the CHM file a second time.
The code of the HTA is buried within the binary of the CHM file and configured to be invisible to the victim during execution. The HTA is used to execute the binary app.dll.
Figure 4. HTA code buried in pss10r.chm.
The binary app.dll is actually hidden within the ISO image. The hidden binary can be revealed using the attrib command.
Figure 5. Revealing the hidden binary.
The app.dll binary is a 64-bit IcedID DLL. (SHA256: d240bd25a0516bf1a6f6b3f080b8d649ed2b116c145dd919f65c05d20fc73131)
IcedID DLL’s Configuration Extraction
To retrieve the indicators of compromise (IoCs) from the IcedID DLL, we looked at its configuration. The IcedID DLL’s configuration is encoded and stored in the data section of the binary. The encoded configuration has the format shown in Figure 6.
Figure 6. Structure of encoded configuration blob.
The following function would decode the IcedID DLL’s configuration at runtime. The address of the encoded configuration (enc_config) is in the function.
The decoded IcedID DLL’s configuration has the following format.
Figure 8. Structure of decoded IcedID configuration.
From the decoded configuration, we can extract the following IoCs:
Command and Control URL
abegelkunic[.]com
Campaign ID
4157420015
Conclusion
Threat actors continue to evolve their techniques to evade detection. The above analysis demonstrates how attackers abused a polyglot Microsoft Compiled HTML file to deliver an IcedID payload. It is important for defenders not to trust binaries based on their file types since polyglot files such as the one discussed here have more than one correct file type.
Malware authors regularly evolve their techniques to evade detection and execute more sophisticated attacks. We’ve commonly observed one method over the past few years: unsigned DLL loading.
Assuming that this method might be used by advanced persistent threats (APTs), we hunted for it. The hunt revealed sophisticated payloads and APT groups in the wild, including the Chinese cyberespionage group Stately Taurus (formerly known as PKPLUG, aka Mustang Panda) and the North Korean Selective Pisces (aka Lazarus Group).
Below, we show how hunting for the loading of unsigned DLLs can help you identify attacks and threat actors in your environment.
Palo Alto Networks customers receive protections and detections against malicious DLL loading through the Cortex XDR agent.
Threat Actor Groups Discussed
Unit 42 tracks group as…
Group also known as…
Stately Taurus
Mustang Panda, PKPLUG, BRONZE PRESIDENT, HoneyMyte, Red Lich, Baijiu
Selective Pisces
Lazarus Group, ZINC, APT - C - 26
Malicious DLLs: A Common Method Attackers Use for Executing Malicious Payloads on Infected Systems
Based on our observations over years of proactive threat-hunting experience, we hypothesize that one of the main methods for executing malicious payloads on infected systems is loading a malicious DLL. As both individual hackers and APT groups use this method, we decided to conduct research based on this hypothesis.
Most of the malicious DLLs we observe in the wild share three common characteristics:
The DLLs are mostly written to unprivileged paths.
The DLLs are unsigned.
To evade detection, the DLLs are loaded by a signed process, whether a utility dedicated to loading DLLs (such as rundll32.exe) or an executable that loads DLLs as part of its activity.
With that in mind, we found that the most common techniques that are being used by threat actors in the wild are the following:
DLL loading by rundll32.exe/regsvr32.exe– While those processes are signed and known binaries, threat actors abuse them to achieve code execution in an attempt to evade detection.
DLL order hijacking – This refers to loading a malicious DLL by abusing the search order of a legitimate process. This way, a benign application will load a malicious payload with the name of a known DLL.
Reviewing the results of the above techniques in the wild revealed that the most common unprivileged paths to load malicious unsigned DLLs are the folders and sub-folders of ProgramData, AppData and the users’ home directories.
The next section will introduce several findings based on the above hypothesis.
Attack Trends in the Wild Related to Unsigned DLLs
To start hunting based on the hypothesis we described, we created two XQL queries. The first one looks for unsigned DLLs that were loaded by rundll32.exe/regsvr32.exe, while the other looks for signed software that loads an unsigned DLL.
The hunting activity revealed various malware families that used unsigned DLL loading. Figure 1 presents the malware we detected using these methods over the past six months (February-August 2022).
Figure 1. Malware observed using DLL loading.
Analyzing the execution techniques used by the above threats showed that banking trojans and individual threat actors typically used rundll32.exe or regsvr32.exe to load a malicious DLL, while APT groups used the DLL side-loading technique most of the time.
Diving Into Selected Payloads
Stately Taurus
We decided to highlight an investigation around Stately Taurus activity that we detected in the environment of one organization. Stately Taurus is a Chinese APT group that usually targets non-governmental organizations and is known for abusing legitimate software to load payloads.
In this case, we observed the usage of the DLL search order hijacking technique that enabled the attacker’s malicious DLL to load into the memory space of a legitimate process. The threat actor used multiple pieces of third party software for the DLL side-loading, such as antivirus software and a PDF reader.
Figure 2. AvastSvc.exe uses side-loading to load a malicious DLL.
To achieve DLL side-loading, the group dropped the payload into the ProgramData folder, which contained three files – a benign EXE file for DLL hijacking (AvastSvc.exe), a DLL file (wsc.dll) and an encrypted payload (AvastAuth.dat). The loaded DLL appeared to be the PlugX RAT, which loads the encrypted payload from the .dat file.
Among the results of our hunting queries, we also identified several high-entropy malicious modules within the ProgramData directories shown in Figure 4.
Figure 4. DLL side-loading by Selective Pisces.
Investigating the execution chain of the unsigned modules shown in Figure 4 revealed that they were dropped to the disk by the signed DreamSecurity MagicLine4NX process (MagicLine4NX.exe).
MagicLine4NX.exe executed a second-stage payload that we observed utilizing DLL side-loading in order to evade detection. The second-stage payload wrote a new DLL named mi.dll, and copied wsmprovhost.exe (host process for WinRM) to a random directory in ProgramData. Wsmprovhost.exe is a native Windows binary that attempts to load mi.dll from the same directory. The attackers abused this mechanism in order to achieve DLL side-loading (T1574.002) with this process.
The mi.dll payload was observed dropping a new payload named ualapi.dll to the System32 directory (C:\Windows\System32\ualapi.dll). As ualapi.dll is in this case a missing DLL on the System32 directory, the attackers used this fact to achieve persistence by giving their malicious payload the name ualapi.dll. That way, spoolsv.exe will load it upon startup.
After analyzing the payloads above, we attributed them to the North Korean APT group that Unit 42 tracks as Selective Pisces. This group’s utilization of legitimate third party-software such as MagicLine4NX was described earlier this year in a blog post by Symantec.
Raspberry Robin
The last attack we would like to elaborate on is the most common one we observed in the wild.
Some of the results that our query yields share several common characteristics:
DLLs with scrambled names reside in random sub-folders of the ProgramData or AppData folders.
Those DLLs have a similar range of entropy (~0.66).
All of them were loaded by rundll32.exe or regsvr32.exe
For example: RUNDLL32.EXE C:\ProgramData\<random_folder>\fhcplow_Tudjdm.dll,iarws_sbv
Figure 5. DLLs loaded by Raspberry Robin.
The DLL loading activities that take place in those attacks were attributed to a campaign called Raspberry Robin, which was recently described by Red Canary.
Those attacks begin from a shortcut file on an infected USB device. This spawns msiexec.exe to retrieve the malicious DLL from a remote C2 server. Over installation, a scheduled task is created in order to achieve persistence, loading the DLL using rundll32.exe/regsvr32.exe on system start up.
Using Unsigned DLLs to Hunt for Attacks in Your Environment
You can hunt for the loading of unsigned DLLs using XQL Search in Cortex XDR.
To narrow down the results, we suggest focusing on the following:
For DLL side-loading, we recommend paying attention to known third-party software placed in non-standard directories.
Focus on the file’s entropy – binaries that have a high value of entropy may contain a packed section that will be extracted during execution.
Focus on the frequency of execution – high-frequency results may indicate a legitimate activity that occurs periodically, while low-frequency results may be a lead for an investigation.
Focus on the file’s path – results that contain folders or files with scrambled names are more suspicious than others.
Figure 6. Query results sorted by the module’s entropy.
Figure 6 contains partial results of the queries that are mentioned in the next section, sorted by the module’s entropy. While the first two rows are an example of Emotet execution, the others are benign DLLs.
Hunting Queries
1
2
3
4
5
6
7
8
9
// Rundll32.exe / Regsvr32.exe loads an unsigned module from uncommon folders over the past 30 days.
|comp count(action_module_path)ascounter by action_module_path,action_module_sha256,module_entropy,actor_process_image_path
Conclusion
Most detection techniques for blocking malicious DLLs rely on the module's behavior after it has been loaded into memory. This can limit the ability to block all malicious modules.
That said, you can proactively hunt for malicious unsigned DLLs using hunting approaches such as the ones presented in this blog.
Knowing the baseline of your network in terms of legitimate software or behavior can reduce the number of results generated by the above queries, allowing you to focus on results that might be suspicious.
Cortex XDR alerts on and blocks malicious DLLs loaded by known hijacking techniques, and can also prevent post-exploitation activities, through the Behavioral Threat Protection and Analytics modules.
Indicators of compromise and TTPs associated with Stately Taurus can be found in the Stately Taurus ATOM.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call North America Toll-Free: 866.486.4842 (866.4.UNIT42), EMEA: +31.20.299.3130, APAC: +65.6983.8730, or Japan: +81.50.1790.0200.
Cybercriminals compromise domain names to attack the owners or users of the domains directly, or use them for various nefarious endeavors, including phishing, malware distribution, and command and control (C2) operations. A special case of DNS hijacking is called domain shadowing, where attackers stealthily create malicious subdomains under compromised domain names. Shadowed domains do not affect the normal operation of the compromised domains, making it hard for victims to detect them. The inconspicuousness of these subdomains often allows perpetrators to take advantage of the compromised domain’s benign reputation for a long time.
Current threat research-based detection approaches are labor-intensive and slow as they rely on the discovery of malicious campaigns that use shadowed domains before they can look for related domains in various data sets. To address these issues, we designed and implemented an automated pipeline that can detect shadowed domains faster on a large scale for campaigns that are not yet known. Our system processes terabytes of passive DNS logs every day to extract features about candidate shadowed domains. Building on these features, it uses a high-precision machine learning model to identify shadowed domain names. Our model finds hundreds of shadowed domains created daily under dozens of compromised domain names.
Emphasizing the difficulty of discovering shadowed domains, we found that only 200 domains were marked as malicious by vendors on VirusTotal out of 12,197 shadowed domains automatically detected by us between April 25 and June 27, 2022. As an example, we give a detailed account of a phishing campaign leveraging 649 shadowed subdomains under 16 compromised domains such as bancobpmmavfhxcc.barwonbluff.com[.]au and carriernhoousvz.brisbanegateway[.]com. The perpetrators leveraged the benign reputation of these domains to spread fake login pages harvesting credentials. VT vendor performance is much better for this specific campaign, marking as malicious 151 out of the 649 shadowed domains – but still less than one quarter of all the domains.
Cybercriminals use domain names for various nefarious purposes, including communication with C2 servers, malware distribution, scams and phishing. To help perpetrate these activities, crooks can either purchase domain names (malicious registration) or compromise existing ones (DNS hijacking/compromise). Avenues for criminals to compromise a domain name include stealing the login credential of the domain owner at the registrar or DNS service provider, compromising the registrar or DNS service provider, compromising the DNS server itself, or abusing dangling domains.
Domain shadowing is a subcategory of DNS hijacking, where attackers attempt to stay unnoticed. First, cybercriminals stealthily insert subdomains under the compromised domain name. Second, they keep existing records to allow the normal operation of services such as websites, email servers and any other services using the compromised domain. By ensuring the undisturbed operation of existing services, the criminals make the compromise inconspicuous to the domain owners and the cleanup of malicious entries unlikely. As a result, domain shadowing provides attackers access to virtually unlimited subdomains inheriting the compromised domain’s benign reputation.
When attackers change the DNS records of existing domain names, they aim to target the owners or users of these domain names. However, criminals often use shadowed domains as part of their infrastructure to support endeavors such as generic phishing campaigns or botnet operations. In the case of phishing, crooks can use shadowed domains as the initial domain in a phishing email, as an intermediate node in a malicious redirection (e.g., in a malicious traffic distribution system), or as a landing page hosting the phishing website. In the case of botnet operations, a shadowed domain can be used, for example, as a proxy domain to conceal C2 communication.
In Table 1, we collect example shadowed domains used as part of a recent phishing campaign automatically discovered by our detector. The attackers compromised several domain names that have existed for many years and thus built up a good reputation. We can observe that the IP addresses of these domains (and IPs of their benign subdomains) are located in either Australia (AU) or the United States (US). Suspiciously, all the shadowed domains have IP addresses located in Russia (RU) – a different country and autonomous system from the parent domains. Furthermore, all shadowed domains in this campaign use an IP address from the same /24 IP subnet (the first three numbers are the same in the IP address). An additional indicator of malice we noticed is that all the malicious subdomains shown were activated around the same time and were operational for a relatively short period.
FQDN
IP Address
CC
First Seen
Last Seen
Time Active*
halont.edu[.]au
103.152.248[.]148
AU
2020-11-23
2022-06-28
~ 9 years
training.halont.edu[.]au
103.152.248[.]148
AU
2020-12-08
2021-05-02
~ 7 years
training.halont.edu[.]au**
62.204.41[.]218
RU
2022-04-17
2022-05-06
< 1 month
ocwdvmjjj78krus.halont.edu[.]au
62.204.41[.]218
RU
2022-04-04
2022-04-04
< 1 day
baqrxmgfr39mfpp.halont.edu[.]au
62.204.41[.]218
RU
2022-04-01
2022-04-01
< 1 day
barwonbluff.com[.]au
27.131.74[.]5
AU
2018-12-13
2022-06-28
~ 19 years
bancobpmmavfhxcc.barwonbluff.com[.]au
62.204.41[.]247
RU
2022-03-07
2022-06-06
~ 3 months
tomsvprfudhd.barwonbluff.com[.]au
62.204.41[.]77
RU
2022-03-07
2022-03-07
< 1 day
brisbanegateway[.]com
101.0.112[.]230
AU
2015-04-23
2022-06-24
~ 12 years
carriernhoousvz.brisbanegateway[.]com
62.204.41[.]218
RU
2022-03-07
2022-03-08
~ 2 days
vembanadhouse[.]com
162.215.253[.]110
US
2019-09-04
2022-06-28
~ 17 years
wiguhllnz43wxvq.vembanadhouse[.]com
62.204.41[.]218
RU
2022-03-25
2022-03-25
< 1 day
Table 1. Example of compromised domains and their shadowed subdomains. *Time active column is based on the time first seen in pDNS, Whois, or archive.org. **It seems that the subdomain training.halont.edu[.]au was deactivated, and later the attacker accidentally hijacked it via DNS wildcarding. FQDN stands for Fully Qualified Domain Name and CC stands for the country-code of the IP address.
How to Detect Domain Shadowing
To address issues with threat hunting-based approaches to detect shadowed domains – such as lack of coverage, delay in detection and the need for human labor – we designed a detection pipeline leveraging passive DNS traffic logs (pDNS) based on work by Liu et al. Building on observations similar to the ones discussed in Table 1, we extracted over 300 features that could signal potential shadowed domains. Using these features, we trained a machine learning classifier that is the core of our detection pipeline.
Design Approach for the Machine Learning Classifier
We can arrange the features into three groups – those specific to the candidate shadowed domain itself, those related to the candidate shadowed domain’s root domain and those related to the IP addresses of the candidate shadowed domain.
The first group is specific to the candidate shadowed domain itself. Examples of these FQDN-level features include:
Deviation of the IP address from the root domain’s IP (and its country/autonomous system).
Difference in the first seen date compared to the root domain’s first seen date.
Whether the subdomain is popular.
The second feature group describes the candidate shadowed domain's root domain. Examples are:
The ratio of popular to all subdomains of the root.
The average IP deviation of subdomains.
The average number of days subdomains are active.
The third group of features is about the IP addresses of the candidate shadowed domain, for example:
The apex domain to FQDN ratio on the IP.
The average IP country deviation of subdomains using that IP.
As we generate over 300 features – where many of them are highly correlated – we perform feature selection in order to use only the features that will contribute most to the machine learning classifer’s performance. We use the Chi-squared test to find the best features individually and mutual Pearson correlation to decrease the weight of highly correlated features.
We can select classifiers with different performance and complexity tradeoffs depending on the desired use case. Using a random forest classifier, we can achieve 99.99% accuracy, 99.92% precision and 99.87% recall using only the 64 best features and allowing each of 200 trees in the random forest to use at most eight features and to have a maximum depth of four. A simpler classifier – using only the top 32 features where each tree can only use at most four features and have a depth of two – can achieve 99.78% accuracy, 99.87% precision and 92.58% recall.
During a two-month period, our classifier found 12,197 shadowed domains averaging a couple hundred detections every day. Looking at these domains in VirusTotal, we find that only 200 were marked as malicious by at least one vendor. We conclude from these results that domain shadowing is an active threat to the enterprise, and it is hard to detect without leveraging automated machine learning algorithms that can analyze large amounts of DNS logs.
A Phishing Campaign Using Shadowed Domains
Next, we dive deeper into the phishing campaign we used as an example in Table 1. Clustering – based on IP address and root domains – the results from our detector, we found 649 shadowed domains created under 16 compromised domain names for this campaign. Figure 1 is a screenshot of barwonbluff.com[.]au, one of the compromised domains. Even though it seems to operate normally, attackers have created many subdomains under it that they can use in phishing links such as hxxps[:]//snaitechbumxzzwt.barwonbluff[.]com.au/bumxzzwt/xxx.yyy@target.it.
Figure 1. Screenshot of barwonbluff.com[.]au – an originally benign domain.When users click on the above phishing URL, they are redirected to a landing page, as shown in Figure 2. The phishing page on login.elitepackagingblog[.]com wants to steal Microsoft user credentials. To avoid falling for similar phishing attacks, users need to check the domain name of the website they are visiting and the lock icon next to the URL bar before entering their credentials.
Figure 2. Screenshot of the phishing landing page on elitepackagingblog[.]com, where victims are redirected from the snaitechbumxzzwt.barwonbluff[.]com.au shadowed domain. Source: Joe Sandbox.Figure 3 is a screenshot of halont.edu[.]au after the website owners found out that their domain name was compromised. Unfortunately, we observed many shadowed domains created under this domain name before the owners realized it was hacked. These cases further emphasize the necessity to automatically detect these domains because it is hard for domain owners to discover that they are compromised.
Figure 3. Screenshot of halont.edu[.]au, an originally benign domain that is being rebuilt after compromise.
Conclusion
Cybercriminals use shadowed domains for various illicit ventures, including phishing and botnet operations. We observe that it is challenging to detect shadowed domains as vendors on VirusTotal cover less than 2% of these domains. As traditional approaches based on threat research are too slow and fail to uncover the majority of shadowed domains, we turn to an automated detection system based on pDNS data. Our high-precision machine learning-based detector processes terabytes of DNS logs and discovers hundreds of shadowed domains daily. Palo Alto Networks offers multiple security subscriptions – including DNS Security and Advanced URL Filtering – that leverage our detector to protect against shadowed domains. Additionally, customers can leverage Cortex XDR to alert on and respond to domain shadowing when used for command and control communications.
Acknowledgements
We want to thank Wei Wang and Erica Naone for their invaluable input on this blog post.
Code injection is an attack technique widely used by threat actors to launch arbitrary code execution on victim machines through vulnerable applications. In 2021, the Open Web Application Security Project (OWASP) ranked it as third in the top 10 web application security risks.
Given the popularity of code injection in exploits, signatures with pattern matches are commonly used to identify the anomalies in network traffic (mostly URI path, header string, etc.). However, injections can happen in numerous forms, and a simple injection can easily evade a signature-based solution by adding extraneous strings. Therefore, signature-based solutions will often fail on the variants of the proof of concept (PoC) of Common Vulnerabilities and Exposures (CVEs). In this blog, we explore how deep learning models can help provide more flexible coverage that is more robust to attempts by attackers to avoid traditional signatures.
Why Intrusion Prevention System Signatures Aren’t Sufficient – How Machine Learning Can Help
Intrusion Prevention System (IPS) signatures have long been proven to be an efficient solution for cyberattacks. Depending on predefined signatures, IPS can accurately detect known threats with few or no false positives. However, creating IPS rules involves proof of concept or technical analysis of certain vulnerabilities, so it is challenging for IPS signatures to detect unknown attacks due to a lack of knowledge. For example, remote code execution exploits are often crafted with vulnerable URI/parameters and malicious payloads, and both parts should be identified to ensure threat detection. On the other hand, in zero-day attacks, both parts can be either unknown or obfuscated, making it difficult to have the needed IPS signature coverage. In our experience, we found the following set of challenges faced by threat researchers:
False negatives. Variations and zero-day attacks are seen every day, and IPS cannot have full coverage for all of them due to a lack of attack details beforehand.
False positives. To address variants and zero-day attacks, generic rules with loose conditions are created, which inevitably brings the risk of false alarm.
Latency. The time lag between vulnerability disclosure, security vendors rolling out protections and customers applying security patches represents a significant window for attackers to exploit the end user.
While these problems are innate to the nature of IPS signatures, machine learning techniques can address these shortcomings. Based on real-world zero days and benign traffic, we trained machine learning models to address common attacks such as remote code execution and SQL injection. From our recent research, presented in this blog, we find that these models can be very helpful in zero-day exploit detection, being both more robust and quicker to respond than traditional IPS methods.
In the following sections, we’ll share some case studies and insights into how machine learning models can be incorporated into exploit detection modules, and how effective this can be.
Detection Case Studies on Zero-Day Exploits
Case Study 1: Command Injection Detection
Command injection has long been a major threat in network security. Due to their easy-to-exploit nature and severe impact, command injection vulnerabilities have the potential to bring tremendous damage to affected organizations, especially when patches come late. Last year, vulnerabilities in commonly used software such as Log4Shell and SpringShell placed hundreds of millions of Java-based servers and web applications at risk. Meanwhile, vendors were busy updating IPS signatures to cover constantly evolving attack patterns derived from the original exploit in a frustrating cat-and-mouse chase, and we still see obfuscated attacks attempted today.
Generally, for those vulnerabilities which include specific paths or parameters, IPS signatures are a good idea since attacks can be accurately filtered out by the URI and suspicious payload. However, some exploits of critical vulnerabilities can be flexible due to the nature of HTTP protocols. For example, the Log4Shell vulnerability can be triggered through all kinds of user inputs. Moreover, the complexity of HTTP encoding methods allows attackers to evade normal detection using partial or mixed encoding. In such situations, machine learning methods can more accurately identify abnormal traffic, yielding corresponding verdicts with the knowledge of previously seen malicious sample payloads.
We trained a state-of-the-art Convolutional Neural Network (CNN) with cutting edge deep learning technologies loosely based on previous academic research on Temporal Convolutional Networks. While variable length inputs suggest that a recurrent model structure such as a Recurrent Neural Network (RNN) or a Long Short-Term Memory (LSTM) Network may be suitable, research shows that a simple convolutional architecture often outperforms recurrent models. Our model has learned more generalizable common patterns in command injection exploits while also being specific enough to avoid false positives. In the following sections, we discuss case studies of command injection exploits and how our new machine learning model is able to accurately detect them.
Atlassian Confluence is a web-based corporate wiki tool used to help teams to collaborate and share knowledge efficiently. One recent remote code execution vulnerability, CVE-2022-26134, targets Confluence versions 1.3.0-7.4.17, 7.13.0-7.13.7, 7.14.0-7.14.3, 7.15.0-7.15.2, 7.16.0-7.16.4, 7.17.0-7.17.4 and 7.18.0-7.18.1. We have observed successful exploitation leveraging this vulnerability to perform Cerber Ransomware attacks.
Figure 1. One PoC attack leveraging CVE-2022-26134.
Malicious but arbitrary commands can be inserted in the payload to perform various activities. The machine learning model can easily distinguish between benign and malicious activities and block the attacks using different commands without knowing the full context of the application.
2. Unknown IoT Zero-Day Attack
Sometimes we see alerts from our internal threat hunting research platform when processing real-world traffic. After filtering out false positives, these types of detections usually indicate that a zero-day attack has been captured. For example, on April 29, 2022, we saw the HTTP request shown in Figure 2.
Figure 2. An HTTP request that triggered an alert on our machine learning model.
The command and control (C2) server was down shortly after we got the traffic, so it is difficult to verify details of the exploit and payload. However, according to our threat intelligence, this could be attributed to a previously unknown attack targeting certain MIPS-based smart devices.
With traditional IPS technologies, it’s possible to miss such attacks since the vulnerable URI and parameters have never been seen before; it’s hard to determine if the requested data is benign or suspicious. In this specific case, our IPS with a default configuration did not result in an alert, but our machine learning model successfully identified the attack with a high confidence score.
The Tenda AC18 router is prone to a remote code execution vulnerability, allowing attackers to execute arbitrary commands on the device. Not long after the vulnerability was published, a Palo Alto Networks researcher discovered an exploit in the wild targeting this specific CVE, as shown in Figure 3.
Figure 3. Exploit in the wild targeting CVE-2022-31446.
Similar to the zero-day IoT attack mentioned above, it's difficult for traditional IPS solutions to detect such attacks due to their inherent limitations. However, our machine learning model detected the exploit with high confidence. The machine learning model identifies that requests in the POST body are highly suspicious and suggests the IP address shown in Figure 3 should be further investigated with correlated malicious samples.
Case study 2: SQL Injection Detection
SQL injections are another notorious and challenging threat in network security. In this type of attack, threat actors alter SQL queries and inject malicious code by exploiting vulnerabilities. SQL injections may result in information modification, sensitive data leakage and unauthorized command executions in underlying database systems. Due to the serious potential impact of SQL injection vulnerabilities, their prompt detection and zero-day exploit prevention on the network side are critical to fortifying an organization’s assets.
Unfortunately, the task is challenging with traditional IPS systems due to time limitations and the need for technical expertise. Traditional systems require properly composing and testing customized signatures to cover zero-day SQL exploitations, such as exploits targeting, for example, CVE-2022-0332 and CVE-2022-34265. Even worse, attackers may utilize readily available hacking tools such as sqlmap to generate SQL injection exploitations that are very difficult to cover with IPS signatures. In this case, machine learning solutions can effectively classify malicious SQL injection payloads from benign traffic by examining carefully selected features covering a variety of SQL injection exploitations. The following vulnerability case studies demonstrate the effectiveness and efficiency of the machine learning solutions we have developed.
Moodle is a free and open source learning management system with more than 300 million users. However, Moodle versions 3.11 to 3.11.4 have a vulnerability (CVE-2022-0332) in the server.php file due to the lack of user input sanitization, making it possible to use the union operator to query unexpected data. When given the following payload, vulnerable versions of Moodle will query the SQLite engine version with the function sqlite_version() and return it to the user. Our machine learning solution effectively derives features from capturing the union-select related SQL injection code snippet and flexibly detects exploitations of CVE-2022-0332.
Figure 4. One PoC leveraging CVE-2022-0332.
After decoding, the PoC of CVE-2022-0332 is shown in Figure 5.
Django is a widely used framework to build websites, including Instagram, Disqus, Pinterest, etc. CVE-2022-34265 is an issue affecting the Django framework. This vulnerability is caused by an improper check on parameter values for the Trunc() and Extract() functions, which may lead to unexpected SQL statement execution. Two PoCs for CVE-2022-34265 are shown in Figures 6 and 7. Both payloads use a boolean injection sub-payload followed by a stack injection sub-payload. When a payload is appended to the predefined SQL statement, the first statement split by the semicolon will always be true because of the or 1=1. The second part will lead to a sleep of five seconds by the program, which, on the browser side, leads to a five second waiting time. The five second delay on the front end can indicate the successful SQL statement execution – which also indicates the existence of the SQL injection vulnerability. Our machine learning solution can also effectively detect the SQL injection patterns as or 1=1 statements, which can help us effectively prevent the exploitation of such vulnerabilities.
Figure 6. Two PoCs for CVE-2022-34265.Figure 7. After decoding, two PoCs for CVE-2022-34265.
3. sqlmap-generated exploitation
sqlmap is an open source tool used in penetration testing to detect and exploit SQL injection flaws, which can automate the process of crafting exploitations of SQL injection vulnerabilities. While the tool can be used for legitimate purposes, it can also be abused by attackers.
Figure 8 shows a PoC of SQL injection from sqlmap. After decoding, we can observe the snippet and 1043=1043, which is a widely used pattern for blind SQL exploitation. The attacker can leverage the statement to sniff the vulnerabilities of web services and database systems. The pattern is similar to or 1=1 (see our discussion of CVE-2022-34265), but sqlmap can generate polymorphic SQL injection exploitations as long as the statement is always true after and.
These types of patterns are challenging to detect via IPS signatures. While a traditional signature might only be able to match one and 1=1 case, our machine learning solution can properly cover the exploitation with dedicated features for all similar and 1=1 cases.
Figure 8. One PoC from SQLmap.Figure 9. The decoded PoC from SQLmap.
Machine Learning Test Results
For detecting zero day exploits, we trained two machine learning models: one for detecting SQL injection attacks, and one for detecting command injection attacks. We prioritize a low false positive rate in order to minimize adverse effects of deploying these models for detection. For both models, we train on HTTP GET and POST requests. To generate these datasets, we combined multiple sources, including tool-generated malicious traffic, live traffic, internal IPS data sets and more.
From ~1.15 million benign and ~1.5 million malicious samples containing SQL queries, our SQL model achieved a 0.02% false positive rate and a 90% true positive rate.
From ~1 million benign and ~2.2 million malicious samples containing web searches and possible command injections, our command injection model achieves a 0.011% false positive rate and a 92% true positive rate.
These detections are particularly useful because they can provide protections against new zero-day attacks, while being resistant to small modifications that might evade traditional IPS signatures.
Conclusion
Command injection and SQL injection attacks continue to be some of the most common and most concerning threats affecting web applications. While traditional signature-based solutions remain effective against out-of-the-box exploits, they often fail to detect variants; a motivated adversary can make minimum modifications and evade such solutions.
To combat these ever-evolving threats, we developed a context-based deep learning model that proved to be effective in detecting the latest high profile attacks. Our models were able to successfully detect zero-day exploits such as the Atlassian Confluence vulnerability, the Moodle vulnerability and the Django vulnerability. These types of flexible detections will prove to be critical in providing comprehensive defense in an ever-evolving malware landscape.
To protect our customers, the Palo Alto Networks Next-Generation Firewall uses a combined inline and cloud solution. Our traditional IPS solutions remain effective for protecting against a significant portion of existing exploits, including SQL injections and command injections. In addition, the machine learning models we explored in this blog have the potential to provide even more robust protections beyond IPS signatures.
On March 4, 2019, one of the most well-known keyloggers used by criminals, called Agent Tesla, closed up shop due to legal troubles. In the announcement message posted on the Agent Tesla Discord server, the keylogger’s developers suggested people switch over to a new keylogger: “If you want to see a powerful software like Agent Tesla, we would like to suggest you OriginLogger. OriginLogger is an AT-based software and has all the features.” OriginLogger is a variant of Agent Tesla. As such, the majority of tools and detections for Agent Tesla will still trigger on OriginLogger samples.
Recently, when sitting down to analyze some malware tagged as Agent Tesla, I was surprised to learn I was actually looking at something else. This fact revealed itself to me when I began analyzing the malware families’ configurations at scale after creating tooling to extract them.
In this blog, I will cover the OriginLogger keylogger malware, how it handles the string obfuscation for configuration variables and what I found when looking at the extracted configurations that allowed for better identification and further pivoting.
When I began researching OriginLogger, I could find little to no public information about it. There are several Agent Tesla-related analysis blogs that I now recognize as pertaining to OriginLogger – sometimes tagged as “AgentTeslav3” – but otherwise, the public internet is pretty light on relevant information.
During my search, I stumbled across a YouTube video posted in 2018 (before Agent Tesla closed up shop) by a person selling “fully undetectable” (FUD) tools. This person showed off the OriginLogger tools with a link to buy it from a known site that traffics in malware, exploits and the like.
Figure 1. OriginLogger feature highlights (Source: screenshots of the OriginLogger sale page from a YouTube video on OriginLogger).Figure 2. OriginLogger feature list.
Additionally, they showed both the web panel and the malware builder.
The image of the builder shown in Figure 4 was particularly interesting to me as it provided a default string – facebook, twitter, gmail, instagram, movie, skype, porn, hack, whatsapp, discord – that might be unique to this application. Sure enough, a content search on VirusTotal shows one matching file (SHA256: 595a7ea981a3948c4f387a5a6af54a70a41dd604685c72cbd2a55880c2b702ed) uploaded on May 17, 2022.
Figure 5. VirusTotal search for string.
Downloading and attempting to run this file resulted in errors due to missing dependencies; however, knowing the builder’s filename, OriginLogger.exe, allowed me to expand the search and locate a Zip archive (SHA256: b22a0dd33d957f6da3f1cd9687b9b00d0ff2bdf02d28356c1462f3dbfb8708dd) containing all of the files required to run OriginLogger.
Figure 6. Bundled files in Zip archive.
The settings.ini file contains the configuration the builder will use, and in Figure 7 we can see the previous search string listed under SmartWords.
Figure 7. OriginLogger Builder settings.ini file.
The file profile.origin contains the embedded username/password that a customer registers with when purchasing OriginLogger.
Figure 8. OriginLogger builder login screen.
Amusingly, if you flip around the values in the profile file, the plaintext password is revealed.
Figure 9. Contents of profile.origin file.Figure 10. OriginLogger builder login screen with threat actor password revealed in plaintext.
When a user logs in, the builder attempts to authenticate with the OriginLogger servers to validate the subscription.
At this point, I had two versions of the builder. The first one (b22a0d*), contained in the Zip file, was compiled Sept. 6, 2020. The other, which contained the SmartWords string (595a7e*), was compiled on June 29, 2022, just about two years after the first.
The later version makes its authentication request over TCP/3345 to IP 23.106.223[.]46. Since March 3, 2022, this IP has resolved to the domain originpro[.]me. This domain has resolved to the following IP addresses:
23.106.223[.]46 204.16.247[.]26 31.170.160[.]61
The second IP, 204.16.247[.]26, stands out due to resolving these other OriginLogger related domains:
Things get more interesting when looking at the older builder. This one attempts to reach out to a different IP address for the authentication.
Figure 11. PCAP showing remote IP address.Unlike the IP addresses associated with originpro[.]me, 74.118.138[.]76 does not resolve to any OriginLogger domains directly but instead resolves to 0xfd3[.]com. Pivoting on this domain shows it contains both DNS MX and TXT records for mail.originlogger[.]com.
Beginning around March 7, 2022, the domain in question began resolving to IP 23.106.223[.]47, which is one value higher in the last octet than the IP used for originpro[.]me, which used 46.
These two IP addresses have shared multiple SSL certificates:
The RDP login screens for both of the servers beginning with IP 23.106.223.X show a Windows Server 2012 R2 server with multiple accounts.
Figure 12. RDP login screen for 23.106.223[.]46.When further searching for this domain, I came across the GitHub profile for user 0xfd3, which contains the two repositories shown in Figure 13.
Figure 13. User 0xfd GitHub.
I’ll circle back to these later in the blog when looking at the code, but (spoiler alert) they are also used in OriginLogger.
Dropper Lure
Before diving into the malware, I’ll quickly cover the dropper that led to the sample I set out to analyze. As both Agent Tesla and OriginLogger are commercialized keyloggers, the initial droppers will vary greatly between campaigns and should not be considered unique to either. I present the below as a real-world example of an attack dropping OriginLogger and show that they can be quite convoluted and obfuscated.
The initial lure document is a Microsoft Word file (SHA256: ccc8d5aa5d1a682c20b0806948bf06d1b5d11961887df70c8902d2146c6d1481). When opened, this document displays a photo of a passport for a German citizen, along with a credit card. I’m not quite sure how enticing this would be as a lure for a normal user, but either way, you’ll note the inclusion of numerous Excel Worksheets below the image, as shown in Figure 14.
Figure 14. Lure document.
Each of these sheets are contained in separate embedded Excel Workbooks and are exactly the same:
Within each Workbook is a singular macro that simply saves a command to execute at the following location:
C:\Users\Public\olapappinuggerman.js
Figure 15. Excel VBA macro.
Once run, this will download and execute via MSHTA the contents of the file at hxxp://www.asianexportglass[.]shop/p/25.html. A screenshot of the website is shown in Figure 16.
Figure 16. Website to appear legitimate.This file contains an embedded obfuscated script in the middle of the document as a comment.
Figure 17. Website hidden comment.
Unescaping the script reveals the code shown in Figure 18, which downloads the next payload from a BitBucket snippet (hxxps://bitbucket[.]org/!api/2.0/snippets/12sds/pEEggp/8cb4e7aef7a46445b9885381da074c86ad0d01d6/files/snippet.txt) and establishes persistence with a scheduled task named calsaasdendersw that runs every 83 minutes and uses MSHTA again to execute the script contained within hxxp://www.coalminners[.]shop/p/25.html.
Figure 18. Unescaped script.
The snippet hosted on the BitBucket website contains further obfuscated PowerShell code and two binaries encoded and compressed.
The first of the two files (SHA256: 23fcaad34d06f748452d04b003b78eb701c1ab9bf2dd5503cf75ac0387f4e4f8) is a C# reflective loader using CSharp-RunPE. This tool is used to hollow out a process and inject another executable inside of it; in this case, the keylogger payload will be placed inside the aspnet_compiler.exe process.
Figure 19. PowerShell command to execute method contained in dotNet assembly.Note the projFUD.PA class that the Execute method is called from. Morphisec released a blog in 2021 called “Revealing the Snip3 Crypter, a highly evasive RAT loader,” where they analyze a crypter-as-a-service and fingerprint the crypter’s author using this artifact.
The second of the two files (SHA256: cddca3371378d545e5e4c032951db0e000e2dfc901b5a5e390679adc524e7d9c) is the OriginLogger payload.
OriginLogger Configuration
As previously stated, the original intention of this analysis was to automate and extract configuration-related details from the keylogger. To achieve this, I started by looking at how the configuration-related strings are used.
I won’t be diving into any of the actual functionality of the malware as it’s fairly standard and mirrors analysis of older Agent Tesla variants. Just as the threat actors’ advertisements state, the malware uses tried and true methods and includes the ability to keylog, steal credentials, take screenshots, download additional payloads, upload your data in a myriad of ways and attempt to avoid detection.
To start extracting configuration-related details, I needed to figure out how the user-supplied data is stored in the malware; it turned out to be straightforward. The builder will take the dynamic string values and concatenate them into a giant blob of text which is then encoded and stored in a byte array to be decoded at runtime. Once the malware runs and hits a particular function that needs a string, such as the HTTP address to upload screenshots to, it will pass the offset and string length to a function that will then carve out the text at that location within the blob.
To illustrate, below you can see the decoding logic used for the main blob of text.
Figure 20. OriginLogger plaintext blob decoding.
Each byte is XOR’d by the index of the byte within the byte array, and again XOR’d by the value 170 to reveal the plaintext.
For each sample generated by the builder, this blob of text will differ depending on what’s configured, so offsets and positioning will change. Looking at the raw text shown in Figure 21 is helpful, but without splicing it up, it becomes hard to determine where the boundaries end or begin.
Figure 21. Plaintext blob.
It also does not help when it comes time to analyze the malware, as you won’t be able to discern when or where something is used. To figure this next piece out, I needed to look at how OriginLogger handles the splicing.
Below you can see the function responsible for carving out the string, followed by the beginning of the individual methods containing the offset and length.
Figure 22. OriginLogger string functions.
In this case, if the B() method is called at some point by the malware, it will pass 2, 2, 27 to the obfuscated nameless function at the top of the image. The first integer is used for the array index where the decoded string will be stored. The second (offset) and third (length) integers are then passed to the GetString function to obtain the text. For this particular entry, the resulting value – <font color="#00b1ba"><b>[ – is used during the creation of the HTML page it uploads to display the stolen data.
Knowing how the string parsing works, I could then automate the extraction of these strings. To start, it helps to look at the underlying intermediate language (IL) assembly instructions.
Figure 23. OriginLogger IL instructions for string function.
For each of these lookups, the structure of the function block will remain the same. At index 6-8 in Figure 23, you will see three ldc.i4.X instructions where X dictates an integer value that will be pushed onto the stack before calling the previously described splicing function. This overall structure creates a framework that can then be used to match all of the corresponding functions in the binary for parsing.
Leveraging this, I wrote a script to identify the encoded byte array, determine the XOR values and then splice up the decoded blob in the same fashion the malware uses it. With this, you can scroll through the decoded strings and look for things of interest. Once something is identified, knowing the offset and subsequent function name, you can pivot into the part of the malware that leverages them.
Figure 24. OriginLogger decoded strings.
From here, I started renaming the obfuscated methods to reflect their actual values, which made analysis easier on the eyes.
Figure 25. OriginLogger FTP upload function.
It should be noted that the same string deobfuscation can be achieved by using de4dot and its dynamic string decryption feature by specifying the string types as delegate and identifying the tokens of interest. This works extremely well for single file analysis.
Recall that I mentioned in the OriginLogger Builder section of this blog that I’d circle back to the GitHub repositories of the 0xfd3 user. Take a look in Figure 26 at the Chrome Password Recovery code uploaded in March 2020 after OriginLogger took Agent Tesla’s prominence in the keylogger world.
Figure 26. Chrome Password Recovery.
Compare Figure 26 to the code from the OriginLogger sample with renamed methods shown in Figure 27.
Look familiar? These types of similarities abound as OriginLogger has continued development where Agent Tesla left off.
Identifying OriginLogger Through Artifacts
Using this tooling, I extracted 1,917 different configurations, which gives insight into the exfiltration methods used and allows for clustering of samples based on the underlying infrastructure.
This is where I began to understand that what I was looking at wasn’t Agent Tesla but instead a different keylogger – OriginLogger. Two particular exfiltration methods that both showed multiple references to “origin” in some fashion led me to connect the dots.
For example, one of the URLs configured for a sample to upload keylogger and screenshot data to was hxxps://agusanplantation[.]com/new/new/inc/7a5c36cee88e6b.php. This URL is no longer active so I started searching for historical information about it to understand what was on the receiving end of these HTTP POST requests. By plugging in the domain to URLScan.io, it showed login pages for the panel in the same directory but, more importantly, that the OriginLogger web panel (SHA256: c2a4cf56a675b913d8ee0cb2db3864d66990e940566f57cb97a9161bd262f271) was observed on this host at the time of scanning four months ago.
Figure 28. URLScan.io scan history for domain.Similarly, one of the exfiltration methods is through Telegram bots. To utilize them, OriginLogger requires a Telegram bot token to be included so the malware can interact with it. This provides another unique opportunity to analyze the infrastructure in use. In this case, I can use the token to query Telegram with what equates to a whoami command and observe the names used by the bot creator. Below are a handful of examples showing relevant naming.
Like other keyloggers that are commercially sold, OriginLogger is used by a wide variety of people for various malicious purposes around the globe. In the past, I’ve written about taking a deeper look at the victims of keyloggers and what analyzing their screenshots can reveal about the potential intentions of the attackers. In this blog post, I will summarize some observations of the data extracted from the corpus of OriginLogger samples I collected. Most samples had multiple exfiltration techniques configured and I’ll cover each one below.
SMTP is still the primary mechanism used for exfiltrating data and was identified in 1,909 samples. This is most likely because:
The traffic will blend in with normal user traffic better than other included protocols.It’s relatively easy for attackers to obtain stolen e-mail accounts.
E-mail providers usually offer a large amount of storage space.
There were 296 unique e-mail recipient addresses for the stolen data and 334 unique e-mail account credentials used to send them.
FTP was configured in 1,888 samples using 56 unique FTP servers and 79 unique FTP accounts, with multiple accounts logging to different directories, likely based on different campaigns. Across the accessible servers, which were limited to 11 of the 56, there are 442 unique victims, with some victims being logged hundreds of times.
Web uploads to the OriginLogger panel followed closely behind and were configured in 1,866 samples, uploading to 92 unique URLs. When analyzing these URLs, the PHP file used for the upload showed a pattern of alphanumeric characters in the filename, with a couple of additional patterns presenting themselves in the directory structure. Looking into the source code of the web panel as shown in Figure 29 shows that the PHP filename is an MD5 value of some random bytes and is placed in the /inc/ (incoming) directory.
Figure 29. OriginLogger source code for setup.php.
Keep in mind that many keylogger purchasers may not have much technical experience and tend to use a “full service” vendor that creates everything for them so that all they are required to do is distribute the keylogger. I suspect this is a reason for a lot of the URIs having similar structures. For example, the structure http://<ipaddress>/<name>/inc/<md5>.php is repeated throughout, and the first level of the directory shows values unlikely to be generated automatically – possibly account-related:
For the last exfiltration method, we have Telegram identified in 1,732 samples with 181 unique Telegram bots receiving the stolen data. In addition to being able to issue a whoami for the bot, we’re able to query for information related to the channels where stolen information was uploaded. The most prominent of the channels are below with the details currently in use:
Count
Channel Bio
Owner
Bot Name
41
Invest in bitcoin now and attain financial freedom
Alaa Ahmed
obomike_bot
25
Free Cannabis
Cry_ptoSand
sales3w7_bot, oasisx_bot, valiat073_bot
21
Atrium Investment Ltd: We Help You ACHIEVE YOUR LIFE GOALS
Doris E. Athey
Tino08Bot
20
Self Discipline, Consistency and humanity.
Lucas Grayson
Odion2023bot
18
Come Closer
Anthony Forbes
Anthonyforbes2023bot
14
Think it, Code It
CodeOnce DeSpartan
PWORIGIN_bot
12
Dream cha$er 4L
Lurgard da Great
johnwalkkerBot
11
coder..no system is safe.. Private crypt 100$..knowledge is power
☠️The Devil☠️( do not disturb ))
Skiddoobot
10
PhD Engineering
Alexander Macbill
swft_bot
Table 2. Prominent Channels
Finally, one feature that is not utilized very often is the ability for OriginLogger to download an additional payload after infecting the victim system. In the samples discussed here, only two were configured to download additional malware.
Conclusion
OriginLogger, much like its parent Agent Tesla, is a commoditized keylogger that shares many overlapping similarities and code, but it’s important to distinguish between the two for tracking and understanding. Commercial keyloggers have historically catered to less advanced attackers, but as illustrated in the initial lure document analyzed here, this does not make attackers any less capable of using multiple tools and services to obfuscate and make analysis more complicated. Commercial keyloggers should be treated with equal amounts of caution as would be used with any malware.
Luckily, in this instance, because of the similarities between the two aforementioned keyloggers, detections and protections carried over from one generation to the next – albeit with slightly inaccurate signature naming.
There is a constant debate between usability and security in the software world. Many third-party programs can make their users’ lives easier and save them time by storing their credentials. However, as it turns out, this convenience often comes at the price of poor security, causing the risk of password theft. Credentials gathered in this manner can then be used during an actual cyberattack.
In this article, we will explain the dangers of credential theft. We will examine some common third-party software scenarios related to credential gathering, looking into how passwords are stored, how they can be retrieved and how to monitor these actions based on real-world attack scenarios.
Cortex XDR Customers are protected from such attacks using the Credential Gathering Protection Module released in Cortex 3.4 on Windows, Linux and MacOS agents.
Thus, when attackers can get a password from one source, they can try to use it against other resources, including some that are more protected. So, for every program A that is well secured, the user could use the same password or pattern on program B that is less secure – which could result in making program A less secure.
Furthermore, if it turns out that a person is using their operating system password in other less secure locations, a whole new world of possibilities is open to the attacker.
Let’s say, for example, that person X uses the same password for his Windows account domain and a Linux FTP file server. In this scenario, person X uses the common program WinSCP to manage their files in the file server. Although WinSCP advises that saving passwords isn’t recommended, person X accesses this file server every week, so they prefer to save time and save their password.
Figure 1. Password saving is not recommended by WinSCP.
As we will demonstrate later in this blog, the user’s password can easily be retrieved from where WinSCP stores it. An attacker who can get a foothold on X’s personal computer can get their domain account password – only because it is being saved insecurely. This is on top of the fact that the password is valid for connecting to the file server. This file server may contain files with sensitive information to which the attacker now has access. From there, the attacker can use tools like BloodHound to estimate how far they can spread within an organization.
Credential Gathering in Practice
Software: WinSCP
WinSCP is a popular SFTP client and FTP client for Microsoft Windows that is used to copy files between local Windows computers and remote servers using FTP, FTPS, SCP and SFTP.
Tested version:
5.19.6 (Build 12002 2022-02-22)
Where are credentials stored?
WinSCP stores the encrypted user’s password under the registry key HKCU\software\martin prikryl\winscp 2\sessions\<session_name> in a value called Password.
How can the credentials be recovered?
WinSCP performs symmetric mathematical operations on the bits of the user’s passwords. It takes each byte of the password, computes the complement to 0xFF (11111111), and after that, XORs it with the byte 0xA3 (10100011).
The encryption process comprises finding the complement and performing the XOR one time. The password is then stored in the Password registry value. Since these mathematical operations are symmetric, all we need to do is perform the same two operations once again, in reverse order, to get the original value.
For example, let's take a commonly used password: Aa123456. This is how WinSCP will store this password: 1D3D6D6E6F68696A.
In Figure 2, we see the steps to decrypt the password:
Figure 2. Decrypting a password stored in WinSCP.
The password is saved along with the HostName and UserName. To get it from the Password registry value, we must find the index at the beginning of the password. This calculation is pretty easy – depending on the WinSCP version, the first or third byte of the registry value is the length of the username, hostname and password, concatenated. The start index is the following byte to the length, and its value is multiplied by two. Both the length and the start index are encrypted in the same way.
The UserName and HostName are also saved on different registry values, so we know their length and value. All we do is decrypt the Password registry value from the index: start index + username length + hostname length to length, and we will get our password.
Figure 3. Location of username, hostname and password, concatenated.
In the wild
We have seen the following script executed in multiple customer environments:
Figure 4. Suspicious PowerShell with encoded command.
-enc stands for EncodedCommand, meaning that a base-64-encoded string is used as the command.
In the decoded script, we can see an attempt to decrypt WinSCP passwords:
Figure 5. PowerShell script for extracting and decrypting WinSCP’s passwords.
Figure 6. Cortex XDR prevented attempts to read passwords stored in WinSCP.
Software: Git
Tested version:
2.35.1.windows.2
Where are credentials stored?
Git allows for the use of both passwords and Personal Access Tokens (PATs).
When users want to save time by saving their Git credentials, they can do it using the following command:
git config credential.helper 'store'
Using this command, Git will save the user’s credentials indefinitely on disk, in plain text.
Possible files containing passwords:
<userprofile>\.git-credentials
<userprofile>\.config\git\credentials
Git allows using PATs as credentials instead of the traditional use of passwords. These tokens are more modular, as any number of access tokens can be created, each with different permissions and expiration dates.
Although it is possible to control users’ actions in a more modular and granular way, each associated with a specific PAT, anyone who has the user’s PAT can view all repositories to which the user has access.
These tokens also appear in cleartext in the same files mentioned above.
How can the credentials be recovered?
Anyone who reads these files will see the username, password or token, and relevant Git repository in plain text.
Software: RDCMan
Tested version:
2.83
RDCMan manages multiple remote desktop connections. It is useful for managing server labs where you need regular access to machines, such as automated check-in systems and data centers.
Where are credentials stored?
When a user decides to save a password for a session using RDCMan, the default configuration file will be %localappdata%\Microsoft\Remote Desktop Connection Manager\RDCMan.settings
This file is an XML file that contains general metadata about each RDP connection.
Among the data, there is an XML tag called CredentialsProfiles, which has attracted our attention.
We can see that under this tag, there is another one called CredentialsProfiles, and inside there are credentialsProfile XML tags, with a Password tag.
Figure 7. Looking at the XML tags in RDCMan.settings
How can the credentials be recovered?
To retrieve the password, we will have to execute commands in the context of the person using the RDCMan program. This is because the password is being saved using the DATA Protection API (DPAPI), which enables symmetric encryption and decryption of any kind of data using the functions CryptProtectData and CryptUnprotectData, respectively.
So, to get the password, we need to call the function CryptUnprotectData.
Usually, the only user who can decrypt the data is a user with the same login credentials as the user who encrypted the data.
Although gathering credentials from RDCMan requires an additional step from the attacker than was needed in some of our other examples – running the software in the context of the relevant user – there is great value to the result for the attacker. If the effort is successful, it’s possible for the threat actor to get all the users and passwords for all of the machines that this specific user connects to.
Once the attacker is able to execute commands in the context of the user, all that remains in order to gather credentials is to:
Open the RDCMan.settings file and check for the password XML tag.
Decode the string in the tag with base64.
Call CryptUnprotectData with the decoded password string.
Decode the result using UTF-8 (or other relevant formats).
Remove unnecessary null characters.
Looking at the example above, the password saved in the file was:
OpenVPN is a virtual private network system that implements techniques to create secure point-to-point or site-to-site connections in routed or bridged configurations and remote access facilities.
Where are credentials stored?
OpenVPN stores the user’s password under the registry key HKCU\software\openvpn-gui\configs\<session_name> in a value called auth-data.
How can the credentials be recovered?
OpenVPN also uses the DPAPI mechanism, with the additional optional entropy parameter (which can be set to NULL).
When an optional entropy DATA_BLOB structure was used in the encryption phase, that same DATA_BLOB structure must be used for the decryption phase.
In the case of OpenVPN, the entropy is saved in a registry value called entropy. The entropy registry value is also stored in the path HKCU\software\openvpn-gui\configs\<session_name>
So, calling CryptUnprotectData with the password from auth-data and entropy (from entropy) will give us the session password.
The entropy registry value contains an extra byte of 00, so we just need to omit it.
Figure 9. Above, the PowerShell script for recovering an OpenVPN password. Below, the way auth-data and entropy registry values are shown via reg.exe (POC).
Software: Chromium-based Browsers
Tested version:
Google Chrome – Tested version: 103.0.5060.53 (Official Build) (64-bit)
Microsoft Edge – Tested version: 103.0.1264.37 (Official Build) (64-bit)
Opera – Tested version: 88.0.4412.53
The Chromium projects include Chromium, the open-source project behind the Google Chrome browser.
In a typical usage routine, many people tend to save passwords while surfing the internet.
Figure 10. Passwords saved by Google Chrome Version 102.0.5005.115 (Official Build) (64-bit).
Where are credentials stored?
When using a Chromium-based browser, like Microsoft Edge, Opera or Google Chrome, passwords are located encrypted in an SQLite database file, usually called login data.
Each profile has a password database – its login data file.
The key used to encrypt the passwords is located in the parent folder, in a JSON file called local state.
For example:
login data locations:
Google Chrome: %localappdata%\google\chrome\user data\<PROFILE>\login data
Microsoft Edge: %localappdata%\microsoft\edge\user data\<PROFILE>\login data
Opera: %appdata%\opera software\operastable\<PROFILE>\login data
local state locations:
Google Chrome: %localappdata%\google\chrome\user data\local state
Microsoft Edge: %localappdata%\microsoft\edge\user data\local state
Opera: %appdata%\opera software\opera stable\local state
How can the credentials be recovered?
Each password in the login data database is encrypted using the Advanced Encryption Standard (AES), with GCM mode. AES GCM is a symmetrical encryption method, so the same key is valid for both encryption and decryption. The AES algorithm uses a different key for every 128-bit block, which is based on the calculation of the previous block. For the first block, there is an option to use the Initialization Vector (IV).
To decrypt a password that a Chromium-based browser saves, we need to have:
The encrypted password.
The initialization vector.
The AES key.
Let’s see how we can retrieve each of those:
A. The encrypted password.
Can be exported from the login data database – the encrypted password is taken from the password_value column, from the letter in the 15th position to the end – 16 letters. [15:-16]
B. The initialization vector.
Located in the same password_value field column, from the letter in the third position to the letter in the 15th position. [3:15]
C. The AES key.
Written in the local state JSON file, under keys os_crypt and encrypted_key, decoded with base64.
Chromium-based browsers save the AES key using the DPAPI mechanism, so to get it, we will have to decode it from base64 and use CryptUnprotectData in the user’s context.
Example from Google Chrome:
Figure 11. Password that is being saved in local state JSON file of Google Chrome.
It is being saved with a prefix of five letters at the beginning: DPAPI.
Figure 12. The decoded password that was saved in Google Chrome.
If the attacker is able to run in the context of the user, all that is necessary to complete gathering user credentials is:
Copy both login data and local state files.
Get the AES GCM key from the local state JSON file.
Decode (base64), decrypt (CryptUnprotectData) and remove the padding from the key.
Decrypt each password in the login data database, using the decrypted AES GCM key.
Figure 13. POC for recovering passwords that were saved in Chrome.
(SHA256 of kgnkudbadmpogg.dll: 6599FEE8C7ADF30A00889A7070600F472F8CEAD8EA4DD1A85E724ED15F2AED0F)
After a chain of events, the final payload was trying to access Microsoft Edge credentials files:
The login data file (SQLite database file) C:\users\<username>\appdata\local\microsoft\edge\user data\default\login data
The local state file (contains the encryption key) C:\users\<username>\appdata\local\microsoft\edge\user data\local state
Figure 14. Cortex XDR detected attempts to read passwords saved in the Microsoft Edge browser.
Software: Firefox Browser
Tested version:
Firefox Version 101.0.1 (64-bit)
The password-saving behavior pattern is also relevant when using other browsers, such as Mozilla Firefox.
Figure 15. Passwords that are being saved by Firefox Version 101.0.1 (64-bit).
Where are credentials stored?
Similar to Chromium-based browsers, in the Mozilla Firefox browser, each profile also has its own password file.
This file is called logins.json and is located in %appdata%\mozilla\firefox\profiles\<PROFILE>\logins.json
Both username and password are saved encrypted.
Figure 16. Password saved in the logins.json file of Firefox.
How can the credentials be recovered?
Each username and password in the logins.json file is encrypted using the PKCS #11 cryptography standard. Firefox has developed the NSS library to adopt this standard into its browser (nss3.dll).
To retrieve the user’s passwords, the attacker will have to access one of these files and the logins.json file.
So, if the attacker can gain access to run on the same machine, the process of stealing the passwords will be:
The attacker copies the logins.json file.
Loads the NSS library (nss3.dll)
Decodes (base64) the encryptedUsername and encryptedPassword from the copy of logins.json.
Stores each of the inputs in a SecItem object, which is later used throughout NSS to pass blocks of binary data back and forth.
Creates SecItem objects for output.
Decrypts each encryptedUsername and encryptedPassword input object, and stores the data in the new SecItem output objects, using the PK11 decryption function from nss3.dll.
Unlike the case of Chromium-based browsers, the attacker doesn’t have to run in a user’s context to get the person’s passwords, but can take advantage of any user who has permission to access the file system profile of the target user.
Figure 17. User S got passwords belonging to user D that were saved in Firefox profile 2. (POC)
Tries to create Invoke-WebRequest for each of the links in $Links, downloads a DLL and saves it in the folder mentioned in step A with the name rRXqwGvGNR.wTj
Breaks after the first successful execution.
Next, we saw that a DLL was created on the endpoint and regsvr32.exe was used with the following command line:
Note that the path has an evasion in it: By using \..\ to go back to the Local folder, the attacker avoids accessing it directly.
After using regsvr32.exe:
A. The DLL copies itself to a random folder with a random name, with a DLL extension: C:\Users\<USERNAME>\AppData\Local\<random_folder_name>\<random_dll_name>.dll
B. The DLL executes a couple of discovery commands:
systeminfo – To list machine information.
ipconfig /all – To list all network interfaces on the machine.
nltest.exe /dclist: – To list all domain controllers in the domain.
C. The DLL creates and executes two files based on certutil.exe with random names:
One of them has a new random name but is still signed by Microsoft.
The other one is a mangled version of certutil – keeping the original name, but with different functionality, and no signature.
Certutil SHA256 - Note that this file is benign: D252235AA420B91C38BFEEC4F1C3F3434BC853D04635453648B26B2947352889
The unsigned certutil.exe then tries to access password files, both for Chromium-based and Firefox-based browsers.
When checking the links from Figure 19, only two links worked:
Figure 20. DLLs that we were able to download.
First downloaded DLL: hxxps://www[.]yell[.]ge/nav_logo/AEnTP/
Downloaded filename: RwuuPYoVei7FkJB.dll
(SHA256: A1D513E4A5C83895E5769C994C4D319959EF5AE3F679CE6C0C5211B5BECA7695)
Second downloaded DLL: hxxps://yakosurf[.]com/wp-includes/S/
Downloaded filename: lw1JF63zARLUV8UwpwGnWpgg.dll
(SHA256: 1B8638333751EFCB6B5332C801C11DF0DE3D7077C6ACEA1D663C0302519D7172)
In both cases, it is actually the same DLL, except for a small difference that changes the SHA256 hash.
Looking into this sample, we identified the first DLL as part of the Emotet malware family.
Figure 21. Cortex XDR prevented attempts to read passwords saved in the Firefox browser.
Cortex XDR stops this operation synchronously, so the next attack stages are not performed. This malware tries to read passwords in this order: first Firefox, then Microsoft Edge and later, Google Chrome.
For the demonstration, we will illustrate Cortex XDR with report mode. We will see that the Credential Gathering Protection Module also detects attempts to read Chromium-based browsers' saved passwords.
Figure 22. Cortex XDR detected attempts to read passwords saved in the Microsoft Edge browser.Figure 23. Cortex XDR detected attempts to read passwords saved in the Google Chrome browser.
Emotet?
Since we saw two different cases involving Emotet, we looked a bit deeper into this malware family and its methods for third-party credential gathering. We saw that sometimes malware does not even need to implement all the logical conditions on its own. It can just wrap existing tools, like the WebBrowserPassView Nirsoft tool, to reveal the passwords stored by the web browsers.
Figure 24. WebBrowserPassView.exe shows usernames, passwords and the file path that stores each of them.
We can see the login data file for Chromium-based browsers, and the logins.json file for the Firefox browser.
Figure 25. Cortex XDR prevented attempts to read browsers' saved passwords by WebBrowserPassView.exe.
Conclusion
It turns out that the way certain third-party software stores credentials is less secure than we thought. Most of these programs store the user’s credentials on the local disk, via file or registry values. This fact can be the one weak spot in the chain that attackers wish to find, giving them the access to perform an attack against an organization.
Palo Alto Networks customers using Cortex XDR receive protections using the new Credential Gathering Protection Module for the scenarios described above as well as other credential gathering techniques not mentioned in this write-up. Additional layers of protection – including Local Analysis, Behavioral Threat Protection, BIOC and Analytics BIOCs rules – are also available.
Palo Alto Networks customers that use WildFire receive protections from tools implementing these credential gathering attempts.
Nirsoft tools are marked as grayware in WildFire and are blocked by the XDR Agent.
Indicators of Compromise
Unauthorized access to the following registry values
In early August, Unit 42 researchers discovered attacks leveraging several vulnerabilities in devices made by D-Link, a company that specializes in network and connectivity products. The vulnerabilities exploited include:
If the devices are compromised, they will be fully controlled by attackers, who could utilize those devices to conduct further attacks such as distributed denial-of-service (DDoS) attacks. The exploit attempts captured by Unit 42 researchers leverage the aforementioned vulnerabilities to spread MooBot, a Mirai variant, which targets exposed networking devices running Linux.
While D-Link has published security bulletins regarding all the vulnerabilities mentioned here, some users may be running unpatched or older versions or devices. Unit 42 strongly recommends applying upgrades and patches where possible.
Palo Alto Networks Next-Generation Firewall customers receive protections through cloud-delivered security services such as IoT Security, Advanced Threat Prevention, WildFire and Advanced URL Filtering, which can detect and block the exploit traffic and malware.
Four known vulnerabilities were exploited in this attack. Upon successful exploitation, the wget utility executes to download MooBot samples from the malware infrastructure and then executes the downloaded binaries. Vulnerability-related information is shown in Table 1.
The attacker utilizes four D-Link vulnerabilities that could lead to remote code execution and download a MooBot downloader from host 159.203.15[.]179.
Figure 2. CVE-2015-2051 exploit payload.The exploit targeting the older D-Link routers takes advantage of vulnerabilities in the HNAP SOAP interface. An attacker can perform code execution through a blind OS command injection.
Figure 3. CVE-2018-6530 exploit payload.The exploit works due to the older D-Link router's unsanitized use of the “service” parameters in requests made to the SOAP interface. The vulnerability can be exploited to allow unauthenticated remote code execution.
Figure 4. CVE-2022-26258 exploit payload.The exploit targets a command injection vulnerability in the /lan.asp component. The component does not successfully sanitize the value of the HTTP parameter DeviceName, which in turn can lead to arbitrary command execution.
Figure 5. CVE-2022-28958 exploit payload.The exploit targets a remote command execution vulnerability in the /shareport.php component. The component does not successfully sanitize the value of the HTTP parameter value, which can lead to arbitrary command execution.
Malware Analysis
All the artifacts related to this attack are shown in the following table:
Unit 42 researchers conducted analysis on the downloaded malware sample. Based on its behavior and patterns, we believe that the malware samples that were hosted on 159.203.15[.]179 relate to a variant of the Mirai botnet called MooBot.
Figure 6. MooBot random string generator.
The most obvious feature of MooBot is the executable file containing the string w5q6he3dbrsgmclkiu4to18npavj702f, which will be used to generate random alphanumeric strings.
Upon execution, the binary file prints get haxored! to the console, spawns processes with random names and wipes out the executable file.
Figure 7. MooBot creates processes.
As a variant, MooBot inherits Mirai’s most significant feature – a data section with embedded default login credentials and botnet configuration – but instead of using Mirai’s encryption key, 0xDEADBEEF, MooBot encrypts its data with 0x22.
Figure 8. MooBot configuration decode function.
After decoding its C2 server vpn.komaru[.]today from configuration, MooBot will send out a message to inform the C2 server that a new MooBot is online. The message starts with the hardcoded magic value 0x336699.
At the time of our analysis, the C2 server was offline. According to the code analysis, MooBot will also send heartbeat messages to the C2 server and parse commands from C2 to start a DDoS attack on a specific IP address and port number.
Conclusion
The vulnerabilities mentioned above have low attack complexity but critical security impact that can lead to remote code execution. Once the attacker gains control in this manner, they could take advantage by including the newly compromised devices into their botnet to conduct further attacks such as DDoS.
Therefore, we strongly recommend applying patches and upgrades when possible.
Palo Alto Networks customers receive protections from the vulnerability and malware through the following products and services:
Next-Generation Firewalls with a Threat Prevention security subscription can block the attacks with Best Practices via Threat Prevention signatures 38600, 92960, 92959 and 92533.
WildFire can stop the malware with static signature detections.
The Palo Alto Networks IoT security platform can leverage network traffic information to identify the vendor, model and firmware version of a device and identify specific devices that are vulnerable to the aforementioned CVEs.
In addition, IoT Security has an inbuilt machine learning-based anomaly detection that can alert the customer if a device exhibits non-typical behavior, such as a sudden appearance of traffic from a new source, an unusually high number of connections or an inexplicable surge of certain attributes typically appearing in IoT application payloads.
The Tor project provides one of the most well-known tools that users can leverage to stay anonymous on the internet. People use Tor for many different reasons, both benign and malicious. However, allowing Tor traffic on enterprise networks opens the door to a variety of potential abuses and security risks.
Political activists use Tor to express their views while staying out of sight of their governments. Cybercriminals use Tor to evade defenses and hide their identity from law enforcement. Tor is famous for enabling the operation of dark web marketplaces, such as Silk Road, where customers could procure a wide range of illicit goods, including drugs, weapons and fake identification documents. Malware authors regularly use Tor for denial-of-service (DoS) attacks, hidden reconnaissance, exploitation, command and control communication and data exfiltration.
For enterprises concerned about the risks of Tor traffic, the use of Tor for malware, command and control, exfiltration, and hidden reconnaissance are some of the most important security risks. Also, employees can use Tor to bypass content blocking policies (e.g., blocking of adult or gambling sites) such as those provided by the Palo Alto Networks DNS Security and Advanced URL Filtering services. Users can also elude geographic restrictions of services or buy illicit goods unchecked using Tor. To avoid these risks, we advise the blocking of Tor in enterprise networks.
Emphasizing the importance of monitoring or blocking Tor traffic in the enterprise, we observed 6,617,473 sessions to or from 691 devices within 204 customer networks in one month.
Palo Alto Networks provides two solutions as part of Threat Prevention that are best used together to filter Tor traffic. We maintain a verified and built-in Tor Exit IP External Dynamic List that our customers can use to block connections from Tor Exit nodes. Customers can also leverage the Palo Alto Networks traffic classification system App-ID to block incoming and outgoing Tor traffic. Additionally, customers can utilize Cortex XDR to alert on and respond to Tor-related threats on endpoints, in the network or in the cloud.
The goal of the Tor network is to provide a tool to internet users for anonymous communication. Tor stands for The Onion Router, which is the software that enables Tor nodes to participate in onion routing. Onion routing is a technique allowing anonymous communication. Anonymity on the internet means that no one can connect a user's actions and identity. For example, anonymous communication would mean that when a user connects to a server hosting a forum and makes a public post with a made-up username, neither a global observer, the forum operators nor other users should be able to tell the user's true identity based on these actions.
To better understand how hard it is to stay anonymous, let us introduce the imaginary country of lemons ruled by the tyrant Lemonheads, where it is frowned upon to like or discuss oranges. Emilia, our heroine, is part of a small rebellious group that loves oranges. To discuss her passion with others, she would like to visit a site called peel-the-orange[.]com.
One of Emilia's friends, Bob, always used to connect to peel-the-orange[.]com without using any anonymity-enhancing technology. Bob told Emilia that his traffic is encrypted since he connects using HTTPS, so no one can read what he is doing. Unfortunately for Bob, HTTPS does not encrypt the DNS name, peel-the-orange[.]com, so the lemon secret police could easily tell that he was visiting a site for orange enthusiasts. Therefore, he ended up on the bad lemons list.
After that, everyone in their group became more cautious. Emilia's other friends started using a foreign VPN provider to funnel their traffic through the VPN server and hide their identities. This effort truly made it hard for the lemon police to find out who is connecting to forbidden sites.
Jess, another friend of Emilia, was high on the Lemonheads’ list of suspected orange sympathizers. Observing Jess’s traffic, it became clear to the secret lemon police that she is frequently connecting to a known VPN provider. While the VPN provider helped Jess protect her identity, it proved to be a single point of failure. A VPN provider can be bribed, threatened or hacked, which are the favorite methods of the Lemonheads. More advanced adversaries (such as the lemon secret police) could employ correlation attacks based on statistical methods to match incoming and outgoing traffic to and from the VPN servers.
The lemon secret police initiated “Operation Super Sour” by compromising several servers of the VPN provider and stealing the complete list of all lemon citizens visiting peel-the-orange[.]com. As a result, many of Emilia's friends, including Jess, ended up on the bad lemons list. Furthermore, the lemon government started censoring connections to known foreign VPN server IP addresses to stop the dissidents’ decadent love for oranges.
Emilia became very careful after that last incident. She looked for a solution that would keep her safe, even if the lemon secret police could compromise the proxy/VPN servers she used. Additionally, she wanted to ensure that even peel-the-orange[.]com would not know her identity if someone infiltrated their server.
She soon found Tor, which seemed like it could help her stay anonymous. However, Emilia soon discovered that even this wasn’t foolproof. She told a few acquaintances about Tor, but the lemon secret police were able to identify one of them, Gordon, because he shared his nickname Orange Cake across different sites. Luckily, Emilia only used her pseudonym Orange Girl on peel-the-orange[.]com.
How Tor Works on a High Level
Figure 1 helps us explain how, using Tor, Emilia can stay anonymous even if the Lemonheads would have full global visibility of network traffic or could compromise a couple of Tor nodes.
At first, we assume that Emilia already has a Tor circuit built, meaning that her computer already selected three Tor nodes (servers running Tor software) to relay messages and obtained a shared key with each of them.
Figure 1. High-level overview of how connecting to a website looks using an already built Tor circuit.
Emilia’s computer first encrypts the private data in three layers (step 1 in Figure 1), hence the name onion routing. Her computer encrypts the data in reverse order: first with the key of the last exit node (Kn3), then with the middle relay node’s key (Kn2) and finally with the guard node’s key (Kn1). The guard node receives the data, removes the outermost layer of encryption using Kn1 and sends the decrypted message to the relay node. The middle node removes the next layer using Kn2 and relays it to the exit node. Finally, the exit node decrypts the message with Kn3 and sends the original data to the web server (in this example, peel-the-orange[.]com). The layered encryption enables secrecy and limits knowledge about who is involved in the communication as only the nodes that know the keys can decrypt the messages.
Table 1. This shows which nodes in the column headers know which nodes in the row headers.
Table 1 summarizes which nodes know about which other nodes. The guard node knows who Emilia is and the next node that receives Emilia’s message, the middle relay node. However, the guard node does not know about the last exit node and Emilia’s final destination, because decrypting with only Kn1, the message is still garbled for the entry node. The relay node knows the least. It does not know who is the original sender or the final destination and only knows the entry and exit nodes. The exit node knows about the middle relay node and the destination server, while the destination server only knows about the exit node.
Messages on the way back to Emilia are passed back in a similar fashion, each node adding a layer of encryption using the key shared with Emilia.
Figure 2. The global Tor Network and a global observer.
Figure 2 depicts Lemonheads as a global observer. When Emilia uses Tor, the Lemonheads can only observe her connection to the entry node. Even if they have complete global visibility of the messages passed, it becomes hard for them to track Emilia’s messages as they get mixed in with all Tor users’ traffic, and the layer of encryption changes every time the message is passed to another node. As discussed earlier, if Emilia were to use a single VPN provider, it would know what sites Emilia visits. Additionally, the Lemonheads could observe incoming and outgoing messages from the VPN server and possibly determine which sites Emilia is visiting.
A curious question is: How can Emilia share keys with Tor nodes without revealing her identity? Solving this problem is a two-part puzzle.
First, how can two nodes cooperate to create a key only known to them on a public network where anyone can read all communication? The answer is the Diffie-Hellman key Exchange (DHE) protocol. The idea is that first, both parties need to individually generate their own private secrets that they combine into a shared secret (Kn1) that only the two of them can compute. In practice, authenticated ECDHE based on elliptic cryptography is used to solve issues with vanilla DHE.
At this point, Emilia could go to each Tor node and establish a key with them individually, but that would reveal her identity to each of them. The second piece of the puzzle is establishing the keys using DHE. Instead of communicating directly with all three nodes, after establishing a key with the entry node, Emilia’s computer encrypts all messages with Kn1 and sends the message to the relay node through the entry node. This means that the relay node only knows the entry node and not Emilia. Similarly, Emilia’s computer encrypts DHE messages with Kn2 and Kn1 and sends them through the guard and relay nodes to the exit node.
Unfortunately, barely after Emilia learned about Tor and started using it, the Lemonheads started censoring connections to publicly advertised Tor node IPs. To counter such efforts, volunteers started running secret Tor bridges (private replacement of publicly advertised entry nodes) and made them available in small batches to only a few users at a time.
Making the matter worse for Emilia and her fellow orange-lovers, researchers found that they can discover Tor bridges by scanning the entire IPv4 space. We do not cover all challenges using Tor and additional issues are discussed in the DefCon 2022 Tor Presentation.
In conclusion, it turns out to be a continuous cat and mouse game for someone like Emilia to maintain anonymity online.
Malicious and Benign Use Cases for Tor
Internet users utilize Tor for many malicious and benign purposes. Political activists, similar to Emilia in the examples, want to make sure that their identity remains secret and they cannot be tied back to activities condemned by their government. Other users might want to protect their privacy and keep the sites they visit secret, even if the activity is not illicit where they live.
People might use Tor to reach geographically restricted content or to circumvent censorship by their government or content blocking by their institution. For example, if Tor traffic is not blocked, customers of Advanced URL Filtering could not stop employees using Tor from circumventing category-based filtering.
Tor is also famous for its onion services. For example, Tor helps to hide multiple whistleblower websites where users can report illicit and immoral activities in their organizations without having to worry about retaliation. An onion service keeps its IP address secret by allowing users to connect only using Tor. The idea is that both the user and the onion service connect through Tor, and they meet in the middle at a rendezvous point (a Tor node). While the goal of these onion services is not necessarily to enable illicit activities, past studies have found that Tor users established a large fraction or the majority of Tor hidden services for illegal purposes. However, only 6.7% of all Tor users connect to hidden services. The vast majority of users visit clear websites that are less likely to be illicit than onion services. For example, more than a million people use Tor to view Facebook’s hidden service allowing access from areas where governments censor it.
Attackers can leverage Tor for their activities too. Attacks usually start with reconnaissance, where the attacker explores the target’s infrastructure and searches for potential vulnerabilities, for example, by scanning for open ports and running services. Using Tor, attackers can hide their location and distribute their activity to multiple exit nodes.
Similarly, malicious actors can use Tor for later steps of an attack, such as exploiting vulnerabilities found during reconnaissance, updating malicious code on the target’s machine, command and control communication, and data exfiltration. Other malicious uses of Tor include DoS attacks, fake account creation, spamming and phishing.
Miscreants have utilized Tor for ransomware attacks in a variety of ways. In the case of Ryuk and Egregor ransomware, the initial Remote Access Trojan (RAT) called SystemBC used a Tor hidden service as a backdoor for command and control communications. Using Tor hidden services for command and control is useful when building bots as this makes the command and control hard to take down and maintains its accessibility unless connections to Tor are blocked, for example, by using various Palo Alto Network products. The Gold Waterfall threat group also used Tor for backdoor communication when installing DarkSide ransomware. Tor hidden service-based leak sites also have been utilized to host stolen data related to DarkSide and Ranzy locker. Additionally, DoppelPaymerused Tor payment sites to collect ransoms. Unit 42 recently published research on Cuba Ransomware, which uses a Tor hidden service-based leak site, and BlueSky ransomware, which sends a ransom note instructing targets to download the Tor browser as part of the process of regaining access to their files.
Tor usage is not specific to malware targeting servers and personal computers. A type of Android malware also uses a Tor hidden service as a command and control server to make takedowns hard.
Additionally, researchers found that Tor is used to send various malicious spam messages, often in the form of comments and dating spam. The authors also found that emails sent through Tor can contain severe threats, including the distribution of AgentTesla RAT, Adobe-themed phishing emails and Covid-19 loan scams.
How Do Criminals Using Tor Get Caught?
While Tor provides better anonymity than many other solutions, it is not perfect.
In 2013, a Harvard student tried to avoid taking one of his final exams by sending a bomb threat. He connected through Tor to an anonymous email provider to keep his identity secret. Then he used this email provider to send the bomb threat. While he used Tor properly, the student made a big mistake when he connected to Tor from Harvard’s wifi network. The student’s mistake was that Tor hides what you do, but not the fact that you use Tor. Authorities found out from the email’s headers that someone used Tor to send the email. From there, they checked the network logs to see if any student connected to Tor around the time the university received the email. Connecting the dots, they found the culprit, who faced criminal charges.
Ross Ulbricht, the creator of the infamous onion service Silk Road, also used Tor correctly but made a different operational mistake that led to his arrest. Silk Road was the most well-known dark web market at its time, where sellers offered goods like drugs, counterfeit cash, forged ID documents and firearms. The FBI found that early on, someone using the pseudonym “Altoid” was astroturfing to promote the Silk Road marketplace. Eight months later, Ulbricht posted a job advertisement using this pseudonym and the contact rossulbricht@gmail[.]com to hire an IT expert who can help with “a venture backed Bitcoin startup company.” The FBI was reportedly then able to access both the logs of a VPN server Ulbricht used and Google’s log of access to his Gmail address. Both records pointed to an internet cafe in San Francisco and led to his arrest. (Ulbricht’s mistake is similar to the mistake made by Gordon in our initial example, where he was caught because of his use of the nickname Orange Cake across multiple services.)
Attackers can deanonymize Tor users via other methods, for example, by using JavaScript or by setting up rogue Tor nodes (which might be happening in the real world now). The takeaway is that while Tor does offer a level of anonymity, users can leak their identity via operational mistakes, or they can be identified if the observer is determined and has the resources.
Methods to Block Tor Traffic
Table 2. How different methods can be used to stop malicious actors from leveraging Tor. The cells labeled Part 1* and 2* mean that the two solutions together need to be used to protect the enterprise.
To stop traffic to and from the Tor network, we can either block publicly advertised Tor IPs or identify and block Tor application traffic. Table 2 summarizes the use cases for each type of blocking mechanism. First, we can use the list of known exit node IPs to block attacks from Tor such as reconnaissance, exploitation, command and control communication, data exfiltration and DoS attacks. Using the list of known guard node IPs, we can stop our users and their machines from sending traffic to Tor and prevent data exfiltration, command and control communication, evasion of geo-restrictions and content blocking, and visits to .onion sites.
As the list of Tor bridge nodes is unknown, guard node IP-based blocking is only a partial solution. Instead, we can directly detect and block Tor traffic using App-ID, the Palo Alto Networks traffic classification system. Next to using available guard and bridge node IPs, App-ID looks at characteristics of connections – such as the cipher suite used or the size of data packets – to identify Tor traffic.
Furthermore, an attacker can initiate data exfiltration and command and control communication from the Tor network or the compromised machine. Therefore, to halt these attacks, it is best to use both exit IP-based and traffic analysis-based blocking.
Palo Alto Networks collects all publicly advertised Tor exit IPs and builds a circuit using each of them to test whether they work. The known and working Tor exits list constitutes our predefined Tor Exit IP External Dynamic List.
Using the Tor Exit IP External Dynamic List and App-ID, we observe that Tor usage is common in the enterprise, as we identified 6,617,473 sessions on 691 devices within 204 customer networks during one month.
Along with blocking Tor traffic, an enterprise can leverage endpoint protections such as Cortex XDR to provide coverage for Tor-based threats. Cortex XDR builds on user and entity behavior analytics (UEBA), endpoint detection and response (EDR), network detection and response (NDR) and cloud audit logs to detect the following activities:
Tor provides anonymity to its users, which they leverage for both benign and malicious uses. On the one hand, Tor can help political activists in oppressive regimes, improve privacy and protect whistleblower websites. On the other hand, Tor is useful for various malicious activities, including anonymous reconnaissance, data exfiltration, evasion of geo-restrictions, evasion of content blocking, and the running of illicit marketplaces on the dark web.
As cybercriminals often use Tor for malicious purposes, blocking Tor traffic in an enterprise setting is advisable. We find that attempts to use Tor are common, and we identified 6,617,473 sessions to or from 691 devices on 204 customer networks in one month. Palo Alto Networks provides two solutions for blocking Tor traffic as part of Threat Prevention that are best used together. We provide a verified and built-in Tor Exit IP External Dynamic List to our customers that they can use to block connections to Tor Exit nodes. Additionally, Tor traffic in the enterprise network can be blocked using the Palo Alto Networks traffic classification system App-ID. Furthermore, customers can leverage Cortex XDR to alert on and respond to Tor-related activities on endpoint devices, in the network or in the cloud.
Acknowledgments
We want to thank Michael Giuntoli, Yue Guan, Russell Holloway, Erez Levy, Daiping Liu, Erica Naone, Jason Reverri, Siddhart Shibiraj, Zachary Weinberg, Zhibin Zhang and Jimmy Chen for their invaluable input on this blog post.
Appendix: More Details on the DHE Key Exchange
Figure 3. How the basic DHE protocol for key exchange would look between Emilia’s computer and the Tor guard node. Note that in practice ECDHE (DHE with elliptic curve crypto) is used with node authentication.
We explain the DHE protocol in Figure 3. The idea is that first, both parties need to individually generate their own secret (a and b randomly selected) that they combine into a shared secret (Kn1) that only the two of them know. They achieve this by selecting large public prime numbers g and p and calculating A (= ga mod p) and B (= gb mod p), the public counterparts of their secrets (a and b). The trick is that only Emilia can calculate Kn1 (= Ba mod p) from public B, and only the entry guard can calculate Kn1 (= Ab mod p) from public A (leveraging that (ga)b = (gb)a).
There are two drawbacks to DHE. First, it is computationally expensive. Therefore, a more advanced version building on elliptic cryptography is used in practice called ECDHE. Second, Meddler-in-the-Middle (MitM) attacks are possible against plain DHE protocols as all messages are public. For example, the Lemonheads could act like they are the entry node to Emilia, generate keys with her, and at the same time pretend that they are Emilia to the entry node and share a different key with it. To counter MitM attacks, Tor uses an authenticated version of DHE. In the case of Tor networks, users authenticate Tor nodes by contacting several known directory authorities to retrieve node identities and certificates.
Black Basta is ransomware as a service (RaaS) that first emerged in April 2022. However, evidence suggests that it has been in development since February. The Black Basta operator(s) use the double extortion technique, meaning that in addition to encrypting files on the systems of targeted organizations and demanding ransom to make decryption possible, they also maintain a dark web leak site where they threaten to post sensitive information if an organization chooses not to pay ransom.
Black Basta affiliates have been very active deploying Black Basta and extorting organizations since the ransomware first emerged. Although the Black Basta affiliates have only been active for the past couple of months, based on the information posted on their leak site, they have compromised over 75 organizations at the time of this publication. Unit 42 has also worked on several Black Basta incident response cases.
The ransomware is written in C++ and impacts both Windows and Linux operating systems. It encrypts users’ data using a combination of ChaCha20 and RSA-4096, and to speed up the encryption process, the ransomware encrypts in chunks of 64 bytes, with 128 bytes of data remaining unencrypted between the encrypted regions. The faster the ransomware encrypts, the more systems can potentially be compromised before defenses are triggered. It is a key factor affiliates look for when joining a Ransomware-as-a-Service group.
Black Basta is ransomware as a service (RaaS) that leverages double extortion as part of its attacks. The attackers not only execute ransomware but also exfiltrate sensitive data and threaten to release it publicly if the ransom demands are not met. The threat actors behind the ransomware deploy a name-and-shame approach to their victim, where they use a Tor site, Basta News, to list all of the victims who have not paid the ransom.
Although the Black Basta RaaS has only been active for a couple of months, according to its leak site, it had compromised over 75 organizations at the time of this publication. At least 20 victims were posted to its leak site in the first two weeks of the ransomware’s operation, which indicates the group likely is experienced in the ransomware business and has a steady source of initial access.
It is also possible that this is not a new operation but rather a rebrand of a previous ransomware group that brought along their affiliates. Based on multiple similarities in tactics, techniques and procedures (TTPs) - victim-shaming blogs, recovery portals, negotiation tactics, and how quickly Black Basta amassed its victims - that the Black Basta group could include current or former members of the Conti group.
Unit 42 has observed the Black Basta ransomware group using QBot as an initial point of entry and to move laterally in compromised networks. QBot, also known as Qakbot, is a Windows malware strain that started as a banking trojan and evolved into a malware dropper. It has been used by other ransomware groups, including MegaCortex, ProLock, DoppelPaymer and Egregor. While these ransomware groups used QBot for initial access, the Black Basta group was observed using it for both initial access and to spread laterally throughout the network.
Figure 1 below shows the standard attack lifecycle observed with Black Basta ransomware.
Figure 1. Black Basta attack lifecycle based on Unit 42 incident response cases.
Technical Details
Black Basta is written in C++ and is cross-platform ransomware that impacts both Windows and Linux systems. In June 2022, a VMware ESXi variant of Black Basta was observed targeting virtual machines running on enterprise Linux servers.
The ransomware includes anti-analysis techniques that attempt to detect code emulation or sandboxing to avoid virtual/analysis machine environments. It also supports the command line argument -forcepath that is used to encrypt files in a specified directory. Otherwise, the entire system, except for certain critical directories, is encrypted.
The ransomware spawns a mutex with a string of dsajdhas.0 to ensure a single instance of the malware is running at a time. Then it will iterate through the entire file system, encrypting files with a file extension of .basta.
Black Basta ransomware encrypts users’ data through a combination of ChaCha20 and RSA-4096. To speed up the encryption process, the ransomware encrypts in chunks of 64 bytes, with 128 bytes of data remaining unencrypted between the encrypted regions. The ransomware also attempts to delete shadow copies and other backups of files using vssadmin.exe, a command-line tool that manages Volume Shadow Copy Service (VSS), which captures and copies stable images for backups on running systems.
It writes the Random-letters.ico and Random-letters.jpg files to the %TEMP% directory. The .jpg file is leveraged to overwrite the desktop background and appears as follows:
Figure 2. Black Basta desktop wallpaper.
It adds a custom icon to the registry, corresponding to the .basta icon, which is shown in Figure 3.
Figure 3. Black Basta icon.
It will then boot the system in safe mode and proceed to encrypt files. Following successful encryption, the file’s extension is changed to .basta and the ransomware will write numerous instances of readme.txt, which contains the following ransom note:
Figure 4. Black Basta ransom note.
Tactics, Techniques and Procedures
We have observed Black Basta affiliates leveraging the following TTPs:
Tactic / Technique
Notes
TA0001 Initial Access
T1566.001. Phishing: Spear phishing Attachment
Victims receive spear phishing emails with attached malicious zip files - typically password protected. That contains malicious doc including .doc, .pdf, .xls
TA0002 Execution
T1569.002. System Services: Service Execution
Black Basta has installed and used PsExec to execute payloads on remote hosts.
T1047. Windows Management Instrumentation
Utilizes Invoke-TotalExec to push out the ransomware binary.
T1059.001. Command and Scripting Interpreter: PowerShell
Black Basta has encoded PowerShell scripts to download additional scripts.
TA0003 Persistence
T1136. Create Account
Black Basta threat actors created accounts with names such as temp, r, or admin.
T1098. Account Manipulation
Added newly created accounts to the administrators' group to maintain elevated access.
T1543.003. Create or Modify System Process: Windows Service
Creates benign-looking services for the ransomware binary.
T1574.001. Hijack Execution Flow: DLL Search Order Hijacking
Black Basta used Qakbot, which has the ability to exploit Windows 7 Calculator to execute malicious payloads.
TA0004 Privilege Escalation
T1484.001. Domain Policy Modification: Group Policy Modification
Black Basta can modify group policy for privilege escalation and defense evasion.
T1574.001. Hijack Execution Flow: DLL Search Order Hijacking
Black Basta used Qakbot, which has the ability to exploit Windows 7 Calculator to execute malicious payloads.
T1543.003. Create or Modify System Process: Windows Service
Creates benign-looking services for the ransomware binary.
TA0005 Defense Evasion
T1484.001. Domain Policy Modification: Group Policy Modification
Black Basta can modify group policy for privilege escalation and defense evasion.
T1218.010. System Binary Proxy Execution: Regsvr32
Black Basta has used regsvr32.exe to execute a malicious DLL.
T1070.004. Indicator Removal on Host: File Deletion
Attempts to delete malicious batch files.
T1112. Modify Registry
Black Basta makes modifications to the Registry.
T1140. Deobfuscate/Decode Files or Information
Initial malicious .zip file bypasses some antivirus detection due to password protection.
T1562.001. Impair Defenses: Disable or Modify Tools
Disables Windows Defender with batch scripts, such as d.bat or defof.bat.
T1562.004. Impair Defenses: Disable or Modify System Firewall
Uses batch scripts, such as rdp.bat or SERVI.bat, to modify the firewall to allow remote administration and RDP.
T1562.009. Impair Defenses: Safe Boot Mode
Uses bcdedit to boot the device in safe mode.
T1574.001. Hijack Execution Flow: DLL Search Order Hijacking
Black Basta used Qakbot, which has the ability to exploit Windows 7 Calculator to execute malicious payloads.
T1622. Debugger Evasion
Uses IsDebuggerPresent to check if processes are being debugged.
TA0006 Credential Access
T1555. Credentials from Password Stores
Black Basta uses Mimikatz to dump passwords.
TA0007 Discovery
T1087.002. Account Discovery: Domain Account
Used commands such as net user /domain and net group /domain.
T1016. System Network Configuration Discovery
Lists internal IP addresses to target in C:\Windows\pc_list.txt – typically found on the Domain Controller.
T1082. System Information Discovery
Uses GetComputerName to query the computer name.
T1622. Debugger Evasion
Uses IsDebuggerPresent to check if processes are being debugged.
T1560.001. Archive Collected Data: Archive via Utility
TA0010 Exfiltration
T1567. Exfiltration over Web Service
TA0011 Command and Control
T1219. Remote Access Software
Black Basta has installed and used legitimate tools such as TeamViewer and AnyConnect on targeted systems.
T1573. Encrypted Channel
Uses Qakbot primarily and Cobalt Strike.
TA0040 Impact
T1486. Data Encrypted for Impact
Black Basta modifies the Desktop background by adding a .jpg in C:\Temp and creating a registry key HKCU\Control Panel\Desktop. Additionally modifies the registry to change the icon of encrypted files.
It encrypts files excluding those with a .exe, .cmd, .bat and .com extension. Uses ChaCha20 or RSA-4096 to encrypt victims.
T1489. Service Stop
Uses sc stop and taskkill to stop services.
T1490. Inhibit System Recovery
Black Basta deletes Volume Shadow Copies using vssadmin.
Table 1. Tactics, techniques and procedures for Black Basta activity.
Victimology
The ransomware group and its affiliate program reportedly compromised multiple large organizations, in sectors including consumer and industrial products; energy, resources and agriculture; manufacturing; utilities; transportation; government agencies; professional services and consulting; and real estate.
Black Basta operators also posted on dark web forums expressing interest in attacking organizations based in Australia, Canada, New Zealand, the U.K. and the U.S. Threat actors using the ransomware impacted organizations based in the U.S., Germany, Switzerland, Italy, France and the Netherlands (listed in descending order by numbers of allegedly breached organizations).
Figure 5. Black Basta post on dark web forums.
The threat actor(s) responsible for Black Basta operate a cybercrime marketplace and victim name-and-shame blog. This site is hosted as a Tor hidden service, where the Black Basta ransomware group lists their victims’ names, descriptions, percentage of stolen data which has been published, number of visits and any data exfiltrated. There were 75 victims listed on the leak site at the time of writing.
Figure 6. Black Basta News site where the threat actors post allegedly breached organizations (details redacted) and number of visits.
Courses of Action
Several adversarial techniques were observed in activity associated with Black Basta, and the following measures are suggested within Palo Alto Networks products and services to mitigate threats related to Black Basta ransomware, as well as other malware using similar techniques:
Product / Service
Course of Action
Initial Access
The below courses of action mitigate the following techniques:
The below courses of action mitigate the following techniques:
Create Account [T1136], Account Manipulation [T1098], Regsvr32 [T1218.010], File Deletion [T1070.004], Disable or Modify Tools [T1562.001], Modify Registry [T1112], Deobfuscate/Decode Files or Information [T1140], Disable or Modify System Firewall [T1562.004], Windows Service [T1543.003], DLL Search Order Hijacking [T1574.001], Group Policy Modification [T1484.001]
NEXT-GENERATION FIREWALLS
Ensure that the User-ID Agent has minimal permissions if User-ID is enabled
Ensure that security policies restrict User-ID Agent traffic from crossing into untrusted zones
Ensure that the User-ID service account does not have interactive logon rights
Ensure that 'Include/Exclude Networks' is used if User-ID is enabled
Ensure remote access capabilities for the User-ID service account are forbidden.
Ensure that User-ID is only enabled for internal trusted interfaces
Black Basta ransomware operators have been active since at least April 2022. Although their RaaS has only been active for the past couple of months it had compromised at least 75 organizations at the time of this publication. Due to the high-profile nature and steady stream of Black Basta attacks identified globally in 2022, the operators and/or affiliates behind the service likely will continue to attack and extort organizations.
Palo Alto Networks helps detect and prevent Black Basta ransomware in the following ways:
WildFire: All known samples are identified as malware.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call North America Toll-Free: 866.486.4842 (866.4.UNIT42), EMEA: +31.20.299.3130, APAC: +65.6983.8730, or Japan: +81.50.1790.0200.
Indicators of compromise and Black Basta-associated TTPs can be found in the Black BastaATOM.
Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Instead of creating phishing pages from scratch, more and more cybercriminals are now abusing legitimate software-as-a-service (SaaS) platforms, including various website builders or form builders, to host their phishing pages. Since these URLs are hosted on legitimate domains, they can be especially difficult for many phishing detection engines to detect. Furthermore, these platforms typically require little to no coding experience, significantly lowering the barrier to entry for creating and launching phishing attacks.
From the beginning of 2020 to June 2022, Palo Alto Networks analyzed the URLs detected by our Advanced URL Filtering service, and discovered that the number of phishing URLs hosted on legitimate SaaS platforms has continued to increase at an alarming rate. In fact, from June 2021-June 2022, the rate of newly detected phishing URLs hosted on legitimate SaaS platforms has increased over 1100%.
The Palo Alto Networks Advanced URL Filtering uses deep learning to analyze the content of each webpage at the URL level instead of the domain level. Customers with an Advanced URL Filtering subscription therefore receive protections from these platform-abuse phishing attacks.
Today, more organizations are adopting existing SaaS tools for tasks like handling file storage, building websites, and more importantly, enabling collaboration within and outside of the organization. For example, many website builders allow users to easily create websites without having to write any code themselves, and form builders allow users to easily create and share surveys, registration forms, etc. Recently, we’ve seen that cybercriminals have begun to abuse these SaaS platforms for their own nefarious uses. In early 2022, we noticed an uptick in phishing URLs hosted on legitimate SaaS platforms, and we decided to further investigate this trend.
Methodology
First, we gathered a list of various SaaS platforms that could potentially be used to host phishing attacks. We then looked at the phishing URLs discovered by The Palo Alto Networks Advanced URL Filtering service from January 2020-June 2022 and used signature-based pattern matching to determine which phishing URLs were hosted on each SaaS platform.
Examples of the types of SaaS platforms we studied are shown in Table 1.
Platform Type
Description
File Sharing
Sites for hosting and/or sharing files
Form Builders
Sites for creating forms, surveys, etc.
Website Builders
Popular website builders, typically requiring no coding experience
Note Taking/Collaboration
Sites for taking notes, writing documentation, creating internal dashboards, etc. Various productivity tools.
Design/Prototyping
Sites for designing/prototyping wireframes, infographics, mockups, etc.
Personal Branding
Sites for hosting social media links, personal portfolios, etc.
Table 1. Breakdown of types ofSaaS platforms studied in this research.
Results: Platform-Abuse Phishing Is on the Rise
In Figures 1 and 2 respectively, we show the number of newly discovered phishing URLs hosted on legitimate SaaS platforms per week, as well as the percentage of all newly discovered phishing URLs that we found being hosted on legitimate SaaS platforms. We can see that the prevalence of platform-abuse phishing URLs has increased significantly from 2020, both in terms of raw numbers and percentage. Although there was a slight dip during the 2021-22 holiday season, starting in February 2022, the trend began to surge once again.
Figure 1. Newly created phishing URLs hosted on legitimate SaaS platforms per week.Figure 2. Percentage of newly discovered phishing URLs hosted on legitimate SaaS platforms.
Next, we separately analyzed the trends in each SaaS platform subcategory and normalized each subcategory’s “platform abuse” rate to a prevalence value between 0 and 1. A value of 1 represents the week in which that platform type saw the largest number of new phishing URLs.
Figure 3. Phishing prevalence within each SaaS platform subcategory, normalized.
Generally speaking, each type of SaaS platform saw an increase in phishing activity in the latter half of 2021, with the most noticeable increases occurring between September-October 2021. More recently, we observed a larger increase beginning in February 2022. With new SaaS platforms continuing to rise in popularity, it is likely that this trend will continue into the future, making it absolutely critical that URL Filtering products are equipped with the right capabilities to detect these types of phishing URLs.
Platform-Abuse Phishing Case Studies
We have highlighted a variety of case studies to demonstrate the types of tactics these platform-abuse phishing URLs employ.
In Figure 4, we see a file-sharing URL that shows a preview of a document related to a remittance payment. However, upon clicking the “View Now” button, the user is taken to a credential-stealing page built using a popular website builder, which prompts the user to enter their login credentials to view a sensitive document.
Figure 4. Left: Landing page for a phishing attack, hosted on a file-sharing site. Sent in an email with the subject line: “Re: [REDACTED COMPANY NAME] Wire.” Right: Credential-stealing page built using a popular website builder, linked to by the page on the left.In Figure 5, we see an example of a credential-stealing page hosted on a site built by a legitimate form builder. On the page where the user is prompted to enter a password, the attacker has embedded a logo, imitating a reputable brand in order to make the page appear like a legitimate login portal. Since the password prompt only appears after some user interaction (entering the email address on the first page), this phishing page may be more difficult for automated crawler-based detection engines to detect.
Figure 5. Credential-stealing page built using a popular form builder. Sent in an email with the subject line: “Invoice 071158.”
Furthermore, we noticed several examples of landing pages that don’t host the credential-stealing forms themselves, but rather contain urgent-sounding language that prompts the user to click on a link or button, which then leads to a different credential-stealing page. Using landing pages in phishing campaigns may increase the number of clicks necessary to arrive at the credential-stealing page, but the practice has an important benefit: In the event that the final credential-stealing page is taken down, the attacker can simply change the link and point to a new credential-stealing page, preserving the effectiveness of the original campaign.
Link-hosting sites are an example of a type of SaaS platform that attackers can abuse to host such landing pages for phishing attacks. These platforms allow users to host links to their various social media accounts on a single page, giving them the ability to consolidate their online presence.
As one such link-hosting platform started to gain more popularity in 2021, we observed more and more landing pages for phishing attacks being hosted on the platform. (This trend can be seen in Figure 3 by observing the increase in phishing URLs hosted on “Personal Branding” platforms starting in the latter half of 2021.) An example of such a landing page is shown in Figure 6.
Figure 6. Landing page for a phishing attack created using a popular link-hosting platform, discovered on Nov. 29, 2021.
An article published by Cofense suggests that these more niche platforms may be less effective at finding hosted threats, especially compared to sites and tools from popular cloud vendors. By utilizing these niche platforms, attackers may be able to put up phishing pages that stay live for a longer period of time.
This suggests that attackers may try to take advantage of relatively new and less “obvious” platforms when deciding which platforms to use for their phishing attacks. In doing so, attackers may be attempting to take advantage of the likelihood that these platforms do not have as many resources dedicated to abuse prevention as the more established and general-purpose SaaS platforms do.
Conclusion
As seen in the case studies shown above, just because a URL is hosted on a seemingly legitimate domain or platform, doesn’t mean that the URL itself is trustworthy. More phishing URLs are being hosted on legitimate SaaS platforms, making these phishing pages both easier for attackers to create and harder for phishing detection engines to detect.
Since the Palo Alto Networks Advanced URL Filtering service analyzes web content on a URL level (using machine-learning models that study the actual content of the page), Palo Alto Networks customers who subscribe to Advanced URL Filtering receive protections from these types of phishing attacks, as well as from other web-based threats.
For end users, it is crucial to take caution when inputting one’s credentials into any online type of platform. Furthermore, users should be wary of any suspicious emails that use time-sensitive language to prompt a user to take some sort of urgent action.
When in doubt, users should manually navigate to the relevant login page directly in their browser (for example, by typing login.microsoftonline.com in the navigation bar), instead of clicking any links contained in a potentially deceptive email.
Acknowledgements
The author would like to thank Seokkyung Chung, Ziqi Dong, Wei Wang, Jun Javier Wang, Claud Xiao, Billy Melicher and Ashraf Aziz for helping gather the data sources used in this report, for curating the list of SaaS platforms and for setting the direction of this research report.
Recent observations of exploits used in the wild reveal that attackers have been making use of newly published remote code execution vulnerabilities in VMware ONE Access and Identity Manager and Spring Cloud Function, Spring MVC and Spring Web Flux, among others. Attackers have also been taking advantage of a cross-site scripting vulnerability in WordPress core, and SQL injection vulnerabilities in VoIPmonitor GUI and other services. In our observations of network security trends, Unit 42 researchers select exploits of the latest published attacks that defenders should know based on the availability of proofs of concept (PoCs), the severity of the vulnerabilities the exploits are based on and the ease of exploitation.
Other insights that could assist defenders include our rankings of the most commonly used techniques and the types of vulnerabilities that attackers have recently favored. For example, among 6,000 newly published vulnerabilities, a large portion (almost 13.3%) involve cross-site scripting, suggesting that defenders may wish to consider how best to mitigate this technique across internet-facing properties.
Other major focuses identified by evaluating more than 93 million attack sessions include remote code execution, traversal and information disclosure.
Additionally, we provide insight into how these vulnerabilities are actively exploited in the wild based on real-world data collected from Palo Alto Networks Next-Generation Firewalls. For example, we highlight how frequently the most commonly exploited vulnerabilities were attacked through networks and the locations from which the attacks appeared to originate. We then draw conclusions about the most commonly exploited vulnerabilities attackers are using, as well as the severity, category and origin of each attack.
Here, we summarize key trends from February-April 2022. In the following sections, we present our analysis of the most recently published vulnerabilities, including the severity distribution. We also classify vulnerabilities to provide a clear view of the prevalence of, say, cross-site scripting or denial-of-service.
Updated Sept. 2 at 12:30 p.m. PT to remove two CVEs that were listed in error.
Analysis of Published Vulnerabilities, February 2022 to April 2022
From February-April 2022, a total of 5,962 new Common Vulnerabilities and Exposures (CVE) numbers were registered. To better understand the potential impact these newly published vulnerabilities could have on network security, we provide our observations based on the severity, proof-of-concept code feasibility and vulnerability categories.
How Severe Are the Latest Vulnerabilities?
To estimate the potential impact of vulnerabilities, we consider their severity and examine any reliable proofs of concept (PoCs) available that attackers could easily launch. Some of the public sources we use to find PoCs are Exploit-DB, GitHub and Metasploit. Distribution of the 5,631 CVEs that have an assigned severity score of medium or higher can be seen in the following table:
Severity
Count
Ratio
PoC Availability
Critical
1033
18.3%
7.8%
High
2282
40.5%
4.8%
Medium
2316
41.1%
3.6%
Table 1. Severity distribution for CVEs registered February-April 2022.
Figure 1. Severity distribution for CVEs registered from February-April 2022, including only those rated medium-critical.
Vulnerabilities classified as critical are the least common but are also more likely to have PoCs available. The data suggests a correlation between the availability of a PoC and the severity of a vulnerability. In the period discussed, the critical-severity ratios increased while high-severity and medium-severity PoC ratios decreased slightly. Palo Alto Networks continues to leverage threat intelligence of the latest vulnerabilities and real-time monitoring of exploits in the wild to provide protections for our customers.
Vulnerability Category Distribution
The type of vulnerability is also crucial to understanding its consequences. Out of the newly published CVEs that were analyzed, 26.4% are classified as local vulnerabilities, requiring prior access to compromised systems, while the remaining 73.6% are remote vulnerabilities, which can be exploited over a network. This means that the majority of newly published vulnerabilities introduce potential opportunities for threat actors to attack vulnerable organizations from anywhere in the world.
As shown in Figure 2, we can see the most common vulnerability types ranked by how prevalent they were among the most recent set of published vulnerabilities.
Figure 2. Vulnerability category distribution for CVEs registered February 2022-April 2022.
Cross-site scripting remains the most reported vulnerability in this time period, and we also saw an increase in out-of-bounds write and information disclosure vulnerabilities published compared to last quarter. However, most of the recently published cross-site scripting and information disclosure attacks are usually at medium or high severity (rather than critical). At the same time, the prevalence of SQL injection vulnerabilities increased in February-April 2022 – and many of the vulnerabilities in this category are critical.
Network Security Trends: Analysis of Exploits in the Wild, February-April 2022
Data Collection
By leveraging Palo Alto Networks Next-Generation Firewalls as sensors on the perimeter, Unit 42 researchers observed malicious activities from February-April 2022. The malicious traffic we identified is further processed and based on metrics such as IP addresses, port numbers and timestamps. This ensures the uniqueness of each attack session and thus eliminates potential data skews. We analyzed 93 million valid malicious sessions and then correlated the refined data with other attributes to infer attack trends over time to get a picture of the threat landscape.
How Severe Were the Attacks Exploited in the Wild?
To arrive at 93 million valid malicious sessions, we excluded the original set of low-severity signature triggers that are used to detect scanning and brute-force attacks, as well as internal triggers used for research purposes. Therefore, we consider exploitable vulnerabilities with a severity ranking of medium and higher (based on the CVSS v3 Score) as a verified attack.
Figure 3. Attack severity distribution, February-April 2022, including only medium-critical vulnerabilities.
Figure 3 shows the session count and ratio of attacks grouped by the severity of each vulnerability. Compared with the previous quarters’ severity distribution, this quarter shows almost no difference for critical-, high- and medium-severity attacks. However, we still focus more on critical-severity attacks because of their greater potential impact. Many published vulnerabilities are scored medium severity, but attackers typically leverage more severe vulnerabilities for exploits. Defenders should pay attention to preventing and mitigating high- and critical-severity network attacks.
When Did the Network Attacks Occur?
Figure 4. Attack severity distribution measured weekly from February-April 2022.
For this installment of our network security trends analysis, we collected data from February-April 2022. Attackers steadily leveraged high-severity exploits throughout this period.
As we’ve seen in the past, attackers frequently used vulnerabilities disclosed recently, especially those from 2021-22. This shows the importance of updating security products and applying software patches as soon as they become available to protect against the most recently discovered vulnerabilities.
Figure 5. Observed attacks broken down by the year in which the exploited CVE was disclosed, measured weekly from February-April 2022.
Exploits in the Wild, February-April 2022: A Detailed View
Among the latest published attacks, the following exploits stood out due to their PoC availability, severity and ease of exploitation. We have provided snippets showing how attackers used open source tools to compromise the different targets, allowing defenders to better understand how the exploit operates.
VMware Workspace ONE Access and Identity Manager contain a remote code execution (RCE) vulnerability due to server-side template injection. A malicious actor can trigger a server-side template injection.
In Spring Cloud Function, when using routing functionality, it is possible for a user to provide a specially crafted SpEL as a routing expression that may result in remote code execution and access to local resources.
Figure 7. Spring Cloud SpEL remote code execution vulnerability.
A Spring MVC or Spring WebFlux application may be vulnerable to RCE via data binding. The specific exploit requires the application to run on Tomcat as a WAR deployment.
Figure 8. Spring Core remote code execution vulnerability.
In Spring Cloud Gateway, applications are vulnerable to a code injection attack when the Gateway Actuator endpoint is enabled, exposed and unsecured. A remote attacker can craft a malicious request that would allow arbitrary remote execution on the remote host.
Figure 10. Spring Cloud Gateway code injection vulnerability.
An attacker can abuse the batch requests plugin to send requests and bypass the IP restriction of Admin API. A default configuration of Apache APISIX (with default API key) is vulnerable to RCE.
SAP NetWeaver Application Server ABAP, SAP NetWeaver Application Server Java, ABAP Platform, SAP Content Server and SAP Web Dispatcher are vulnerable for request smuggling and request concatenation. An unauthenticated attacker can prepend a victim's request using arbitrary data.
Figure 12. SAP multiple products HTTP request smuggling vulnerability.
The Perfect Survey WordPress plugin does not validate and escape the question_id GET parameter before using it in a SQL statement in the get_question AJAX action, allowing unauthenticated users to perform SQL injection.
Low-privileged authenticated users in WordPress core are able to execute JavaScript/perform stored cross-site scripting attacks, which can affect high-privileged users.
Figure 14. WordPress core post slug stored cross-site scripting vulnerability.
The downloadFlile.cgi binary file in TOTOLINK has a command injection vulnerability when receiving GET parameters. The parameter name can be constructed for unauthenticated command execution.
TP-Link Tapo C200 IP camera is affected by an unauthenticated RCE vulnerability, which is present in the uhttpd binary running by default as root. The exploitation of this vulnerability allows an attacker to take full control of the camera.
Figure 17. TP-Link Tapo C200 remote code execution vulnerability.
An OS command injection vulnerability exists in the Web Manager Wireless Network Scanner functionality of Lantronix PremierWave. A specially crafted HTTP request can lead to command execution. An attacker can then make an authenticated HTTP request to trigger this vulnerability.
There is an easily exploitable vulnerability in the Oracle WebLogic Server that allows an unauthenticated attacker with network access via HTTP to compromise Oracle WebLogic Server.
Figure 20. Oracle Weblogic Server local file inclusion vulnerability.
A cross-site request forgery (CSRF) issue in /api/crontab on iRZ Mobile Routers allows a threat actor to create a crontab entry in the router administration panel. The cronjob will consequently execute the entry on the threat actor's defined interval, leading to RCE and allowing the threat actor to gain file system access.
Figure 21. iRZ Mobile Routers cross-site request forgery vulnerability.
Certain WSO2 products allow unrestricted file upload with resultant RCE. The attacker must use a /fileupload endpoint with a Content-Disposition directory traversal sequence to reach a directory under the web root, such as a ../../../../repository/deployment/server/webapps directory.
CVE-2021-28169 – Eclipse Jetty information disclosure vulnerability.
CVE-2021-31589 – BeyondTrust remote support cross-site scripting vulnerability.
Attack Category Distribution
We classified each network attack by category and organized them in terms of prevalence. In the period discussed, RCE ranks first, followed by traversal attacks. Attackers typically want to gain as much information and control as possible over the systems they target. Information disclosure attacks decreased this quarter.
After identifying the region from which each network attack originated, we discovered that the majority of them seem to originate from the United States, followed by Germany and Russia. However, we recognize that the attackers might leverage proxy servers and VPNs located in those countries to hide their actual physical locations.
Figure 24. Locations ranked in terms of how frequently they were the origin of observed attacks from February-April 2022.Figure 25. Attack geolocation distribution from February-April 2022.
Conclusion
The vulnerabilities disclosed from February-April 2022 indicate that web applications remain popular targets for attackers, and that critical vulnerabilities are more likely to have PoCs publicly available. In the meantime, we continue to capture newly published vulnerabilities that are exploited in the wild. This emphasizes the need for organizations to promptly patch their systems and implement security best practices. If not, attackers will continue to make a concerted effort to expand their arsenal of exploits whenever possible.
BlueSky ransomware is an emerging family that has adopted modern techniques to evade security defenses.
Ransomware is a malicious program designed to encrypt a user’s data and demand a ransom for the decryption. BlueSky ransomware predominantly targets Windows hosts and utilizes multithreading to encrypt files on the host for faster encryption.
In our analysis, we found code fingerprints from samples of BlueSky ransomware that can be connected to the Conti ransomware group. In particular, the multithreaded architecture of BlueSky bears code similarities with Conti v3, and the network search module is an exact replica of it.
However, in another respect, BlueSky more closely resembles Babuk Ransomware. Both use ChaCha20, an algorithm for file encryption, along with Curve25519 for key generation.
According to research done by CloudSEK, PowerShell scripting is used to drop and download BlueSky ransomware from a fake website to encrypt data. After successful encryption, BlueSky Ransomware renames the encrypted files with the file extension .bluesky and drops a ransom note file named # DECRYPT FILES BLUESKY #.txt and # DECRYPT FILES BLUESKY #.html.
As shown in Figure 1, BlueSky ransomware is initially dropped by the PowerShell script start.ps1, which is hosted at hxxps://kmsauto[.]us/someone/start.ps1. The initial dropper is Base64-encoded and then DEFLATE-compressed, which is common behavior observed among PowerShell droppers.
Figure 1. Initial dropper.
After extracting the embedded Base64-encoded stream from start.ps1, the decoded and uncompressed data stream led to yet another PowerShell script called stage.ps1. This script contained countless irrelevant comments in an attempt to conceal malicious activity. After removing these excessive comments, we discovered that start.ps1 downloaded a number of payloads from hxxps://kmsauto[.]us/someone/ based on the user’s privileges, as shown in Figure 2.
Figure 2. Initial dropper (decoded).
Local Privilege Escalation
Before downloading additional payloads to perform local privilege escalation, the PowerShell script, stage.ps1, determines if it is being executed as a privileged user. If so, it moves to the next step and downloads and executes the ransomware payload. If not, it uses the following techniques to escalate local privileges, depending on the version of the host operating system. If the version of the host operating system is earlier than Windows 10, such as Windows 7, 8 or XP, then the script will download and execute a modified version of the local privilege escalation tool called JuicyPotato. If the host is running Windows 10 or later, then the script will download and execute ghost.exe and spooler.exe to exploit local privilege escalation vulnerabilities CVE-2020-0796 and CVE-2021-1732 respectively.
Ransomware Payload
After gaining additional privileges, stage.ps1 downloads the final BlueSky ransomware payload from hxxps://kmsauto[.]us/someone/l.exe and saves it locally to the filesystem as javaw.exe, attempting to masquerade as a legitimate Windows application. Eventually, the sample executes from the file path %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\javaw.exe.
Ransom Note
BlueSky drops the ransom note as a text file named # DECRYPT FILES BLUESKY #.txt and an HTML file named # DECRYPT FILES BLUESKY #.html in a local directory where it has encrypted files successfully and renamed them with the file extension .bluesky. The content of # DECRYPT FILES BLUESKY #.html is shown in Figure 3.
Figure 3. BlueSky ransom note.
Anti-Analysis Techniques
BlueSky implements multiple anti-analysis techniques, including string encryption, API obfuscation and anti-debugging mechanisms, allowing it to obfuscate Windows API function names and use indirect calls for resolving APIs. Additionally, BlueSky encodes API names using DJB hashing functions as shown in Figure 4, hindering malware analysis.
Figure 4. DJB hash matching.
Ransomware Artifacts
BlueSky generates a unique user ID by computing the MD5 hash over the combined Volume Information, Machine GUID, Product ID and Install Date values, as shown in Figure 5. Furthermore, it uses the same ID for generating the mutex Global\<32-byte ID>.
Figure 5. Unique ID calculation.
It creates the registry key HKCU\Software\<32-byte ID> to store registry entries completed, RECOVERY BLOB and x25519_public to fingerprint its ransomware operations. Once the encryption process is completed, the registry entry completed is set with a value of 1. RECOVERY BLOB is a fingerprint identifier for the compromised organization, which is encrypted by the ChaCha20 encryption algorithm. The structure of the RECOVERY BLOB is shown in Table 1.
Offset
Data
Size
0x00
Curve25519 public key
0x20
0x20
Cryptographic random value
0x0C
0x2C
Curve25519 secret key
0x20
0x4C
Unique user ID
0x10
0x5C
Hardcoded RC4-decoded bytes
0x10
0x6C
Unknown DWORD
0x04
0x70
Unknown DWORD
0x04
0x74
Constant value 0x1000
0x04
Table 1. Recovery blob structure.
The RECOVERY BLOB is then encrypted with ChaCha20 as shown in Figure 6 and stored in HKCU\Software\<32-byte ID>\RECOVERY.
Figure 6. Recovery blob encryption.
File Encryption
Unlike other ransomware, which normally contains a list of file extensions to identify eligible files for encryption, BlueSky consists of a list of extensions that are negated in the file encryption process. The file extensions used in BlueSky are listed below: ldf, scr, icl, 386, cmd, ani, adv, theme, msi, rtp, diagcfg, msstyles, bin, hlp, shs, drv, wpx, bat, rom, msc, lnk, cab, spl, ps1, msu, ics, key, msp, com, sys, diagpkg, nls, diagcab, ico, lock, ocx, mpa, cur, cpl, mod, hta, exe, ini, icns, prf, dll, bluesky, nomedia, idx
Directory names excluded from encryption: $recycle.bin, $windows.~bt, $windows.~ws, boot, windows, windows.old, system volume information, perflogs, programdata, program files, program files (x86), all users, appdata, tor browser
As shown in Figure 7, BlueSky uses a multithreaded queue for encryption. It starts multiple threads – one responsible for file encryption, another for enumerating files on the local file system and mounted network shares to be added into the queue. This multithreaded architecture bears code similarities with Conti (Ransomware) v3. In particular, the network search module is an exact replica of Conti v3. However, there are certain differences in the file encryption routine. For instance, Conti v3 uses RSA- and AES-based file encryption, whereas BlueSky utilizes Curve25519- and ChaCha20-based file encryption.
Figure 7. Ransomware queues.
The file encryption of BlueSky is similar to Babuk Ransomware – both use Curve25519 to generate a public key for the host and generate a shared key with the public key of the attacker. After generating an elliptic curve key pair, BlueSky computes a hash of the shared key, and uses it to generate a file encryption key for the ChaCha20 algorithm. Finally, it reads the file buffer, encrypts it with ChaCha20 and replaces the contents of the original file, as shown in Figure 8.
Figure 8. File encryption routine.
RedLine Infostealer Association
All samples we observed related to BlueSky ransomware were hosted at an active domain named kmsauto[.]us. When hunting for more samples related to BlueSky ransomware, we observed that several malware samples associated with the RedLine infostealer were hosted on the same domain. Although we did not find any code overlap between RedLine and BlueSky ransomware, similarities in the initial stages were observed, as both these families use a PowerShell downloader as the initial vector.
Conclusion
Ransomware authors are adopting modern advanced techniques such as encoding and encrypting malicious samples, or using multi-staged ransomware delivery and loading, to evade security defenses. BlueSky ransomware is capable of encrypting files on victim hosts at rapid speeds with multithreaded computation. In addition, the ransomware adopts obfuscation techniques, such as API hashing, to slow down the reverse engineering process for the analyst.
It is very likely that ransomware attacks will continue to grow with advanced encryption techniques and delivery mechanisms.
![Traffic from gateway domains such as jxc786[.]com will reach this gambling website, but if a visitor opens the subdomain directly, they are redirected to a search engine for cloaking.](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/10/word-image-20.png)
![The older version of OriginLogger reaches out to 74.118.138[.]76 for authentication as shown in the pcap](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/09/word-image-35.png)
![RDP login screen for 23.106.223[.]46 shows a Windows Server 2012 R2 server with multiple accounts - administrator, ftpuser and postgres](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/09/word-image-36.png)
![A minimalist but legitimate-appearing website at hxxp://www.asianexportglass[.]shop](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/09/word-image-39.png)
![PowerShell command. The command shown begins with [Reflection.Assembly]](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/09/word-image-42.png)
![URLScan.io results for the agusanplantation[.]com domain includes an observation of the OriginLogger web panel.](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/09/word-image-51.png)
![CVE-2015-2051 exploit payload, showing the connection to host 159.203.15[.]179, from which a MooBot downloader can be accessed.](https://unit42.paloaltonetworks.com/wp-content/uploads/2023/09/word-image-20.png)
![CVE-2018-6530 exploit payload, showing the connection to host 159.203.15[.]179, from which a MooBot downloader can be accessed.](https://unit42.paloaltonetworks.com/wp-content/uploads/2023/09/word-image-21.png)
![CVE-2022-26258 exploit payload, showing the connection to host 159.203.15[.]179, from which a MooBot downloader can be accessed.](https://unit42.paloaltonetworks.com/wp-content/uploads/2023/09/word-image-22.png)
![CVE-2022-28958 exploit payload, showing the connection to host 159.203.15[.]179, from which a MooBot downloader can be accessed.](https://unit42.paloaltonetworks.com/wp-content/uploads/2023/09/word-image-23.png)
![Text of BlueSky ransom note: "BlueSky: Your important files, documents, photos, videos, databases have been encrypted! The only way to decrypt and restore your files is with our private key and program. Any attempts to restore your files manually will damage your files. To restore your files follow these instructions: 1. Download and install Tor Browser. 2. Run Tor Browser. 3. In the Tor Browser open website [threat actor URL] 4. On the website enter your recovery ID [redacted] 5. Follow the instructions on the website.](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/08/word-image-9.jpeg)
Get updates from Unit 42 