Unit 42 researchers recently found that Stately Taurus abused the popular Visual Studio Code software in espionage operations targeting government entities in Southeast Asia. Stately Taurus is a Chinese advanced persistent threat (APT) group that carries out cyberespionage attacks.
This threat actor used Visual Studio Code’s embedded reverse shell feature to gain a foothold in target networks. This is a relatively new technique that a security researcher discovered in 2023. According to our telemetry, this is the first time a threat actor used it in the wild.
We assess that this campaign is a direct continuation of a previously reported campaign that we attributed with moderate-high confidence to Stately Taurus. We come to this conclusion based on consideration of the TTPs, timeline and victimology targeting government entities in Southeast Asia.
We will also discuss a connection between the Stately Taurus activity and a second cluster of activity occurring simultaneously in the same targeted environment that leveraged the ShadowPad backdoor.
Palo Alto Networks customers receive better protection against threats discussed in this article through the following products and services, which we detail further in the Conclusion section:
One of the novel techniques Stately Taurus used to bypass security protections leverages Visual Studio Code’s embedded reverse shell feature to execute arbitrary code and deliver additional payloads. Truvis Thornton described this technique in a Medium post in September 2023, but this is the first time we’ve observed threat actors abusing this technique in the wild.
To abuse Visual Studio Code for malicious purposes, an attacker can use the portable version of code.exe (the executable file for Visual Studio Code), or an already installed version of the software. By running the command code.exe tunnel, an attacker receives a link that requires them to log into GitHub with their own account.
After logging in, the attacker is redirected to a Visual Studio Code web environment that is connected to the compromised machine. They are then permitted to execute commands and scripts, and to create new files on the infected machine.
Stately Taurus used this technique to deliver malware to infected environments, perform reconnaissance and exfiltrate sensitive data. To establish constant access to the reverse shell, the attacker created persistence for a script named startcode.bat using a scheduled task that is responsible for starting the shell.
Figure 1 shows the process tree for code.exe abuse in Cortex XDR.
Figure 1. Process tree of the code.exe abuse in Cortex XDR.
The Connection to Stately Taurus
In September 2023, we discussed a campaign that was attributed to Stately Taurus, which leveraged the ToneShell backdoor as one of its main tools. During this campaign, Stately Taurus used ToneShell to archive files for exfiltration, protecting the RAR archives with a unique password.
The password was 13 characters long, using upper and lower case letters as well as digits. By tracking this unique password in our telemetry, we were able to find additional Stately Taurus activity in the same targeted environment.
We concluded that this campaign is a continuation of the Stately Taurus activity we reported in this campaign due to the following factors:
The use of the same unique password
Additional TTPs
Timeline
Victimology targeting governmental entities in Southeast Asia
Figure 2 presents the connections between the components of Stately Taurus.
Figure 2. Connections between different components of the campaign and the unique Stately Taurus password.
Stately Taurus (aka Mustang Panda, BRONZE PRESIDENT, RedDelta, Luminous Moth, Earth Preta and Camaro Dragon) has been operating since at least 2012. Stately Taurus is a Chinese APT group that routinely conducts cyberespionage campaigns targeting government entities, as well as religious and other nongovernmental organizations across Europe and Asia.
Additional TTPs Related to the Stately Taurus Cluster
Sshd.exe: The attacker used OpenSSH (sshd.exe) to execute commands, transfer files and spread across the environment as shown in Figure 3. OpenSSH allows the user to connect to a remote machine via SSH.
Figure 3. Sshd.exe used for lateral movement shown in Cortex XDR.
SharpNBTScan: The attackers used SharpNBTScan (renamed as win1.exe) to perform scanning in the environment
Listeners.bat: On some occasions the attackers used a batch file named Listeners.bat to archive files for exfiltration
Exfiltration
As part of this operation, Stately Taurus attempted to exfiltrate sensitive information from different machines. The attacker executed rar.exe remotely via SMB. Next, they tried to iterate and archive all drives from A-Z on remote machines, as shown in Figure 4.
Figure 4. Attacker uses code.exe to archive folders from remote machines shown in Cortex XDR.
To exfiltrate the archived files, the attacker used curl to upload the files to Dropbox, which is a legitimate file hosting service. The attacker used this service to blend in and exfiltrate the data without drawing too much attention.
Stately Taurus used the same technique previously, as described in our previous article. Figure 5 below shows the command line the attacker used for exfiltration.
Figure 5. Data exfiltration using Dropbox.
The Connection to a ShadowPad Activity
While investigating the Stately Taurus cluster, we observed another cluster of activity in the same environment, occurring simultaneously and at times even on the same endpoints. This cluster of activity used the ShadowPad backdoor as its main tool, from which attackers launched other activity. ShadowPad is modular malware that has been in use by multiple Chinese threat actors since at least 2017.
The connection between these two clusters includes the following overlap:
Following the origins of Listeners.bat (used in the Stately Taurus cluster) on an infected machine, we observed that the same network session that wrote Listeners.bat, wrote additional files and malware including the ShadowPad backdoor.
Listeners.bat also used the same unique password that the ToneShell backdoor from the Stately Taurus cluster used. Figure 6 depicts this connection.
Figure 6. The observed connection between Listener.bat of Stately Taurus and ShadowPad.
As of mid-August 2024, it is unclear whether these two clusters originated from the same threat actor. The fact that the two files originated from the same network session might indicate a connection between the ShadowPad activity to the VSCode activity linked to Stately Taurus.
There could also be other possible scenarios to explain this connection. For example, it could be a joint effort between two Chinese APT groups or perhaps two different groups piggybacking on each other’s access.
In the cluster described in this section, the attacker abused the legitimate process imecmnt.exe via DLL sideloading to load the ShadowPad module (imjp14k.dll). Imecmnt.exe is a Microsoft Office Input Method Editor (IME) component.
To keep ShadowPad running on victim machines, the attacker created persistence via a service. These service names are listed in the Indicators of Compromise section below.
Figure 7 shows how ShadowPad (imecmnt.exe renamed as update.exe to appear less suspicious) spawns and injects code into wmplayer.exe, which in turn spawns and injects code into dllhost.exe.
Figure 7. ShadowPad infection in Cortex XDR.
Further TTPs related to the ShadowPad activity can be found in the Appendix section of the blog.
Conclusion
In this follow-up post, we shared new TTPs the Stately Taurus APT group used in an espionage campaign that targeted government entities in Southeast Asia. One of the most noteworthy techniques that we observed in this campaign is the abuse of Visual Studio Code for executing malicious code and gaining a foothold in the infected environment. According to our telemetry, this is the first time attackers have used this technique in the wild.
In addition, we examined a connection we encountered between the Stately Taurus activity cluster and another cluster that used the ShadowPad backdoor in the same environment. As of mid-August 2024, the connection between these two clusters remains uncertain.
Based on the forensic evidence and timeline, one could conclude that these two clusters originated from the same threat actor (Stately Taurus). However, there could be other possible explanations that can account for this connection, such as a collaborative effort between two Chinese APT threat actors.
We encourage organizations to leverage our findings to inform the deployment of protective measures to defend against this threat group.
Protections and Mitigations
For Palo Alto Networks customers, our products and services provide the following coverage associated with this group:
Advanced WildFire cloud-delivered malware analysis service accurately identifies the known samples as malicious.
Prevent the execution of known malicious malware and prevent the execution of unknown malware using Behavioral Threat Protection as well as machine learning based on the Local Analysis module.
Protect against credential gathering tools and techniques using the new Credential Gathering Protection available from Cortex XDR 3.4.
Protect from threat actors dropping and executing commands from web shells using Anti-Webshell Protection, newly released in Cortex XDR 3.4.
Protect against exploitation of different vulnerabilities including ProxyShell and ProxyLogon using the Anti-Exploitation modules as well as Behavioral Threat Protection.
Detect post-exploit activity, including credential-based attacks, with behavioral analytics, through Cortex XDR Pro.
Prisma Cloud Compute and Advanced WildFire integration can help detect and prevent malicious execution of the malware within Windows-based VM, container and serverless cloud infrastructure.
If you think you might have been impacted 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)
The threat actor used the following tools to perform reconnaissance in victim environments:
Tscan: The attacker used a variation of the open-source tool fscan, which they named Tscan. Tscan’s capabilities include scanning, password spraying and command execution.
Figure 8 shows the Tscan banner and help menu, and Figure 9 shows Tscan (ts.exe) being detected for performing a port scan.
Figure 8. Tscan banner and help menu snippet.Figure 9. Tscan detected for performing a port scan in Cortex XDR.
ADExplorer64.exe: The attacker attempted to use the utility AD Explorer on the victim’s Active Directory. This tool allows its user to easily query an Active Directory database.
Credential Theft
The attacker attempted to use different methods to dump credentials. The following is a list of each method:
In-Swor: The attacker attempted to use an open-source tool named In-Swor to execute Mimikatz, as shown in Figure 10. In-Swor appears to have a Chinese-speaking author and it is described as a penetration tool meant to bypass antivirus products.
According to the tool’s GitHub page, the current modules that are available for the tool include: mimikatz, frpc, bypassuac, elevation, killAV and fscan.
Figure 10. In-Swor (wk.exe) prevented attempting to load Mimikatz in Cortex XDR.
Mimikatz: The attacker attempted to dump credentials from memory using the known credential-harvesting tool MimiKatz (named setup1.exe)
LaZagne: The threat actor attempted to use the LaZagne tool to access passwords in infected systems. LaZagne is an open-source tool used to recover stored passwords from systems.
Lsass-dump-main: To retrieve passwords, the threat actor attempted to use what appeared to be a custom tool to dump the memory of the lsass.exe process to disk. Figure 11 shows the output of this tool.
Figure 11. Output from the Lsass-dump-main tool.
Stealing the NTDS.dit File: To steal Active Directory data, the attacker attempted to steal NTDS.dit as shown in Figure 12. NTDS.dit is an Active Directory database that stores information about user objects, groups, group membership and (most importantly) password hashes.
Figure 12. Alert for dump of NTDS.dit in Cortex XDR.
To steal the NTDS.dit file, the threat actor used Vssadmin to create a volume shadow copy on the Domain Controller, which allowed the attacker to access the NTDS.dit file. Next, the attacker dumped the SYSTEM hive from the registry, which contains the boot key that is required to decrypt the NTDS.dit file.
PSEXESVC.exe: The attacker used the popular PsExec utility for lateral movement across the victim’s environment. PsExec allows the execution of processes on remote systems.
Windows Management Instrumentation (WMI): The threat actor used WMI to execute remote processes in the environment. WMI allows the execution of processes on local and remote systems.
The Unit 42 Managed Threat Hunting team (MTH) identified a variant of WikiLoader loader for rent (aka WailingCrab) being delivered via SEO poisoning and spoofing our GlobalProtect VPN software. Analysis conducted by the Advanced WildFire reverse engineering team has uncovered the latest evasion techniques for WikiLoader, providing new insights into its evolution.
We provide multiple XQL queries for Cortex to hunt for this WikiLoader campaign. We also provide hashes that identify samples found in the wild as well as command and control (C2) URLs extracted from the original sample that spoofed GlobalProtect.
Palo Alto Networks customers are better protected from the threats discussed in this article through detection mechanisms available from the following products:
Additionally, Google has confirmed that all sites mentioned in this article are known to Safe Browsing. Any user that visits these sites will receive a warning of potential security risks.
Overview of Tradecraft Used by WikiLoader in Campaigns Spoofing GlobalProtect
WikiLoader is a multistage malware loader that adversaries developed with consideration toward evasion. Our industry partners have documented this threat well. As such, we’ll focus on the specific tradecraft we observed related to campaigns spoofing GlobalProtect, anti-analysis techniques employed by the loader and resources for threat hunters.
Proofpoint has reported WikiLoader has been active since at least late 2022. They also noted that phishing was initially the primary means of delivery. Its operators used compromised WordPress sites and public MQ Telemetry Transport (MQTT) brokers for C2.
In June 2024, we observed a WikiLoader campaign leveraging GlobalProtect themed SEO poisoning, rather than using previously documented phishing tactics. SEO poisoning is the process of getting an attacker-controlled site on the front page of search engine results for a legitimate product through purchasing advertisements or improving page rank.
Attackers commonly use SEO poisoning as an initial access vector to trick people into visiting a page that spoofs the legitimate search result to deliver malware rather than the searched-for product. This campaign’s delivery infrastructure leveraged cloned websites relabeled as GlobalProtect along with cloud-based Git repositories.
Unit 42 primarily observed WikiLoader affecting the U.S. higher education and transportation sectors. However, the use of SEO poisoning for delivery almost certainly broadens the scope of possible victims as compared to phishing.
WikiLoader is a loader for rent, which is suspected to be leveraged by at least two initial access brokers (IABs). Attribution for this specific campaign requires further research. However, we do make the following observations.
Campaigns leveraging WikiLoader and spoofing GlobalProtect have shown reasonable regard for evasion
The threat operators show an awareness of simple techniques that, when executed well, make machine and signature-based detection of such threats difficult
Such OPSEC considerations include:
Using the MQTT internet of things (IoT) event queue protocol for C2
Typosquatting and spoofing download pages modified to deliver WikiLoader throughout the life of a campaign
Using legitimate sites running vulnerable, third-party WordPress plugins as C2 infrastructure
Using cloud-hosted Git solutions to host malicious content
Using legitimate, signed binaries for sideloading WikiLoader
Using common file names associated with security tooling, where allowlistings in security products would reduce detection and response efficacy
Embedding payloads in seemingly benign file names and types
Hiding attributes for all files except the file that receives user interaction
Encrypting shellcode that is stored in separate binaries from the WikiLoader executables
Decrypting keys for shellcode that operators stored in the C2 servers
Performing multiple anti-analysis checks
Displaying fake error messages on execution
Figure 1 provides a summary of the infection chain.
The following section details the execution of WikiLoader as delivered through GlobalProtect-based SEO poisoning.
The advertisements we observed linked to multiple fake sites serving spoofed GlobalProtect installers. Figure 2 shows a malicious advertisement that attackers used to lure victims to a spoofed GlobalProtect download page.
Figure 2. Google ad linked to the websites to download spoofed GlobalProtect.
The first site is a clone of a legitimate business that fetches the malicious payload upon download shown in Figure 3. Bitbucket took the site offline when we notified them of it.
Figure 3. A cloned website that directs users to download the spoofed GlobalProtect installer hosted on Bitbucket.
The second site shown in Figure 4 is a site that spoofs the GlobalProtect client download page.
Figure 4. A cloned GlobalProtect page that directs users to download spoofed GlobalProtect installers.
Upon download, Cortex XDR shows the following information associated with Chrome where the sample is enriched with Mark of the Web (MotW) data as shown in Figure 5. MotW is a security feature in Windows that adds metadata to files downloaded from the internet to indicate a potentially unsafe source. Analysts can use this information to assist in understanding the source of a file, and where someone may have been browsing before downloading the file.
Figure 5. File write and read of the GlobalProtect64.zip file enriched with MotW data streams indicating one of the download URLs in the File Origin text area.
Figure 6 shows how the sample appears to the victim. The sample only shows a single file in the folder.
Figure 6. The contents of GlobalProtect64.zip following extraction as viewed by a user.
Figure 7 shows that when viewing all the hidden files and folders, there are more than 400 files.
Figure 7. The contents of GlobalProtect64.zip following extraction, showing hidden items.
Figure 8 shows what we see when viewing all files in the archive and checking the signer. GlobalProtect64.exe is a renamed copy of a legitimate share trading application that attackers used to sideload the first WikiLoader component.
Figure 8. A screenshot of Cortex XDR showing a copy of the trading platform renamed as GlobalProtect64.exe being abused to sideload the first WikiLoader loader component (i4jinst.dll) upon execution.
Figure 9 shows that upon execution of GlobalProtect64.exe, the threat loads the first WikiLoader component i4jinst.dll, located inside the directory .install4j.
Figure 9. A screenshot of Cortex XDR events associated with spoofed GlobalProtect64.exe.
The i4jinst.dll Load Image event causes the malicious module to be loaded into the binary spoofing GlobalProtect64.exe. Once loaded, i4jinst.dll reads the first stage encrypted shellcode from certificate.pem. It then decrypts the shellcode and injects it into explorer.exe.
This includes the following discrete actions:
The decrypted certificate.pem contains the first stage shellcode that is executed
The shellcode loads C:\Windows\System32\BingMaps.dll
The function GetBingMapsFactory is then overwritten with another shellcode decrypted from certificate.pem
The overwritten shellcode then carries out thread injection into the explorer.exe process
At this point in the infection chain, Cortex’s shellcode prevention raised alerts as shown in Figure 10.
Figure 10. Cortex shellcode protection prevents the injection from the malicious process into explorer.exe.
If unprevented, the injected code in explorer.exe will contact a compromised site running WordPress CMS as a C2 server for the WikiLoader backdoor. It will then establish persistence and communicate with MQTT brokers for tasking.
The injected code will load license_us_EN.html. In the GlobalProtect spoofing campaign, license_us_EN.html is a renamed copy of the AdInsight.exe Microsoft Sysinternals binary. License_us_EN.html will side load the WikiLoader backdoor downloaded from the C2 server.
Upon establishing persistence, AdInsight.exe (renamed to license_us_EN.html) will be renamed again to a random filename. This file will be written into a randomly named folder in ProgramData along with a randomly named file with the extension .pem and the WikiLoader backdoor as a .dll. This process is shown in Figure 11.
Figure 11. Files contained in a randomly named directory when WikiLoader writes persistence components to disk.
In testing environments where shellcode protection was disabled, Cortex XDR still generated an analytic behavioral indicator of compromise (BIOC) detection for the unusual creation of a scheduled task created by explorer.exe following the shellcode injection.
In summary, the infection chain is as follows:
Malicious behaviors begin when the victim launches GlobalProtect64.exe and this file then loads i4jinst.dll (located inside .install4j)
Once loaded, i4jinst.dll will read and decrypt the contents of the file certificate.pem
The decrypted certificate.pem contains the first stage shellcode that the threat executes
The shellcode loads C:\Windows\System32\BingMaps.dll
The function GetBingMapsFactory is then overwritten with another shellcode decrypted from certificate.pem
The overwritten shellcode then carries out thread injection into the explorer.exe process
The injected code in the explorer.exe process will contact the C2 server for the WikiLoader backdoor
If persisting, the threat will write license_us_EN.html and another file with extension .pem to a randomly named folder in ProgramData along with the WikiLoader backdoor as a .dll
The threat will establish persistence via a scheduled task to execute the renamed license_us_EN.html
The injected code will read and execute a hidden PE file from license_us_EN.html
License_us_EN.html will side load the WikiLoader backdoor downloaded from the C2 server
The backdoor will decrypt the shellcode encrypted in the randomly named file with extension .pem. The decryption key is the name of the folder where the backdoor is located.
We have added additional protections to Cortex, and we share a collection of hunting rules written in XQL at the end of this post.
Highlighting WikiLoader Anti-Analysis and Defense Evasion
The following are some unique tricks that this sample of WikiLoader used.
Fake Error Message
As the spoofed GlobalProtect installer is not an actual installer, the authors of WikiLoader needed another trick to fool victims. The threat shows a fake error message when it completes infection of the victim machine. This prevents the victim from wondering why GlobalProtect is not installed.
Figure 12 shows the fake error message generated by the sample.
Figure 12. Fake error message displayed when the sample completes infection
Renamed Legitimate Software Used for Side-Loading Backdoor
Attackers renamed the Microsoft Sysinternals tool ADInsight.exe to license_us_EN.html, and hid it inside the spoofed GlobalProtect installer. ADInsight.exe is used to side load the WikiLoader backdoor. Figure 13 shows the contents of license_us_EN.html.
Figure 13. Hex dump of license_us_EN.html showing it is a PE file.
Checks for Analysis Environments
The sample checks the running processes in the victim machine against a list of hashes of software commonly used by malware analysts. As most malware analysts would be using a virtualized environment to analyze malware samples, the WikiLoader sample will terminate if it finds processes related to virtual machine software.
To hide the list of processes that WikiLoader is looking for, the malware uses a 32-bit hashing routine similar to those used by Emotet back in 2021. Figure 14 shows the hashing routine used by this WikiLoader sample.
Figure 14. Hashing routine used to obfuscate the analysis processes from above.
Folder Name as Decryption Key for the Backdoor
The backdoor is encrypted using the CryptUnprotectData API. This sample of WikiLoader used the folder name (RamDQ) as the decryption key for its backdoor.
Figure 15 shows the folder named RamDQ, which contained the encrypted backdoor 1FoWZv.pem and the executables (s2VT3.exe and version.dll) required to decrypt and execute the backdoor.
Figure 15. Screenshot showing CryptUnprotectData being passed the folder name, ultimately to be used to decrypt the shellcode in 1FoWZv.pem.
Conclusion
Financially motivated threat actors will continue to use WikiLoader as a loader for rent in a variety of campaigns where they require a robust, stealthy Windows loader that pays reasonable attention to OPSEC.
What remains to be seen is why threat actors have shifted from phishing to SEO poisoning to deliver WikiLoader. One hypothesis is that another initial access broker (IAB) has begun to work with WikiLoader to operationalize its delivery through SEO poisoning in recent months. Alternatively, groups that are publicly tracked using WikiLoader could have shifted to SEO poisoning from phishing after an improvement in endpoint security controls or industry reporting disrupted their operations.
While SEO poisoning is not a new technique, it continues to be an effective way to deliver a loader to an endpoint. Spoofing trusted security software is likely to assist in bypassing endpoint controls at organizations that rely on filename based allow listing.
The combination of spoofed, compromised and legitimate infrastructure leveraged by WikiLoader campaigns reinforces the malware authors attention to building an operationally secure and robust loader, with multiple C2 configurations. The authors suspect that we will likely see continued WikiLoader use throughout 2024 and beyond.
Regardless of the anti-analysis and EDR evasion techniques employed by WikiLoader, the procedures employed can be identified using many common endpoint threat hunting methods. We share a selection of four queries in our appendix that organizations can use to hunt for WikiLoader with high fidelity in endpoint data. The queries can be expanded in scope with minimal changes from XQL users to cast a wider net, or narrow in on threats that may be more applicable to an organization’s environment.
Google has confirmed that all sites mentioned in this article are known to Safe Browsing. Any user that visits these sites will receive a warning of potential security risks.
Palo Alto Networks Protection and Mitigation
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
Cortex XDR customers are better protected against the sideloads and shellcode injection attempts mentioned in the article. Cortex XDR detects and prevents these malware activities based on Behavioral Threat Protection, AI-driven local analysis, analytics profiles and other security engines across Windows, Linux and Mac systems.
Prisma Cloud can detect known WikiLoader binaries executed from within cloud environments through the Cloud Security Agent (CSA).
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
Japan: +81.50.1790.0200
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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.
XQL Hunting Queries
Explorer.exe communicating with MQTT brokers
1
2
3
4
5
6
7
8
9
10
11
// Description: Communication to known MQTT broker services from explorer.exe. Observed samples have communicated with MQTT brokers over over plaintext or encrypted TCP ports, not using websockets. Typically these are TCP 1883,8883,8884
// Collate the file writes by the actor (writing) process
|comp count_distinct(action_file_path)ascnt_pe_written,count_distinct(action_file_extension)ascnt_pe_extensions,count_distinct(action_file_signature_status)ascnt_pe_sig_status,values(action_file_path)aspe_written,values(action_file_signature_status)asaction_file_signature_status,values(action_file_signature_vendor)asaction_file_signature_vendor,values(action_file_signature_product)asaction_file_signature_product,values(actor_effective_username)asusername,values(action_file_sha256)asaction_file_sha256,values(_time)astime,values(actor_process_command_line)ascommand_line,values(action_file_name)aspe_written_name,values(agent_hostname)asagent_hostname by actor_process_instance_id
// Filter out those that have only written 1 Exe and 1 DLL, with a DLL using a known abused name
We investigated 19 new top-level domains (TLDs) released in the past year, which revealed large-scale phishing campaigns, distribution of potentially unwanted programs, torrenting websites, and even pranking and meme campaigns.
We saw correlation between the new TLDs' general availability dates and their popularity, showing that different groups follow the launch of new TLDs and their lifecycle. They do so to initiate domain registration and usage, including for abuse.
There are currently over 1,000 generic top-level domains (TLDs) according to the Internet Assigned Numbers Authority (IANA) root database, and more new TLDs are being added every year. As new TLDs emerge, the potential for malicious activity such as domain squatting and phishing increases tremendously. This is especially problematic when these TLDs resemble the extensions of popular file extensions such as .zip, and distinctive service identifiers such as .bot.
The IANA root database currently lists over 1,000 generic top-level domains (TLDs), with new additions continually being made each year. New TLDs under the Generic TLD (gTLD) category are added for myriad reasons including promoting new markets, allowing brands to diversify their web presence, and increasing consumer and business choices.
In the past year and a half, 19 new TLDs have been announced. As more new TLDs are released, companies and other entities may have a hard time keeping up and defensively registering their names on all of them. This presents a possibility for attackers to exploit these TLDs, especially those that resemble file extensions, repurposing them for malicious activities.
TLD Rollout Phases
To understand the potential negative effects of these new TLDs and domain registrations, we first need to understand how new TLDs are rolled out.
All domains under a TLD are tracked in an authoritative database called a registry. A registry operator is the organization that maintains this authoritative database of all domain names for a particular TLD.
After new TLDs are delegated and approved for future release, the registry operator associated with the new TLD takes responsibility for the different launch and registration phases. A typical set of launch phases will include the following:
Note that while these phases are typically associated with generic TLDs, only the sunrise period and general availability are mandatory.
Sunrise Period
This is a mandatory phase for all registries. In this phase, registrations are open only to holders of a validated trademark record in the Trademark Clearinghouse (TMCH). This is an effort to help entities secure domain names under new TLDs that fall under their trademark to protect them from cybersquatting and domain squatting attacks according to ICANN Wiki. If more than one entity proves claims to a certain domain, an auction is conducted.
There are two types of sunrise periods:
End date sunrise (minimum 60-day length)
The less common Start date sunrise (30-day notice before the start of sunrise period and 30-day minimum length)
Landrush
The landrush phase allows registry operators to make registrations open to the public for specific, premium domain names at a higher cost than their price during general availability. Multiple parties applying for the same domain may lead to an auction.
Early Access Period/Program
Certain TLDs also have an early access period that lasts about a week. Some registry operators may not differentiate between the landrush and early access periods (EAP), and others may offer EAP-like pricing during the first week of general availability.
During the EAP, registrants have the opportunity to register a domain name at a premium price before the TLD's official launch during the general availability period on a first-come, first-served basis. The registry operator may set a premium price that is determined based on the number of days starting from the beginning of this period. The first day of early access has the highest registration price and the last day has the lowest, but both are still higher than the general availability period price.
General Availability
Finally, the TLD is officially launched and moves to a general availability phase where domains under this TLD are available to the public for registration. As mentioned before, some registry operators may offer EAP-like pricing during the first weeks of general availability where domains can be registered for a premium price that slowly drops throughout this period. Typically, a trademark claims phase is in effect in the first 90 days of the general availability period where trademark holders could be alerted when someone registers a domain name matching their trademark.
Data Sources
We track the release of new TLDs through the official ICANN website, which reports the sunrise dates for all generic TLDs.
In particular, we are focusing on 19 TLDs that have been released or are in the process of reaching general availability:
.bot
.box
.case
.channel
.dad
.esq
.foo
.ing
.lifestyle
.living
.meme
.mov
.music
.nexus
.phd
.prof
.vana
.watches
.zip
In April 2024, we gathered data about domains under these TLDs from a variety of sources: passive DNS, zone file data published by registry operators, historical newly registered domains (NRDs) and historical domain squatting detections in these TLDs. Finally, we augment this list by taking the top 1 million most popular domains on the internet using the Tranco list—a research-oriented top site ranking. We replace their TLD with each of the 19 new TLDs in an effort to cover all potential cases of abuse of the most popular domain names.
Traffic Toward Domains in These New TLDs
From our customer data logs, Table 1 shows the most-popular new TLDs with the number of unique registered (root) domains.
TLD
Number of Registered Domains
.zip
5,470
.ing
5,071
.bot
4,179
.mov
1,279
.meme
1,175
Table 1. Most popular TLDs from our customer data logs.
We sampled our traffic logs two times a month and added some important dates from the TLD launch schedule as displayed below in Figure 1. This data indicates that the rise in popularity of the top 10 TLDs correlates with the date that a TLD enters the general availability phase.
The .zip TLD entered general availability on May 10, 2023. From the data on May 16, 2023, we see the first spike in the popularity of the .zip domains.
The .ing TLD entered general availability on Dec. 5, 2023. On that same day we saw a large spike in traffic toward .ing domains that has continued since then.
Similarly, Amazon initially allowed registration of .bot domains to customers exclusively for bot-related services. After the .bot TLD entered general availability on Oct. 30, 2023, our data reveals notable increases in .bot domain registrations starting on Nov. 1.
Figure 1. Popularity of the top 10 new TLDs at different points over the past year from our logs.
The evident correlation between these new TLDs' availability and the number of domain registrations indicates that various groups or individuals closely follow the launch of new TLDs to register new domains. These groups could include adversaries that plan to abuse domains belonging to these newly available TLDs. Therefore, tracking and conducting security checks for domains under emerging TLDs is crucial.
Introducing Our Graph-Based Detection System
Our graph-based detection system is enabled by a powerful internal graph database that ingests comprehensive cybersecurity data from various data sources including the following:
Leveraging these data sources, we developed a graph-based automated detection system depicted in Figure 2. Starting with a seed list of domains, the system extracts all related data, including associated URLs, IPs and malware samples.
The system generates an independent graph visualization for each seed domain that depicts the relevant relationships with these other associated entities. In this case, the seed list was a list of all domains under these 19 TLDs that we obtained by analyzing information from our previously mentioned data sources.
Figure 2. Graph-based detection system design.
After constructing the graph relations, we conduct a multi-stage pruning and graph clustering process. In this process, our system’s pruning algorithm significantly reduces noise and redundancies, only retaining the salient graph paths.
For instance, if a domain uses a globally popular nameserver, then hundreds or thousands of other domains will also use the same nameserver. This results in extra noise added to the graph due to that nameserver node. To address this problem, we prune all paths that are connected to a list of known, benign and popular nodes.
Next, we put these pruned graphs through a clustering process that hunts for commonalities. Our system can cluster domain graphs together based on specific features such as the following:
Related IP addresses
Authoritative name servers
Their WHOIS information
Domain name lexical patterns
Traffic and redirection patterns
TLS certificate information
Shared or common web infrastructure and content
This process helps us correlate campaigns that share the following traits:
The same infrastructure
The same traffic distribution systems
Downloading and disseminating the same malware samples
Abusing a common set of intermediary services to broaden their attacks
Results: Case Studies
In this section, we present select network abuse campaigns captured by our graph-based detection system. The results include the following:
Large-scale phishing attacks
Distribution of potentially unwanted programs
Torrenting websites
Pranking or meme campaigns
Redirection Campaign
Bad actors can leverage trending TLDs and domain names to propagate phishing and redirection attacks. In one such case study, we found that 112 domains belonging to these new TLDs form a tightly related cluster that can be associated with a phishing campaign.
Below, Figure 3 shows the clustered graph for this campaign. The nodes near the middle highlighted in yellow are domains under the newly released TLDs. The red nodes are known malicious indicators that our detectors have already blocked for other suspicious activity or content.
Each blue node represents a relationship between two entities, such as URLs, hostnames, IP addresses and files. Figure 3 reflects four distinct types of relationships in the graph:
NS records for the domain
A records for the domain
Redirect to a URL
URLs sharing a “path of” relationship with their root domain
At the time of our data collection, all 112 domains redirected to different URL paths under the choto[.]xyz domain.
Figure 3. Redirection campaign with 112 domains from 11 different newly released TLDs.
Although active as recently as April 2024, by May 2024, this traffic coordination domain choto[.]xyz was inactive and returned an NXDOMAIN DNS error. Checking our archived scans and web archive data, we find that these paths had redirected users to a gambling website.
We found these 112 domains subsequently redirected to URL paths under choto[.]click/vx/<string> that redirected to gambling websites. Figure 4 shows an example of one of the gambling pages.
Figure 4. Example of a gambling page from this campaign.
All 112 domains share the same four nameservers that are denoted by the nodes on the far right in Figure 3. These nameservers are hosted on the same set of IP addresses, indicating a shared infrastructure.
All 112 domains were also registered with the same registrar, with most registered from June-November 2023. We are the first to detect and block over 78% of these 112 domains according to data from open threat intelligence platforms.
Data from this campaign indicates the group behind it has expanded beyond leveraging newly released TLDs. Our analysis also reveals targeted keywords surrounding recent events. For example, we found at least four new domains relating to the 2024 Summer Olympics are connected to this same campaign.
Chat Bot Service Campaign
Another cluster involved luring victims into scanning a QR code that redirects them to begin texting over SMS. The SMS session can potentially expose the victim to scams, spam, data harvesting campaigns and exposure of personal information.
Shown in Figure 5, this campaign contains 92 different domains belonging to the .bot TLD. The domains in this cluster have distinct naming patterns. They are either:
A person’s first name (such as Akira, Emilia, Mei, Percy or Valentina)
The name of a city (such as Amsterdam, Leipzig or Toronto)
Random German words (such as Fluege, Kleinanzeigen, Termin or Welt)
Random English words (such as Broadband, Chicken or LastMinute)
Figure 5. Homogeneous .bot cluster relating to a chat service campaign with 92 domains.
All of these .bot domains redirected victims to a URL under a different domain ending with the same root name string suffixed by .php.
For example, the domain harriet[.]bot redirected to the URL at phpstack-1171166-4096956.cloudwaysapps[.]com/harriet.php
Figure 6 illustrates how the picture/avatar displayed and the QR code changes in relation to the domain name queried.
Figure 6. Two different landing pages under the same domain for URLs ending in harriet[.]php and chicken[.]php.Similar to the previous campaign, all 92 domains share three nameservers hosted on the same IP address. All 92 domains were registered with the same registrar. Notably, all 92 domains were all registered within a two-week period between Nov. 11, 2023, and Dec. 3, 2023, all within five weeks of the .bot domain entering general availability.
Torrenting Unblockit Cluster
Investigating homogeneous clusters, we found a campaign distributing pirating and torrenting links that contain four domains using the same root name with four different TLDs:
.esq
.zip
.ing
.foo.
URLs under these domains all have similar paths as well.
Our graph-based analysis reveals that the infrastructure of these torrenting services keeps evolving as its domains are blocked by security vendors. Figure 7 indicates URL paths that redirect users to the same path under a different TLD, possibly as a mirroring phenomenon.
Figure 7. The unblockit torrenting campaign that highlights the evolving infrastructure.
Following this pattern, we found websites with the root name unblockit under different TLDs. We found 11 additional domains that all redirected to the same unblockit torrenting webpage.
Similar to the above cluster, we found another campaign that uses the root name worldfree4u with different TLDs, which is a torrent and piracy distribution website. Figure 8 shows that we observed the same domain name under five different TLDs:
.foo
.meme
.mov
.zip
.dad
Figure 8 reflects a serial chain of redirections of URLs from one domain under one TLD to another.
Figure 8. Charting the worldfree4u campaign distributing piracy and torrent links.
Examining Previously Reported Malicious TLDs and Domains
Of all the newly released TLDs, .zip and .mov are two TLDs that are among the 10 most popular that also resemble popular file extensions. When Google released these two TLDs for general availability in May 2023, many sources commented on the dangers of these TLDs and how attackers were already leveraging them to perpetuate phishing attacks. Consequently, many of these domains were blocked by security vendors, and new domains under these TLDs began to be scrutinized more carefully.
Malware, Critiques and Pranks
We analyzed previously reported malicious .zip domains and found they have either become NXDOMAINs, parked pages or result in network traffic errors. Some of these previously malicious domains redirect to pages critiquing the TLD, like latestupdate[.]zip and googlechrome[.]zip. Figure 9 illustrates an example of the critique sites.
Figure 9. Example of a previously malicious domain hosting criticism about the .zip TLD.
Websites from domains using the .zip TLD can automatically offer ZIP archives for download. These ZIP archives can contain anything, depending on who established the web server.
Some domains previously reported as malicious now contain prank content. For instance, assignment[.]zip downloads a ZIP archive that contains a picture of a leek and one music track (mp3 file), while photos[.]zip simply contains the text: “haha you got phished!”
At least two servers using .zip TLD domains previously reported as malicious currently distribute content flagged as malware. The first is eicar-test-file[.]zip that appears to send a randomly named ZIP archive containing an EICAR test file.
The second is bomb[.]zip, a site that critiques ICANN's decision to approve the .zip TLD. It states "We heard you like zip bombs!" and sends a zip bomb.
From our studies, we see that many .zip and .mov domains are being used for pranks and memes such as rickrolling.
Leveraging TLDs That Look Like File Extensions for Trolling
We also observe that domains, specifically ones that appear to be file extensions, are increasingly used for trolling online. Specifically for rickrolling, we observed 13 domains in this cluster under the TLDs .zip and .mov redirected users to a bit[.]ly link that led to a YouTube music video of a 1987 song titled “Never Gonna Give You Up” by musician Rick Astley.
These 13 domains resemble file names such as attachedpdf[.]zip and testvideo[.]mov. All of them point to the same set of nameservers denoted by the node on the left in Figure 10. They also have the same four IP addresses in their A record, indicated on the right in Figure 10.
Figure 10. Cluster that points to a link-shortener link that redirects users to get rickrolled.
Conclusion
We investigated domains registered under 19 newly released TLDs from the past year. To sustainably track the evolution of these domains over time, we introduced our graph-based investigation pipeline that can help identify coordinated attack and misuse campaigns.
This article presented detailed case studies on a variety of cyberthreats to show how domains registered on these newly released TLDs have been used for redirection, chatbot campaigns and torrent distribution. As new TLDs emerge, the potential for malicious activity such as domain squatting and phishing increases. This investigation reveals the importance of monitoring domains registered under new TLDs to discover and track new trends and attack campaigns.
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
Japan: +81.50.1790.0200
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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.
Indicators of Compromise
The following are domains and URL paths related to this article.
Our researchers discovered dozens of scam campaigns using deepfake videos featuring the likeness of various public figures, including CEOs, news anchors and top government officials. These campaigns appear in English, Spanish, French, Italian, Turkish, Czech and Russian. Each campaign typically targets potential victims in a single country, including Canada, Mexico, France, Italy, Turkey, Czechia, Singapore, Kazakhstan and Uzbekistan.
Due to their infrastructural and tactical similarities, we believe that many of these campaigns likely stem from a single threat actor group. We have observed this threat actor group using deepfake videos to spread fake investment schemes and fake government-sponsored giveaways.
As of June 2024, we had discovered hundreds of domains being used to promote these campaigns. Each domain has been accessed an average of 114,000 times globally since going live, based on our passive DNS (pDNS) telemetry.
Starting with a campaign promoting an investment scheme called Quantum AI, we studied the infrastructure behind this campaign to track its spread over time. Through this infrastructure investigation, we discovered several additional deepfake campaigns leveraging completely different themes that the same threat actor group created and promoted. These additional scam campaigns used different languages and the likeness of different public figures, suggesting that each campaign is intended for a different target audience.
Despite the use of generative AI (GenAI) in these campaigns, traditional investigative techniques remain useful to identify the hosting infrastructure leveraged by these threat actors. As the malicious usage of deepfake technology increases among threat actors, so should defenders’ efforts to proactively detect and prevent these types of attacks.
Customers of Palo Alto Networks are better protected from these attacks via Advanced URL Filtering, which will continue to detect and block websites that are used to propagate deepfake-based scam campaigns.
To study the Quantum AI campaign, we decided to analyze the infrastructure behind the websites hosting these attacks. Starting with an initial seed set of detections from our deepfake video detection pipeline, we then looked for additional websites serving up known malicious videos. We observed several Quantum AI-related videos that adversaries were widely sharing via websites hosted on newly registered domains.
Upon further investigation, we identified that the videos themselves were primarily hosted on a single domain:
Belmar-marketing[.]online
Next, we searched for other web pages that served video files from this domain and also contained keywords like Quantum AI in the HTML content.
Through this process, we were able to uncover dozens of other scam pages using these videos as a lure. We then used the content on these web pages as well as the pathnames of the video files to create signatures to expand our detections. (See the Indicators of Compromise section for example URLs.)
In May 2024, we noticed that an increasing number of Quantum AI videos were being hosted on other domains as well, including the following:
Ai-usmcollective[.]click
Fortunatenews[.]com
Fiirststreeeet[.]top
We also discovered some sites built using website builders that were promoting the same Quantum AI scam. In these cases, the attackers re-hosted the video directly on the site via the website builder, not on one of the shared video-hosting domains mentioned above.
Quantum AI Example Videos and Web Pages
In Figures 1-7, we present examples of Quantum AI scam web pages and videos discovered by our video analysis pipeline and infrastructure-based investigation. In most of these examples, the scam web page was hosted on a newly registered domain, and the video was hosted as an .mp4 file on one of the shared video-hosting domains mentioned above (e.g., belmar-marketing[.]online).
In most cases, the attackers appear to have started with a legitimate video and added on their own AI-generated audio. Finally, they used lip-syncing technology to modify the lip movement of the speaker to match the AI-generated audio. Most of the videos use Elon Musk as their celebrity of choice, although we discovered a handful of examples using other public figures as well:
Tucker Carlson
Lee Hsien Loong, the former Prime Minister of Singapore
Tharman Shanmugaratnam, the President of Singapore (as of June 2024)
Figure 1. Huerwlleiss-herton[.]pro, a website using an Elon Musk deepfake video to promote the Quantum AI scam.Figure 2. Bitquantumai[.]com, a website using a deepfake video of Elon Musk and Tucker Carlson to promote the Quantum AI scam.Figure 3. Quantumal[.]xyz, a website used to promote the Quantum AI scam. The web page asks for a referral code to log in.
Figure 4. Screenshot of an Elon Musk deepfake video used to promote the Quantum AI scam. In the video, deepfake-Elon claims that Quantum AI is the “world’s first quantum computing software developed by his team with a success rate of 91%.”Figure 5. Another screenshot of a different Elon Musk deepfake video used to promote the Quantum AI scam.Figure 6. Griffinware-tm.cloud, a website using a deepfake video of Lee Hsien Loong, the former Prime Minister of Singapore, to promote the Quantum AI scam.Figure 7. A screenshot of a deepfake video of Tharman Shanmugaratnam, the current President of Singapore, used to promote the Quantum AI scam.
Deepfake Campaign Discovery and Tracking
After investigating the Quantum AI scam campaign, we explored broader trends surrounding these deepfake campaigns as a whole.
Uncovering Additional Deepfake Scams
In addition to the Quantum AI scam, we also investigated the other videos that were present on these video-hosting domains. In doing so, we were able to uncover several other scam campaigns (likely propagated by the same threat actor group), many of which use deepfake videos as a lure. These deepfake videos typically use the likeness of public figures like CEOs, news anchors or top government officials.
We discovered deepfake videos in several different languages, including English, Spanish, French, Italian, Turkish, Czech and Russian. Each campaign typically targets potential victims in a single country, including Canada, Mexico, France, Italy, Turkey, Czechia, Singapore, Kazakhstan and Uzbekistan.
Similar to the Quantum AI scam campaign, these videos add AI-generated audio on top of an existing video and use lip-syncing tools to alter the lip movement of the speaker to match the new audio. Visitors to these web pages are prompted to register with their name and phone number, and they are instructed to await a call from an account manager or representative.
In many of these cases, we discovered several newly registered domains hosting the same content (and the same deepfake video lure). This means that each of these scam web pages is part of a larger campaign, not just a one-off scam web page.
For example, in the case of the KazMunayGas scam shown below in Figure 8, we found scammers using the same video across several recently registered domains, including:
Figure 8. Coinframework[.]top, a scam website using an AI-manipulated video of a Kazakh news anchor to promote a fake giveaway started by KazMunayGas, the state-owned oil and gas company of Kazakhstan.Figure 9. Riseanalyze[.]click, a website linked to from coinframework[.]top. This website contains a registration form for the KazMunayGas-themed scam.Although the languages and impersonation-targets of these scam campaigns are different, they share the following similarities:
They all use similar deepfake techniques
They have similar calls to action
They host their videos on a small, shared set of domains (that do not seem to be used for any other purpose than to host these scam videos)
This suggests that these campaigns can most likely be attributed to a single threat actor group.
We present some selected examples of these additional scam campaigns in Figures 10-15.
Figure 10. Invest-toolavenue[.]shop, a scam website using an AI-manipulated video of Patrick Pouyanné (TotalEnergies CEO) to promote a fake giveaway supposedly created by TotalEnergies, a French multinational energy and petroleum company.Figure 11. Invest-toolavenue[.]shop, continued from Figure 10.
Figure 12. Capitalflow-skillful.shop, a scam website using an AI-manipulated video of Andrés Manuel López, the President of Mexico, to promote a fake “Mexican Investment Society Project.”Figure 13. Untamedal.top, a scam website using an AI-manipulated video of Giorgia Meloni, the Prime Minister of Italy, to promote a fake state-sponsored investment program called FinInvest.
Figure 14. Hugeproject[.]shop, a World Bank-themed scam website using an AI-manipulated video of a woman claiming to represent an international investment bank.Figure 15. Hugeproject[.]shop, continued from Figure 14.
Campaign Activity Over Time
While these campaigns started about a year ago, we observed a large spike of newly observed domains (shown in Figure 16) in February 2024. Unlike typical phishing or malware domains, these domains are relatively long-lived, with an average active time of 142 days.
Figure 16. The number of newly observed domains hosting deepfake videos over time.
Figure 17 shows that the number of active domains exponentially increased until about March 2024, and the total number of active domains has remained steady to the present day.
Figure 17. The number of active domains hosting deepfake videos over time.
Furthermore, it is concerning to note that these domains have a high reach, with each domain being accessed an average of 114,000 times since they first went live, based on pDNS telemetry. The actual number is likely much higher.
Hosting Infrastructure Analysis
Going with the current trend of camouflaging in shared hosting infrastructure, 86.7% of these campaign domains are using the same popular content delivery network (CDN). Multiple IP addresses from the CDN host the same content across different geographic locations, with the U.S., the Netherlands and Russia being the top 3 locations. The utilization of CDNs makes it difficult to attribute the campaign to a particular threat actor or geolocation.
We observed that the attackers primarily hosted their videos on a small set of attacker-owned domains. Attackers presumably did this to circumvent takedown issues that could occur on more popular video-hosting platforms.
Until April 2024, we observed that the deepfake videos were predominantly hosted on belmar-marketing[.]online. However, starting in May 2024, the attackers began to rotate their video hosting locations more frequently. As such, we observed that videos were now mainly hosted on fiirststreeeet[.]top, ai-usmcollective[.]click and fortunatenews[.]com.
Looking for web pages that link to videos hosted on these domains has been very valuable for tracking the spread of these campaigns so far. We will continue to monitor for new video-hosting domains as these campaigns progress.
How the Quantum AI Scam Works
During our research, we observed posts and ads promoting Quantum AI on various social media platforms (shown in Figures 18-20). According to the Australian National Anti-Scam Center, scammers often first use these sorts of social media ads or fake news articles to link to scam web pages that ask for the victim user’s contact information.
Figure 18. Social media post linking to a Quantum AI scam web page.Figure 19. Messaging platform post linking to a Quantum AI scam web page.Figure 20. Social media post using a video to promote the Quantum AI scam.
After visiting the scam landing page and filling out a form to sign up for the platform, one of the scammers gives the victim a phone call. In this call, the scammer tells the victim they’ll need to pay around $250 to access the platform.
The scammer instructs the victim to download a special app so that they can “invest” more of their funds. Within the app, a dashboard appears to show small profits. From there, the scammers continue persuading the victim to deposit more of their money and may even allow the victim to withdraw a small amount of money as a way to gain trust.
Finally, when the victim tries to withdraw their funds, the scammers either demand withdrawal fees, or cite some other reason (e.g., tax issues) for not being able to get their funds back. The scammers may then lock the victim out of their account and pocket the remaining funds, causing the victim to have lost the majority of the money that they put into the “platform.”
Overview of the Web-Based Deepfake Scam Landscape
Quantum AI is not the only scam that adversaries are using involving deepfakes. In this section we’ll discuss other techniques and services that they have been using.
In early 2024, a company lost $25 million to attackers who used deepfake technology to impersonate their chief financial officer on a video conferencing call. While video conferencing deepfakes have received significant attention as a result of this attack, web-based deepfake scams are an emerging threat that researchers should monitor as well.
2024 is predicted to be the largest voting year in history. Over 60 countries are holding significant elections this year, meaning that around half the world's population could be directly affected by these events. In response, researchers have raised concerns about the potential for deepfakes to promote political misinformation. However, the impact of deepfakes is not limited to the political domain. Cybercriminals have already been creating and sharing deepfake videos for their own malicious purposes.
Deepfakes Used to Promote Scams and Phishing Attacks
Since the advent of GenAI, attackers have used deepfakes to promote political misinformation, and even to further voter outreach. For example, in early 2024, a Democratic political consultant used an audio deepfake of Joe Biden to discourage voters in the state of New Hampshire from voting in the upcoming primary election.
Now, we are seeing cybercriminals start to use deepfake media to promote their own scams and phishing attacks as well. In recent months, reporters have observed scams impersonating figures like Elon Musk (shown in Figure 21), Bill Gates and Warren Buffett to peddle fake cryptocurrencies, giveaways and other investment schemes. These are created with the ultimate goal of stealing funds from victims. (Our previoustweets on this topic have more details.)
Figure 21. Screenshot of an Elon Musk deepfake video seen on patriotsmaga2024[.]com, a website promoting the sale of fake “Trump Liberty Coins.”Previously, these attackers might have used paid actors to promote their scams (e.g., by creating videos purporting to be a client who profited from a fake investment scheme). With the increasing popularity and effectiveness of tools that use AI to generate content (e.g., images, audio and video), attackers are now able to create these videos in a cheaper and more convincing way.
Deepfakes as a Service
Our researchers have encountered cybercriminals selling, discussing and trading deepfake tooling and creation services across forums, social media chat channels and instant messaging platforms. These tools and services offer capabilities for generating deceptive and malicious content including audio, video and imagery. The ecosystem surrounding deepfake creation and tooling is alive and vibrant, and cybercriminals are selling a variety of options from face swapping tools to deepfake videos.
Face swapping tools like Swapface (shown in Figure 22) range in price from free to over $249 a month. Adversaries abuse these tools, placing the videos they create on diverse platforms and social media platforms. Swapface offers user-friendly filters and face swapping that operates in real time, allowing users to alter or replace faces in videos.
Figure 22. Swapface tooling subscription cost.
The criminal application of deepfake tooling and creation services and tools includes the following activities:
Facilitating the creation of fake identities
Committing bank fraud
Orchestrating disinformation campaigns
Bypassing know-your-customer verification checks
Performing cryptocurrency theft
These services can manipulate visuals and audio with alarming precision, leading to significant ethical and security concerns. The cost of generating a deepfake video can vary widely, typically ranging from $60 to $500, reflecting the complexity and quality of the requested forgery.
As seen in Figure 23, we also discovered messaging platform channels specifically advertising the creation of deepfake videos for scam purposes.
Figure 23. Messaging platform channel dedicated to deepfake generation services.
The accessibility and range of costs make deepfakes particularly versatile tools for maliciousness, posing challenges for both individuals and institutions trying to safeguard against fraud and misinformation.
Conclusion
Despite the use of GenAI in these campaigns, traditional investigative techniques remain useful to identify the hosting infrastructure leveraged by these threat actors. As threat actors increase their use of deepfake technology, organizations should also proactively defend against these types of attacks.
Palo Alto Networks researchers will continue to monitor these deepfake-based scam campaigns and continue to discover and investigate additional deepfake-based scam campaigns. As such, we can ensure that our customers are better protected from them via Advanced URL Filtering.
Indicators of Compromise
Deepfake Scam Examples
Figure 24. Screenshot of a scam video containing a deepfake of Kevin O’Leary.
Example 1
Web page URL: xtradgpt[.]online
Video URL: hxxps://quontic[.]site/wp-content/uploads/2024/07/449030935_482215324194392_281914555774571171_n[.]mp4
Language: English
Country targeted: Canada
Deepfake of: Kevin O'Leary (Canadian businessman)
Summary: Promoting an AI trading bot that allows Canadian citizens to earn at least $27,000 Canadian dollars per month
Figure 25. Screenshot of a scam video containing a deepfake of Tharman Shanmugaratnam (Prime Minister of Singapore).
Example 2
Web page URL: euphemiouslystner[.]life
Video URL: hxxps://hemicdn[.]com/1501-1400-3505[.]mp4
Language: English
Country targeted: Singapore
Deepfake of: Tharman Shanmugaratnam (Prime Minister of Singapore)
Summary: Promoting a fake investment scheme named Quantum AI
Figure 26. Screenshot of a scam video containing a deepfake video of Patrick Pouyanné (CEO of TotalEnergies).
Example 3
Web page URL: invest-toolavenue[.]shop
Video URL: hxxps://ai-usmcollective[.]click/videos/TotalEnergies_news_FR[.]mp4
Language: French
Country targeted: France
Deepfake of: Patrick Pouyanné (CEO of TotalEnergies)
Summary: Promoting a fake investment platform sponsored by TotalEnergies, and guaranteed by the Bank of France
Figure 27. Screenshot of a scam web page containing a deepfake video of Andrés Manuel López Obrador (President of Mexico).
Example 4
Web page URL: capitalflow-skillful[.]shop
Video URL: hxxps://ai-usmcollective[.]click/videos/MexicanPartnership_man_MX[.]mp4
Language: Spanish
Country targeted: Mexico
Deepfake of: Andrés Manuel López Obrador (President of Mexico)
Summary: Promoting a fake “Mexican Investment Society Project”
Figure 28. Screenshot of a scam video containing a deepfake of Giorgia Meloni (Prime Minister of Italy).
Example 5
Web page URL: untamedal[.]top
Video URL: hxxps://ai-usmcollective[.]click/videos/FinInvest_woman-performing_IT[.]mp4
Language: Italian
Country targeted: Italy
Deepfake of: Giorgia Meloni (Prime Minister of Italy)
Summary: Promoting a fake state-sponsored investment program called FinInvest
Figure 29. Screenshot of a scam video containing a deepfake of Andrej Babis (Czech politician and businessman).
Example 6
Web page URL: hxxps://hybridpowerit[.]com/
Video URL: hxxps://ai-usmcollective[.]click/videos/ImmediateMatrix-PNewsQZ-Invest[.]mp4
Language: Czech
Country targeted: Czechia
Deepfake of: Andrej Babis (Czech politician and businessman)
Summary: Promoting a fake investment platform for Czech citizens
Figure 30. Screenshot of a scam video containing a deepfake of Omer Koc (Turkish businessman).
Example 7
Web page URL: rondeliercore[.]com
Video URL: hxxps://hemicdn[.]com/video_5848484848485[.]mp4
Language: Turkish
Country targeted: Turkey
Deepfake of: Omer Koc (Turkish businessman)
Summary: Introducing an AI-powered trading bot that allows users to earn a stable income of 10,000 Turkish liras
Figure 31. Screenshot of a scam web page containing a deepfake video of Alisher Usmanov (Uzbek and Russian businessman).
Example 8
Web page URL: hxxps://naatuureeffocus[.]com/
Video URL: hxxps://ai-usmcollective[.]click/videos/USM_novosti-usmanov_UZ[.]mp4
Language: Russian
Country targeted: Uzbekistan
Deepfake of: Alisher Usmanov (Uzbek and Russian businessman)
Summary: Presenting a new investment platform for citizens of Uzbekistan
Update on Sept. 19, 2024
Figure 32. Screenshot of a scam video containing a deepfake of Donald Trump.
Example 9
Web page URL: mtgaeth[.]vip
Video URL: hxxp://mtgaeth[.]vip/video/videos-2[.]mp4
Language: English
Country targeted: United States
Deepfake of: Donald Trump (45th President of the United States)
Summary: Selling fake "American Monetary Fund" (AMF) checks, which Americans can cash out for $10K after the 2024 US presidential election
Figure 33. Screenshot of a scam video containing a deepfake of Matthew Amroliwala (BBC Newscaster).
Example 10
Web page URL: bitvidex360[.]trade
Video URL: hxxps://bitvidex360[.]trade/wp-content/uploads/2023/08/Bitvidex360-Trade[.]mp4
Language: English
Country targeted: United Kingdom
Deepfake of: Matthew Amroliwala (BBC Newscaster)
Summary: Announcing a fake investment project from Elon Musk that allows British residents to earn an income of 5,700 pounds per day
Figure 34. Screenshot of a phishing web page containing a deepfake video of Luiz Inácio Lula da Silva (President of Brazil).
Example 11
Web page URL: consultar-resgate[.]com/ll/etapa2
Video URL: hxxp://consultar-resgate[.]com/videos/vsl[.]mp4
Language: Portuguese
Country targeted: Brazil
Deepfake of: Luiz Inácio Lula da Silva (President of Brazil)
Summary: Announcing a government program called Indeniza Brasil that will provide compensation to Brazilian citizens whose personal data was leaked due to a government database system failure
Figure 35. Screenshot of a scam video containing a deepfake of Emomali Rahmon (President of Tajikistan).
Example 12
Web page URL: crisiswatch[.]online
Video URL: hxxps://ai-usmcollective[.]click/videos/GP_prez-tajikistan_RU[.]mp4
Language: Russian
Country targeted: Tajikistan
Deepfake of: Emomali Rahmon (President of Tajikistan)
Summary: Announcing a fake government-sponsored giveaway through a partnership with Gazprom
Update on Oct. 23, 2024
Figure 36. Screenshot of a scam web page containing a deepfake video of Jagmeet Singh (Canadian politician).
Web page URL: weixinchannelsmall[.]com
Video URL: hxxps://d2l7oiuw3gwvbg[.]cloudfront[.]net/video/JagmeetSingh_923_jag[.]mp4
Language: English
Country targeted: Canada
Deepfake of: Jagmeet Singh (Canadian politician, leader of the New Democratic Party)
Summary: Announcing a fake government-sponsored investment program through a partnership with Imperial Oil
Figure 37. Screenshot of a scam video containing a deepfake of Christine Lagarde (President of the European Central Bank).
Web page URL: kotrotshmot[.]site
Video URL: hxxp://kotrotshmot[.]site/video/1735[.]mp4
Language: English
Region targeted: EU
Deepfake of: Christine Lagarde (President of the European Central Bank)
Summary: Introducing a fake investment project launched by the European Central Bank and Eurosystem
Figure 38. Screenshot of a fake news website imitating Tagesschau (German TV news program) and using a deepfake of Theodor Weimer (former CEO of Deutsche Börse).
Web page URL: new-company[.]store
Video URL: hxxps://new-company[.]store/video/1512_3[.]mp4
Language: German
Country targeted: Germany
Deepfake of: Theodor Weimer (German businessman, former CEO of Deutsche Börse)
Summary: Promoting a limited-time offer to trial a fake stock trading algorithm created by major banking corporations
Figure 39. Screenshot of a scam web page containing a deepfake video of Maia Sandu (President of Moldova).
Web page URL: currrencyspot[.]buzz
Video URL: hxxps://ai-usmcollective[.]click/videos/Maib_prezident_RU[.]mp4
Language: Russian
Country targeted: Moldova
Deepfake of: Maia Sandu (President of Moldova)
Summary: Promoting a fake investment project called “Maib”, which claims to provide Moldovan citizens with up to 30,000 lei per month
In an incident response engagement handled by Unit 42, the threat actor group Bling Libra (the group behind the ShinyHunters ransomware) showcased their new shift to extorting victims rather than their traditional tactic of selling/publishing stolen data. This engagement also displayed how the group acquires legitimate credentials, sourced from public repositories, to gain initial access to an organization’s Amazon Web Services (AWS) environment.
While the permissions associated with the compromised credentials limited the impact of the breach, Bling Libra infiltrated the organization’s AWS environment and conducted reconnaissance operations. The threat actor group used tools such as the Amazon Simple Storage Service (S3) Browser and WinSCP to gather information on S3 bucket configurations, access S3 objects and delete data.
Threat actors commonly use S3 Browser and WinSCP during their attacks. To expand incident responders’ understanding of how these tools generate events in the logs, this research differentiates activity initiated by the threat actors versus activity automatically generated by each tool.
As businesses increasingly embrace cloud technologies, the threat posed by groups like Bling Libra underscores the importance of robust cybersecurity practices. By implementing proactive security measures and monitoring critical log sources, organizations can effectively safeguard their cloud assets and mitigate the impact of cyberthreats.
AWS log sources and services such as Amazon GuardDuty, AWS Config and AWS Security Hub play a crucial role in enhancing the security posture of organizations. When using AWS Organizations, using AWS Service Control Policies and permission boundaries add additional protection. These tools provide valuable insights and alerts to security analysts, enabling them to monitor and respond to security incidents effectively.
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
Cortex XDR for cloud can offer a comprehensive incident story by integrating activity from cloud hosts, cloud traffic and audit logs together with endpoint and network data.
Palo Alto Networks customers can also take advantage of Prisma Cloud to monitor posture and maintain compliance across public clouds.
Palo Alto Networks Cloud Security Agent (CSA) uses XSIAM to provide detection and monitoring capabilities to cloud infrastructure through both Prisma Cloud and Cortex cloud agents.
If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.
Bling Libra Background: The Threat Actors Behind ShinyHunters
Unless a threat actor leaves specific indicators behind, researchers have a difficult time performing attribution for cloud attacks. However, the threat actor group Bling Libra does not hold back in making sure their attacks explicitly link back to them.
Bling Libra first emerged in 2020 and has been linked to significant data breaches, such as the Microsoft GitHub and the Tokopedia attacks in 2020 as reported by Wired. While Bling Libra’s targets span various industries and geographic regions, their modus operandi remains consistent.
This group typically acquires legitimate credentials before targeting database infrastructure to gather personally identifiable information (PII) for resale on underground marketplaces. In 2024, the group shifted from trying to sell data they’ve collected to extorting their victims, and targeting cloud environments.
Introduction to MITRE ATT&CK® Framework
This article uses the MITRE ATT&CK framework to categorize the different tactics present within the attack. The matrix comprises 14 unique tactics (Enterprise version 15) and categorizes various common characteristics seen by threat actors. For more information on the tactics present in this article, each header contains a link to each specific tactic and their corresponding techniques. Figure 1 represents the first step in the attack.
Figure 1. Initial access begins with stealing AWS access keys.
Initial Access (TA0001)
To gain initial access into the organization's AWS environment, the threat actors obtained AWS credentials from a sensitive file exposed on the internet. The file contained a variety of credentials, but the group specifically targeted the exposed AWS access key belonging to an identity and access management (IAM) user and a handful of other exposed credentials.
These cloud credentials allowed the threat actors to gain access to the AWS account where this IAM user resided and perform AWS application program interface (API) calls. The permissions associated with these credentials only allowed the attackers to successfully interact with S3 with the AmazonS3FullAccess policy. This AWS-managed policy grants unlimited permissions to S3 resources within an AWS account depending on what other organizational policies the AWS account might employ.
Unit 42 commonly investigates matters where overly permissive cloud credentials deployed by organizations lead to further exploitation of an environment. This Bling Libra attack exemplifies the results of not following the principle of least privilege.
Discovery (TA0007)
Once Bling Libra gained access to the organization’s AWS environment, they performed a variety of API calls to determine the extent of the permissions the compromised credentials contained. To determine what API calls the threat actors made, Unit 42 used CloudTrail logs to track the group’s activities in the environment. CloudTrail logs all the management events that occur within an AWS account. Figure 2 captures the various discovery attempts.
Figure 2. Discovery begins the attacker’s process of learning more about the environment.
Against the IAM service, the threat actor performed ListUsers, which returns a list of the existing users within the AWS account. Due to the limited permissions associated with the access key, the API call failed.
To learn more about the S3 buckets that existed within the AWS account, the group performed the ListBuckets API call using the AWS Command Line Interface (CLI). The AWS CLI provides people the ability to interact with an AWS account through the command line, and it provides the building blocks for automation.
From there, the threat actors switched to using the S3 Browser tool to iterate through the S3 buckets in the account and that generated both GetBucketLocation and GetBucketObjectLockConfiguration events in the CloudTrail logs. The S3 Browser tools provide a graphical user interface (GUI) to interact with the S3 buckets within an AWS account.
The S3 Browser analysis section discusses in more depth which API calls the tool automatically generates to help incident responders differentiate between tool automation and threat actor activity.
Data Access and Impact (TA0010 and TA0040)
Following the discovery operations, the threat actor waited almost a month before returning and taking disruptive actions within the organization’s AWS account. Due to both CloudTrail S3 data logging and S3 server access logging not being enabled within the organization's AWS environment, no logs existed that showed exfiltration activity from the S3 buckets. Figure 3 illustrates the next two stages of the attack.
Figure 3. Data access and impact of the attacker's actions.
After waiting that extended period of time, the threat actor group used WinSCP to graphically view all the S3 buckets in the account. After selecting the Amazon S3 file protocol and entering the access key ID and secret access key, the tool automatically generates the ListBuckets API call to populate the list of buckets in the GUI. Due to the lack of object level logging, no other API calls appeared in the CloudTrail logs until the threat actor deleted a handful of buckets, which resulted in the DeleteBucket API call.
As described below, WinSCP provides various methods to interact with the S3 storage objects in an AWS account. The ransom note later sent by the threat actor provided proof of data access, but it did not provide enough specifics to determine what S3 data left the environment.
Execution (TA0002)
Following the deletion of all the S3 buckets, the threat actor used an automated script with the AWS CLI and attempted to create new S3 buckets. These buckets had various name variations of contact-shinycorp-tutanota-com-# with the # replaced with ascending numbers. Figure 4 shows the final step – execution of the script.
Figure 4. The attacker creates new S3 buckets.
All the buckets were created within ten minutes of starting the CreateBucket operations. We see no motive behind creating these S3 buckets other than to mock the organization about the attack. Figure 5 shows the full MITRE timeline based on key events detailed above.
Figure 5. The MITRE timeline details the attack path taken by the threat actor.
Extortion
After Bling Libra performed all the aforementioned actions (i.e., data access via API key, discovery, deletion and creation of buckets), they completed their attack by sending an extortion email to the victim organization. The note stated the group had shifted to extortion to make more money and that the victim organization had one week to pay, as seen in Figure 6.
Figure 6. Extortion email.
S3 Browser and WinSCP Analysis
In many Unit 42 investigations involving cloud compromises, S3 Browser and WinSCP appear in the logs as threat actors use them for nefarious activity. Unit 42 performed tests to determine which activity in the AWS CloudTrail logs came from specific actions taken in the tools’ GUIs versus automation API calls performed by the tools themselves.
The following tests used S3 Browser version 11.6.7 and WinSCP version 5.21.7.0.
S3 Browser
Unit 42 performed tests to understand which API calls automatically happen in the background by the tool, and which API calls get logged because of specific actions performed by a user in the GUI. The API calls can be tracked via the user agent field in the CloudTrail logs, which would contain a value of S3 Browser/<Version> (https://s3browser[.]com).
The test activities we discuss here took place against a bucket we created with data events logging enabled in CloudTrail, to compare the visibility in management versus data events. Data events provide visibility into the resource operations performed on or within a resource (e.g., creating, downloading or deleting an object within the S3 buckets). We denote object-level logging events with an asterisk (*) in the following sections.
The first connection to the S3 storage service after entering the access key credentials resulted in the API calls listed below. As noted in Figures 7 and 8, S3 Browser automatically queries the object list, location and object lock configuration for the first S3 bucket alphabetically. If the S3 Browser application stays open when adding and removing the access key, only ListBuckets and ListDistributions appear in the CloudTrail logs (shown in Figures 9 and 10):
Figure 7. First connection to S3 service using S3 Browser.Figure 8. API calls for first connection to S3 service using S3 Browser.Figure 9. Connection using the same API keys without closing the S3 Browser.Figure 10. API calls for the connection using the same API keys without closing the S3 Browser.
When selecting and viewing the directory structure of another bucket in S3 Browser, it results in the following API calls.
ListObjects*
GetBucketLocation
GetBucketObjectLockConfiguration
When previewing an object in S3 Browser (shown in Figure 11), the previewed file gets downloaded as a temporary file locally onto the host running the S3 Browser application. The file then immediately gets deleted from disk (even if the preview window is still open with the file in the GUI). The S3 Browser stores the file in a temporary directory: C:\Users\<username>\AppData\Local\Temp\S3 Browser\<TempFileName>. The CloudTrail logs generate two data events for this action, one of them being GetObject, which appears in the logs since the object retrieval took place to populate the preview window. The HeadObject API call retrieves metadata about the object selected (e.g., its size, last modified date and metadata displayed by the application in the Properties tab).
Viewing the permissions in S3 Browser (shown in Figure 12) results in the API calls below for the access control list (ACL), OwnershipControls and PublicAccessBlock of the currently selected bucket.
Viewing the properties (shown in Figure 13) will result in multiple API calls to gather information about all the properties related to the bucket to populate all the information in the Preview window.
Figure 13. Viewing properties of a bucket in S3 Browser.
Attempting to enable and disable versioning for the bucket (shown in Figure 14) results in the API calls below, which first gather the versioning state and then set it to the required value.
PutBucketVersioning with request parameter showing the status as shown in Figure 15
Figure 14. Attempting to modify the versioning properties.Figure 15. Request Parameters of the API call when enabling the versioning for bucket.
Attempting to disable public block access for the bucket (shown in Figure 16) results in the API calls below, which first gather the public access block configuration and then attempts to remove it.
Figure 16. Attempting to modify the public access block configuration.
WinSCP
Windows Secure Copy, commonly known as WinSCP, is a popular file transfer application primarily used for transferring files between local and remote systems using various protocols such as SFTP, SCP, FTPS and FTP. While not specifically designed for Amazon S3, WinSCP can be configured to interact with S3 buckets. While WinSCP provides versatile file transfer capabilities, it does not offer dedicated features for managing Amazon S3 storage, such as advanced bucket and object management functionalities found in S3 Browser.
Unit 42 tested to understand what API calls are automatically made when performing specific actions. WinSCP API calls can be tracked via the user agent field in the CloudTrail logs: WinSCP/<version>.
These test activities took place against a bucket we created with data events logging enabled in CloudTrail to compare the visibility in management versus data events.
The first connection to the S3 storage service after entering the access key credentials (shown in Figure 17) results in the API call below to list all the buckets in the GUI:
ListBuckets
Figure 17. Connection to S3 using WinSCP.
Viewing the properties of an object will result in an API call that returns metadata about the object such as location, size, owner, ACL as shown in Figure 18.
GetObjectAcl*
Figure 18. Viewing the properties of an object in WinSCP.
Downloading, deleting and creating objects and buckets generated the API calls below.
GetObject*
DeleteObject*
PutObject*
CreateBucket
DeleteBucket
When comparing the two tools, S3 Browser generates a lot more API calls that automatically appear in the CloudTrail logs based on user interaction, compared to WinSCP. The difference in the events generated in the CloudTrail logs comes down to the purpose of the two tools. Being a cloud native tool, S3 Browser takes advantage of more AWS features that generate additional API calls versus WinSCP, which works for more file transfer types than solely S3. Figure 19 shows the entire attack broken down based on API calls to display the various results from each tool used.
Figure 19. API call-delineated attack chain.
Conclusion
As organizations increasingly migrate their critical operations to the cloud, we continuously witness a concerning trend of overly permissive credentials. Threat actors like Bling Libra have evolved their tactics to exploit misconfigurations and exposed credentials in cloud environments.
Due to limited permissions of the compromised access keys, the breach covered in this post did not have an impact past the S3 buckets. However, in the past, Unit 42 has observed threat actors abusing overly permissive credentials to create resources for malicious use or modifying the IAM users and permissions to maintain persistence within an environment.
Use IAM Access Analyzer to better identify and manage access risks by analyzing resource policies. Additionally, when using AWS Organizations, AWS Service Control Policies and permission boundaries can be used to help ensure that only permitted actions are allowed, regardless of the individual IAM policies within each account.
Figure 20 shows the complete attack path taken by the threat actor as grouped by MITRE tactics.
Figure 20. The MITRE timeline details the attack path taken by the threat actor.
Ensuring appropriately configured security configurations lays the groundwork to better protect organizations against potential breaches and data compromises. In this attack, attaching an S3 bucket policy requiring MFA to perform sensitive API calls such as DeleteBucket would have provided additional layers of protection against data loss. For critical data, we recommend replicating the data into another region or account to help ensure availability and resilience against security breaches including data destruction.
Ensuring adequate protection also involves regularly auditing and updating access controls, encryption settings and network configurations to align with best practices and compliance requirements. Leveraging services like AWS Config and AWS Security Hub provides continuous monitoring and assessment of the AWS environment's security posture.
Additionally, comprehending the attack lifecycle and the tactics, techniques and procedures (TTPs) of threat actors allows defenders to build the proper understanding for safeguarding cloud environments. By understanding how adversaries operate and the stages they go through to achieve their objectives, security analysts can proactively configure and monitor the necessary log sources in AWS . This allows defenders to more effectively detect and respond to cloud threats. Additionally, integrating Amazon GuardDuty for threat detection further strengthens security postures.
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
Cortex XDR for cloud can offer a comprehensive incident story by integrating activity from cloud hosts, cloud traffic and audit logs together with endpoint and network data.
Palo Alto Networks’ customers can also take advantage of Prisma Cloud to monitor posture and maintain compliance across public clouds.
Palo Alto Networks’ Cloud Security Agent (CSA) uses XSIAM to provide improved security posture and further enable detection and runtime monitoring capabilities to critical cloud infrastructure through both Prisma Cloud and Cortex cloud agents.
If you think you might have been compromised or have an urgent matter, contact 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
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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.
To improve our detection of suspicious network activity, we leveraged a deep learning method to profile and detect malicious DNS traffic patterns. Based on these DNS profiles, we developed multiple detection modules, each designed to identify suspicious domains from different perspectives. We will explore how these DNS traffic patterns correlate with specific types of cyberattacks’ activities through various case studies.
DNS resolution traffic, as the initial stage of network communication, provides critical insights into cyberthreats behind malicious network traffic. Analyzing DNS traffic patterns and characteristics can help us detect and prevent unauthorized infiltration attempts.
For example, upon gaining access to a host within a victim's network, an attacker often deploys malware that periodically connects to its command and control (C2) servers. This results in DNS traffic patterns for these C2 domains that can be markedly different from typical benign DNS activity.
Our detector captured 170 emerging suspicious domains in May 2024. The resulting signatures blocked approximately 374,000 malicious DNS requests every day.
The malicious DNS traffic detector is deployed on the Advanced DNS Security service to provide real-time protection against various network threats. The detected malicious domains are also shared with Advanced URL Filtering.
The Palo Alto Networks Advanced DNS Security service continuously monitors real-world DNS traffic to detect and block threats within organizations’ environments. To aid in threat hunting, all DNS requests are logged and delivered to our backend detection systems. This logging grants us the ability to collect and investigate the time series data of DNS traffic for each domain and customer device in real-time.
Analyzing this time series data can help track malicious DNS activity. By comparing emerging traffic trends with known malicious patterns, we can uncover emerging attacker domain names.
However, running any comparisons on raw traffic data is complex, making the analysis computationally expensive. Furthermore, this complexity will grow exponentially as the time series data scales larger. Therefore, a major challenge in analyzing large-scale time series data is determining how to process and store the data efficiently and scalably.
To overcome these challenges, we transform our dynamic DNS traffic time series data into lower, fixed-dimensional vectors called DNS profiles with the autoencoder technique. An autoencoder is a deep learning model that is designed to compress its input into a lower-dimensional vector, then reconstruct the output from this representation. People typically use an autoencoder for dimensionality reduction and feature learning.
We constructed our autoencoder with recurrent neural networks (RNN) cells so it can take variable-dimensional inputs and output compressed, fixed-dimensional vectors that preserve the input sets’ characteristics. We use the same set of time series data as the input and ground truth to train the model and obtain the intermediate vector as our traffic profiles for each device. In this way, the profiles closely model the characteristics of the input DNS traffic time series data.
Figure 1 plots our autoencoder’s validation loss curve during the model training. The loss stabilizes at a low level after 5,000 epochs of training, indicating this is the point where the model has successfully learned the manifold of real-world DNS traffic and its representative characteristics.
Figure 1. Autoencoder training performance.
Malicious DNS Traffic Detection
After profiling a domain’s DNS traffic into a fixed-dimensional vector, we can leverage various machine learning algorithms, including classification, cluster and anomaly detection models, to discover and analyze malicious network traffic patterns.
DNS Profile Classification
To identify the DNS resolution traffic to malicious domains, we implemented a high-precision classification model trained by historical benign and malicious DNS traffic profiles. The classification model serves a real-time detection system that is able to capture and block ongoing attack traffic as soon as a domain presents suspicious DNS traffic patterns. We illustrate the details of our detection pipeline in the conclusion section.
DNS Traffic Pattern Clustering
In addition to detecting the DNS requests of malicious domains, our DNS profiles also help us move a step further to understand the characteristics of different attacking behaviors in malicious network traffic. Specifically, we apply the clustering algorithm on the malicious DNS profiles to identify different groups of malicious DNS traffic so that we can analyze various DNS patterns and hunt down attack campaigns effectively.
Figure 2 categorizes the traffic of malicious domains into three distinct clusters based on their DNS profiles. The first cluster shows a steady flow of traffic with minimal spikes. Dynamic DNS (DDNS) is one of the behaviors that will generate these high frequency DNS requests and attackers commonly abuse this technique.
Figure 2. Clusters of various DNS trends.
The IP addresses of DDNS domains are changed frequently by their name servers controlled by DDNS providers or adversaries. As a result, the time-to-live (TTL) values of DDNS records are usually short to force the clients to query for potential resolution updates frequently.
Domains in the second cluster shown in Figure 2 experience a moderate amount of traffic, typically 10-20 requests every hour. This cluster could correspond to DNS tunneling domains, which are contacted by malware periodically for data exfiltration. To extract the stolen data, the attackers usually initialize several DNS requests each time for different subdomains.
The third cluster in Figure 2 is characterized by infrequent activity. These domains are mostly inactive but exhibit periodic bursts of DNS queries on a weekly basis, which is the representative behavior of malware heartbeat communication.
Anomaly DNS Traffic Detection
As demonstrated in the previous section, our clustering process revealed several commonly seen DNS profile patterns. However, we noticed that some DNS profiles presented uncommon trend patterns that were significantly different from others.
The significant variations in these trends could indicate either intentional attacking, malicious behaviors or unintentional issues. To identify all such irregular DNS profile trend patterns, we leverage an anomaly detection algorithm that helps detect outliers.
Figure 3 illustrates the DNS requests trend for the domain run[.]sh from a specific device that presents abnormal time series data. We notice that there is an abnormally high frequency of requests to the domain. Since the trend is relatively stable over the whole 24-hour time period, we conclude that this is most likely done programmatically.
Furthermore, the domain name is also a commonly used name for a bash script program. This leads us to conclude that the DNS requests may have been produced unintentionally.
The user may attempt to run a script that has the same filename but causes a DNS lookup to the file name instead. For instance, if someone uses the browser’s address bar to search for a local file or GitHub file named run[.]sh, it may unintentionally cause a DNS lookup instead.
Figure 3. Abnormal DNS traffic trend for run[.]sh.From our data, we see that besides this device, there are thousands of DNS queries for the same domain every day globally. At the time of detection, this domain was a parked domain and it was not involved in any attack campaign. However, if an attacker takes control of the domain, they can benefit from a large amount of unintentional DNS requests.
Case Study
In this section, we dive into detailed case studies focusing on the detection of malicious traffic patterns through DNS traffic profiling. This analysis covers various network abuses, each presenting unique traffic patterns.
Our profiling method can extract the distinct characteristics of different attacks, enabling efficient detection of intrusion attempts from large-scale network traffic logs. These cases demonstrate the efficacy of our system and provide insights into the landscape of network cyberthreat activities.
Command and Control
Attackers typically use C2 domains for servers that send malware and communicate with devices compromised by malware. Our real-time malicious DNS traffic pattern detector can effectively capture DNS traffic of C2 domains based on their characteristic behavior patterns.
Our detector identified one such C2 domain, biillpi[.]com. Figure 4 shows the DNS request trends for this domain. We observe that the domain receives requests that peak once per day with relatively stable gaps. This pattern correlates with the malicious network activity pattern of Trojans.
Malware typically stays dormant for extended periods of time and activates periodically to contact the C2 server in a heartbeat pattern to confirm connection and obtain further instructions. Therefore, the network traffic a Trojan produces is sparse and presents stable patterns. Furthermore, we also observed that the DNS traffic for this domain consists of many different subdomains with random strings, which could carry data that an attacker attempted to exfiltrate through DNS tunneling.
Figure 4. DNS traffic trend for C2 domain biillpi[.]com.
Malicious DDNS
DDNS services offer a way for domain owners to automatically update the IP addresses associated with their domain names on the fly. This allows websites and services to operate seamlessly with dynamic IP addresses.
Threat actors can abuse DDNS services for C2 traffic using different IP addresses over time for the same domain. This type of DNS traffic presents exclusive characteristics:
Compared to legitimate websites and services, malicious DDNS domains receive more sparse network traffic, as there would be no continuous visits to these malicious domains.
DDNS domain records will have short TTL values, so we would see more DNS requests within a single communication session to the attackers’ infrastructure.
Figure 5 presents the DNS requests to a malicious Trojan’s C2 domain robotatten[.]com, hosted by nameservers from the DDNS provider ztomy[.]com. The DDNS service resolves this domain to many IP addresses across the world, and each record has a DNS TTL of five minutes. We notice that while there are multiple DNS requests within each session, the overall trend over the course of days is relatively sparse.
Figure 5. DNS traffic trend for malicious DDNS domain robotatten[.]com.
Strategically Aged Domains
Strategically aged domains refer to domains that are registered and left dormant for months or even years before being actively used for attack campaigns. Advanced persistent threat (APT) groups occasionally use this strategy for their C2 domains so their traffic can evade traditional domain-based reputation checks.
A strategically aged domain's DNS traffic will present a sudden burst or pattern change during their activation. Our system is able to capture this indicative signal for cyberattacks from massive DNS traffic.
Figure 6 shows an example from this type of DNS traffic trend. An infected host periodically sends a limited amount of heartbeat traffic to the malicious domain pococo[.]cc but not in a uniform manner, over the course of one day. After a successful infiltration, we would observe a much higher volume of DNS traffic toward the domains in high frequency for Trojan operations and data exfiltration.
Figure 6. DNS traffic trend for strategically aged domain pococo[.]cc.
Domain Squatting
Our detector also captures traffic toward squatting domains. One example is comcadt[.]net, which is a typosquatting domain mimicking a popular telecommunications company. Since the characters d and s are neighbors on the keyboard, an unintentional typographical error (typo) would lead a victim to the typosquatting domain.
Figure 7 shows how we observed that the DNS queries for comcadt[.]net experienced alternating active and dormant phases, with each phase lasting several days. Investigating the DNS responses for comcadt[.]net, we found this domain was hosted by more than 50 different malicious IP addresses located in the United States and the Netherlands.
Furthermore, the DNS records only had a TTL of 10 minutes, indicating the possible use of fast flux, a technique that makes the malicious domain resolve to many malicious IP addresses that rapidly circulate. Cybercriminals can use this technique to improve the resilience of their attacking infrastructure while preventing investigators from effectively isolating and blocking their attacks.
Figure 7. DNS traffic trend for typosquatting domain comcadt[.]net.
Internet Scam
Scamming websites also generate representative DNS resolution patterns that are captured by the malicious DNS traffic detector. One example is the domain carollewis[.]network.
Figure 8 shows that DNS traffic for this scam activity is relatively sparse, since once victims notice the scam website, they tend to not visit it again. We also observed that most of this scam traffic appeared during business hours.
Figure 8. DNS traffic trend for scamming domain carollewis[.]network.We find that the detected scam domain hosts several dynamically generated URLs. These URLs redirect the user to various suspicious landing pages.
An example URL is cqk1rt8hubcc73f3775g.networkcyclechain[.]com/01, which was a fake antivirus page when we checked it in a lab environment. Figure 9 presents a screenshot of the fake antivirus landing page.
Figure 9. Fake antivirus landing page.
Conclusion
Malicious DNS requests generated by attackers will present patterns that are distinct and different from legitimate DNS traffic. This insight allows us to identify malicious domains based on DNS traffic patterns and characteristics.
To capture the attacking indicators from the DNS traffic, we developed an autoencoder-based deep learning profiling solution to vectorize steaming DNS request traffic. Our autoencoder model is efficient and scalable to encode the DNS trends in real-time. Once we create a baseline of the DNS traffic, we leverage comprehensive threat intelligence to build the classifier that identifies the representative request patterns for various cyberthreats.
How Palo Alto Networks Incorporates Autoencoder-Based DNS Traffic Profiling Into Our Detections
Figure 10 shows the architecture of our system. Our traffic encoder ingests real-time logs from our Advanced DNS Security system to generate and continuously update DNS profiles for each domain and source tuple.
Figure 10. Real-time malicious DNS traffic pattern detection system.
We store all the profiles to an in-memory database so we can achieve high throughput and scalability. The maliciousness classifier scans all updated profiles to hunt for emerging attacks.
Figure 11 presents the detection performance of our detector. In May 2024, our detector captured 170 emerging malicious domains. All signatures from the detector blocked an average of 374,000 malicious DNS requests in our customers’ networks every day during this period.
Figure 11. Number of daily detections and malicious traffic prevention.
Palo Alto Networks Mitigations
Palo Alto Networks continuously monitors the traffic from the Advanced DNS Security customers to detect and block emerging cyberthreats as soon as they present suspicious network activities. The detected malicious domains are also shared with Advanced URL Filtering.
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
Japan: +81.50.1790.0200
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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.
Indicators of Compromise
Below is a list of domains and the URLs discussed in this article.
Unit 42 researchers found an extortion campaign's cloud operation that successfully compromised and extorted multiple victim organizations. It did so by leveraging exposed environment variable files (.env files) that contained sensitive variables such as credentials belonging to various applications.
Multiple security missteps were present in the course of this campaign, including the following:
Exposing environment variables
Using long-lived credentials
Absence of least privilege architecture
The campaign operation set up its attack infrastructure within various organizations’ Amazon Web Services (AWS) environments and used that groundwork to scan more than 230 million unique targets for sensitive information.
This campaign targeted 110,000 domains resulting in over 90,000 unique variables in the .env files. Of those variables, 7,000 belonged to organizations' cloud services and we traced 1,500 variables back to social media accounts. Additionally, attackers used multiple source networks to facilitate the operation.
Based on our research, the attackers used the following for this extortion campaign:
The onion router (Tor) network to perform reconnaissance and initial access operations
Virtual private networks (VPN) to achieve lateral movement and perform data exfiltration
Virtual private server (VPS) endpoints for other aspects of the campaign
The campaign involved attackers successfully ransoming data hosted within cloud storage containers. The event did not include attackers encrypting the data before ransom, but rather they exfiltrated the data and placed the ransom note in the compromised cloud storage container.
Moreover, the attackers behind this campaign likely leveraged extensive automation techniques to operate successfully and rapidly. This indicates that these threat actor groups are both skilled and knowledgeable in advanced cloud architectural processes and techniques.
Note that the attackers’ success relied on misconfigurations in victim organizations that inadvertently exposed their .env files. It did not result from vulnerabilities or misconfigurations in cloud providers’ services.
Palo Alto Networks customers are better protected from the threats discussed in this article through detection mechanisms available from the following products:
This article exposes an extortion operation that targeted cloud environments and leveraged the dynamic scalability of cloud platforms. It also leveraged multiple cloud services to successfully hold organizations’ cloud data to ransom.
The events discussed within this post took place within a cloud environment where the account operators deployed and used overly permissive IAM credentials. These credentials allowed the threat actors to perform several operations that would not have been possible if the account operators followed cloud security best practices.
Attackers obtained initial access to victims' cloud environments through exposed environment files (.env) files within the victim organization's web applications. Due to the security risks associated with authentication data stored inside .env files, organizations should follow security best practices to never expose environment files publicly.
Environment files allow users to define configuration variables used within applications and platforms. These files often contain secrets such as hard-coded cloud provider access keys, software-as-a-service (SaaS) API keys and database login information then used by the threat actor for initial access.
The attack pattern of scanning the internet for domains and exploiting credentials obtained from exposed environment variable files follows a larger pattern we believe propagates through other compromised AWS environments.
Note: The presence of these secrets resulted from misconfigurations of victim organizations who inadvertently exposed their .env files. None of the listed vendors’ applications or services had vulnerabilities or misconfigurations that resulted in this exposure.
Initial Access (MITRE ATT&CK Technique TA0001)
The activity discussed in this post resulted from exposed AWS Identity and Access Management (IAM) access keys obtained from publicly accessible .env files. The threat actors located these access keys by scanning and identifying exposed .env files hosted on unsecured web applications. Once the actors identified the exposed access keys, they used those keys to gain access to the hosting cloud environment.
Unit 42 has responded to a variety of incidents involving AWS environments over the last 12 months, including a previously reported incident involving a zero-day vulnerability within the SugarCRM platform. We continue to see a growing trend of attackers targeting cloud IAM credentials leading to initial access of organizations’ cloud environments.
The most common initial access vectors for this particular threat originate from organizations inadvertently misconfiguring servers, subsequently exposing sensitive files to the public internet, with the most frequently exposed files being .env files.
Discovery (MITRE ATT&CK Technique TA0007)
The threat actor behind this activity performed various discovery API calls to learn more about the environment and select services to exploit. These discovery operations targeted various services such as the following:
IAM
Security Token Service (STS)
Simple Storage Service (S3)
Simple Email Service (SES).
We found these aforementioned services targeted by threat actors while they looked to expand their operation’s control over an organization's cloud environment.
At the beginning of every operation for the discovery phase in this campaign, attackers ran the GetCallerIdentity API call to verify the identity of the user or role assigned to the exposed IAM credential. GetCallerIdentity is the AWS version of whoami. It returns information about the IAM credentials – associated UserID, AWS account number and the Amazon Resource Name (ARN)– of the principal used to initiate the request, as shown in Figure 1.
Figure 1. Example GetCallerIdentity and response.
For background, the AWS UserID is a unique identifier of the entity that performed the call. The AWS account number is the unique 12-digit identifier of the AWS account to which the UserID belongs.
The ARN includes the AWS account number and human-readable name of the principal performing the call. Every cloud resource has a unique ARN within an AWS account that, for example, can be subsequently used as a reference to that entity in CloudTrail logs or CloudFormation templates.
The ARN states the following information:
The AWS service it’s associated with
Region hosting the AWS resource, but for global services like IAM the region is left blank
The AWS account it's located in
The IAM resource type associated with this IAM credential (e.g., user, role, or group)
Attackers also successfully attempted the AWS API request ListUsers to gather a list of IAM users in the AWS account as well as the API request ListBuckets to identify all the existing S3 buckets. These operations give the attackers additional insight into what IAM users exist that they could exploit for future lateral movement, and they provide S3 bucket names for data exfiltration targets.
The threat actors then successfully performed more extensive discovery operations against AWS SES with the following API calls:
While the threat actor did not successfully use SES beyond the initial discovery operations listed above during this campaign, we have found that attackers often target and leverage the SES service to send phishing messages to potential victims. By leveraging legitimate SES services for phishing attacks, a threat actor's malicious emails originate from a trusted source, often allowing them to evade an organization’s defenses.
All of these various events provided the threat actor with a strong baseline understanding of what resources existed throughout the environment and where they could pivot.
Privilege Escalation (MITRE ATT&CK Tactic TA0004)
Following the threat actor’s discovery operations, they identified that the original IAM credential used to gain initial access to the cloud environment did not have administrator access to all cloud resources. We determined that the attackers discovered the original IAM role used for initial access did have the permissions to both create new IAM roles and attach IAM policies to existing roles. Using these capabilities, the attacker successfully escalated their privileges within victim cloud environments by creating new IAM resources with unlimited access.
To accomplish this, they first created an IAM role named lambda-ex with the API request CreateRole, then used the API call AttachRolePolicy to attach the AWS-managed policy AdministratorAccess to the newly created lambda-ex role, as shown in Figure 2.
Figure 2. JSON permissions for the AdministratorAccess policy.
These two IAM events resulted in a new IAM role with administrative permissions, within the compromised AWS account, completing the threat actor’s privilege escalation portion of the attacks. In the following section, we discuss how the threat actors used this role to grant unfettered access to their newly created lambda functions.
Execution (MITRE ATT&CK Tactic TA0002)
Following the successful creation of the privileged IAM role, the threat actor attempted to create two different infrastructure stacks, one using Amazon Elastic Cloud Compute (EC2) resources and the other with AWS Lambda. By performing these execution tactics, the actors failed to create a security group, key pair and EC2 instance, but they successfully created multiple lambda functions with the newly created IAM role attached.
The threat actor attempted to create new EC2 resources to use for cryptomining based on the size of the instance. They successfully created new Lambda functions for their automated scanning operation.
Failed EC2 Creation
During these failed operations, the attackers first attempted to perform the API call CreateSecurityGroup and named the group security. Then they ran AuthorizeSecurityGroupIngress to create an ingress rule allowing all ports from 0 - 65535 from any IP address (0.0.0.0/0). Following that, they attempted to CreateKeyPair and RunInstances with Amazon Machine Image (AMI) IDami-08e8725a42775740f and an EC2 c6g instance type.
C-series instances are compute optimized virtual machines, which are ideal for computationally intensive workloads. As such, malicious actors have often used these instances for cryptojacking operations.
The AMI ID belonged to a publicly accessible Ubuntu 18.04 LTS image in the us-east-1region and the c6g instance type family ran on AWS Graviton2 processors built for compute-intensive workloads.
All of these actions took place in under a minute, indicating a pre-scripted, automated activity. However, these actions failed due to limited permissions associated with the compromised IAM user.
Successful Lambda Function Creation
Following the failed EC2 service actions, the threat actor successfully pivoted to the AWS Lambda service, a cloud-based serverless computation service, where they used the granted permissions obtained from the exposed IAM credential. Their first operation created a new lambda function using the CreateFunction20150331 API call in the AWS region us-east-1, which created a new lambda function named ex. We will go into a deep dive into the lambda function’s code and its purpose in the next section.
Once the threat actor successfully created the first lambda function, they automatically deployed that same lambda function into every other enabled region in the account within a second. As part of the default lambda function creation process, the role attached to the lambda function automatically performs a CreateLogGroup API call followed by CreateLogStream, which begins the process of logging all lambda function operations.
The CreateLogGroup event created a new CloudWatch log group containing the name of the newly created lambda /aws/lambda/ex. Each log stream within the log group aggregates various lambda run information by date. This allowed us to successfully follow the threat actor's operations using the lambda function ex they created. It is important to note that the lambda function’s logging creation process is automated and attackers cannot turn it off.
The threat actor created a malicious lambda function by leveraging the stolen IAM user credentials. The Unit 42 reverse engineering team analyzed the malicious lambda function, which consisted of a bash script configured to perform internet-wide scanning using a preconfigured set of sources containing millions of domains and IP addresses. Figure 3 displays the complete code of the lambda function.
Figure 3. The lambda function bash script.
The script retrieved a list of potential targets from a publicly accessible third-party S3 bucket exploited by the threat actor. We believe the threat actor hosted these third-party S3 buckets within other compromised and legitimate cloud environments, and the threat actor leveraged these resources in this attack. The list of potential targets the malicious lambda function iterated over contained a record of victim domains. For each domain in the list, the code performed a cURL request, targeting any environment variable files exposed at that domain, (i.e., http://<target>/.env).
Upon successfully retrieving the domain’s exposed environment file, the lambda function uncovered and identified cleartext credentials contained within the file. Once the lambda function identified the credentials, it stored them in a newly created folder within another threat-actor-controlled public S3 bucket.
The malicious lambda function specifically targeted instances where the .env file referenced the string mailgun as seen on line 24 within Figure 3. With these compromised Mailgun credentials, threat actors can send large-scale phishing attacks against organizations from legitimate domains, making their attacks more likely to bypass security protections. We accessed the publicly exposed threat actor’s public S3 bucket and assessed that the threat actor could copy the exposed .env files of at least 110,000 domains.
The following diagram, Figure 4, shows the threat actor’s architectural design for scanning and retrieving the exposed authentication credentials in the .env files.
Figure 4. High-level example of the threat actor's operational architecture.
We believe this design is part of a larger, fully automated operation based upon some of the S3 bucket naming conventions alone (e.g., s3://<REDACTED>/ref5/). Due to the large number of targeted domains, we have high confidence that the attackers heavily relied upon automation to achieve their goals.
Further evidence for the heavy reliance upon automation came during our analysis of the threat actor’s public S3 bucket. We identified more than 230 million unique targets that the threat actor was scanning for misconfigured and exposed environment files. Figure 5 shows the contents of the threat actor’s public bucket, listing the number of configured targets.
Figure 5. Target count per scan file and total (the name of the file is on the right).
At the time of access to this public S3 bucket, we estimate that multiple compromised AWS accounts were the target of this malicious scanning as part of a compromise-scan-compromise automated operation. In a later section of this article, we will describe more details about the misconfigured .env finding.
Exfiltration (MITRE ATT&CK Tactic TA0010)
These attacks also included data exfiltration operations from S3 buckets through the use of the S3 Browser tool. This tool generates various S3 API calls when used. These events show which S3 buckets the threat actors interacted with regardless of whether the S3 object-level logging was enabled (shown in Figure 6). These API calls include:
Note, if an S3 bucket does not have object-level logging enabled, Cost and Usage Reports can provide a way to determine if the S3 Browser activity resulted in data exfiltration.
Impact (MITRE ATT&CK Tactic TA0040)
After the threat actor successfully exfiltrated and deleted S3 objects from the target victim’s S3 bucket, they uploaded a ransom note to the now empty bucket. One example is shown in Figure 7.
Figure 7. Ransom note left by the threat actor.
Ransom notes are typically the last step in the extortion process and are designed to scare and coerce the victim to pay an often large fee. Victims make the ransom payment to ostensibly prevent the threat actor from selling or leaking their stolen data on the dark web and to hopefully get their deleted data back. See the Unit 42 Ransomware and Extortion Report for additional information regarding ransomware and extortion trends.
Attackers often upload ransom notes to the impacted S3 bucket. There are also occurrences where the threat actor will email the note to stakeholders of the victim company.
Assessing the Impact of the Leak
As mentioned earlier, the threat actor created a lambda function to scan an extensive list of domains looking for misconfigured and exposed .env files. Ironically, we found we could access the threat actors’ publicly exposed S3 bucket that they used to store and view the stolen .env files. The data in this exposed S3 bucket consisted of the leaked environment variables collected by the threat actors from the misconfigured publicly exposed .env files.
Some of the .env files contained multiple variables that revealed information about several services used within a victim’s infrastructure. Figure 8 shows an example of a complex .env file.
Figure 8. Example of .env file with more than 40 configurations.
We found that the exposed .env files contained a variety of credentials, not only related to cloud infrastructure but also to social media accounts and other on-premises applications. Due to the variety of credentials, we categorized them based on related services to better represent the breadth of exposed credentials. The chart in Figure 9 shows the statistics of credential exposures obtained from the exposed .env files, based on the application type.
Figure 9. Statistics of categorized leaks from .env variables.
We identified over 90,000 unique combinations of leaked environment variables that contained access keys or IAM credentials, with 7,000 access keys directly associated with various cloud services. Not all the leaks necessarily contained user accounts or secrets, but all of them leaked some details about a victim’s internal infrastructure or its configuration.
The threat actor discovered exposed access keys within these variables and used select access credentials as an initial attack vector. Most concerningly, 1,515 of the leaked variables were associated with social media platforms; some of them included account names and authentication secret keys.
We found that while the threat actor’s lambda function initially targeted Mailgun credentials, they captured many other secrets belonging to cloud service providers and SaaS applications.
As noted above, the presence of these secrets resulted from misconfigurations in victim organizations, not from vulnerabilities or misconfigurations in listed vendors’ applications or services.
Figure 10 below shows the breakdown of the top six unique cloud and SaaS secrets stolen and grouped by their respective provider.
Figure 10. Top six cloud and SaaS platforms identified in the .env files.
Please note that Unit 42 did not assess the validity of these credentials. Through the malicious lambda function, the threat actor gained access to several types of credentials. Unit 42 assesses with high confidence that the threat actor likely leveraged the stolen secrets to carry out further acts against victims.
We notified AWS about the availability of the public bucket and its role in an ongoing compromise. Shortly after notification, the public bucket was no longer available.
Network Analysis
When reviewing the different components discussed in this article, we identified various correlations based on network indicators.
The graph displayed in Figure 11 shows network correlations by IP address, user-agent and exit point type. After careful examination of the malicious network traffic, we identified the following exit point categories:
VPN exit node: Known VPN exit point
Tor exit node: Tor network
VPS exit node: Hosting provider
Institution exit node: IP was currently allocated and used by the institution
ISP exit node: Internet service provider, giving services directly to users
Cloud exit node: The access was performed from a cloud provider
Figure 11. Network graph of malicious access for all incidents.
We used internal and public data sources to categorize the originating IP addresses used by the threat actors during this campaign according to the exit node type. The activity in Figure 11 above represents access attempts the threat actor performed using the AWS IAM credentials either discovered from the victim’s exposed environment file or from IAM roles created by the threat actor.
The threat actor operated discreetly using Tor network connections when creating the lambda function activities. After that, the threat actor pivoted to using a VPN for all S3 access and exfiltration using the S3 Browser tool. However, the threat actor made a connection from a controlled AWS account to access S3 customer internal buckets. This event left a trace on AWS-hosted infrastructure that we could follow.
We assess with medium to high confidence that the threat actor accessed the compromised victims’ AWS environment from IP addresses directly assigned to ISPs. This operational security (OPSEC) misstep allowed us to determine, with medium confidence, the threat actor’s general geographic location.
Unit 42 determined one ISP IP address was geolocated in Ukraine and appeared in part of the lambda function activity. The second ISP IP address was geolocated in Morocco and was associated with the S3 access and exfiltration. Based on the user-agents and time between API calls, we determined the threat actor manually performed these access operations, which leaked the threat actor's possible physical location.
Cost and Usage Reports
Logs are essential for effective incident response, and an ideal environment has all logging options enabled. To identify exfiltration events from S3 buckets with granularity, organizations should enable S3 access logging or CloudTrail data events logging prior to an incident occurring.
Both forms of logging help organizations identify GetObject API calls (e.g., the data being fetched) and DeleteObject API calls (e.g., the data being deleted). Both S3 access logging and CloudTrail event logging record the IP addresses and user agents for each request made to the target bucket.
It’s important to note that neither of these log sources are enabled by default, and they will increase costs for the organization’s cloud environment. However, enabling logging for these sources will greatly assist in the identification and alerting of malicious cloud operations.
However, if neither CloudTrail event logging nor S3 access logs are enabled at the time of an incident, there is still hope. Leveraging the Cost and Usage report for S3 can allow organizations to identify spikes in the occurrences of the API calls for GetObject (bytes out) and DeleteObject (bytes deleted) events.
There are drawbacks in leveraging Cost and Usage Reports to identify exfiltration operations. Organizations can only identify high-level activity that occurred within the bucket and the data can only be aggregated into hourly, daily or monthly time frames as shown in Figure 12. This prevents organizations from investigating individual events or retrieving the metadata associated with each of the events.
Figure 12. Cost and Usage Report line item examples.
The GetObject and DeleteObject Cost and Usage Activity records bytes out or bytes deleted, respectively. Using these reports, we have successfully assessed the likelihood that exfiltration events have occurred, pointing to key time frames when there are anomalous spikes in activity.
Remediation
In a majority of these attacks, threat actors obtained long-term IAM access keys allowing them to move into the control plane with no time limit to their credentials. Unless an application or workload requires the use of an access key, IAM roles provide the same ability as access keys, but they are temporary. Using temporary credentials limits the amount of time a threat actor has access to an account.
Another way to protect against these attacks is following the principle of least privilege when provisioning permissions. Limiting the permissions associated with an IAM resource limits the scope of what a compromised credential can perform (e.g., restricting identities that can perform iam:CreateRole and iam:AttachRolePolicy). That way even if a threat actor were to successfully gain access to long-term or short-term credentials, they wouldn’t have enough permissions to execute their malicious actions.
Additionally, disabling all unused regions within an AWS account also protects against these attacks. Threat actors deploy resources in multiple regions to attempt to remain undetected, so disabling all unused regions prevents the threat actors from hiding their attacks.
And finally, enabling logging and establishing a monitoring process is vital to protecting an organization's resources. Regarding AWS, enabling basic logging such as CloudTrail and VPC flow logs provides the base level of visibility into an environment. Amazon GuardDuty also contains a variety of features to help protect against threats to EC2 instances and credential exploitation.
Depending on the AWS services used, organizations will want to ensure they enable the specific logging unique to that service. After organizations establish the proper logging and retention of that data (90 days minimum retention recommended), then the focus shifts to monitoring those data sources.
AWS’s GuardDuty provides a base level of alerting, but each organization should review what services they use and how abnormal activity might appear in the logs. From there, organizations should create alerts for abnormal activity.
Conclusion
We identified a wide-scale extortion operation that resulted in the successful compromise of several cloud environments. The initial access used within the extortion campaign was the direct result of exposed environment files (.env) files within the victim organization's web applications.
By targeting .env files, the threat actor was able to collect the exposed environment files of at least 110,000 domains. We identified over 90,000 unique leaked environment variables of which 7,000 were associated with cloud services and 1,500 were associated with social media accounts, oftentimes including account names in addition to authentication secret keys.
Protections and Mitigations
For Palo Alto Networks customers, our products and services provide the following coverage associated with the threats described above:
Prevent the execution of known malicious malware, and also prevent the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module.
Protect against credential gathering tools and techniques using the new Credential Gathering Protection available from Cortex XDR 3.4.
Attack Path Policies are built on a unified data model that automatically correlates findings across cloud misconfigurations, vulnerabilities, excessive IAM permissions and network exposures. When combined with Unit 42 Threat Intelligence, coupled with machine learning (ML) and user and entity behavior analytics (UEBA), security teams can detect exploited attack paths.
When paired with the WildFire integration, the Prisma Cloud Defender agent will identify malicious binaries and make verdict determinations when analyzing executing processes.
When paired with XSIAM, the Prisma Cloud Defender is enabled to block malicious processes from operating within the cloud environment.
Prevents the execution of known malicious malware, and also prevents the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module.
Hunting, Investigation and Detection Queries
The following queries are intended to assist Palo Alto Networks customers in hunting, investigating and detecting potentially malicious operations within their Cortex XDR and Prisma Cloud platforms. The results of these queries should not be taken as malicious on face value. The queries require careful examination of the resulting events before they can be found malicious.
Pay close attention to the source IP addresses, user agent and the ARNs for each event. If ARNs are being created, modified or deleted, investigate for unwanted modifications to critical infrastructure or the creation of unknown or suspicious ARN names. Unit 42 IR services are available for anyone who’s determined they have been breached, compromised or otherwise affected by malicious events.
event from cloud.audit_logs where cloud.type='aws'ANDcloud.service='iam.amazonaws.com'ANDoperation IN('CreateRole','AttachRolePolicy')ADDCOLUMN$.userAgent$.requestParameters.policyArn
Security Groups
1
event from cloud.audit_logs where cloud.type='aws'ANDcloud.service='iam.amazonaws.com'ANDoperation IN('CreateSecurityGroup','AuthorizeSecurityGroupIngress')ADDCOLUMN$.userAgent$.requestParameters.policyArn
EC2
1
event from cloud.audit_logs where cloud.type='aws'ANDcloud.service='iam.amazonaws.com'ANDoperation IN('CreateKeyPair','RunInstances')ADDCOLUMN$.userAgent$.requestParameters.policyArn
Lambda
1
event from cloud.audit_logs where cloud.type='aws'ANDcloud.service='iam.amazonaws.com'ANDoperation IN('CreateFunction20150331','CreateLogGroup','CreateLogStream')ADDCOLUMN$.userAgent$.requestParameters.policyArn
Prisma Cloud Attack Path Alerting
Prisma Cloud Attack Paths offer a unique view into the configuration of cloud environments. By linking potential architectural misconfigurations, attack path alerts allow security operation center (SOC) personnel the ability to zero in on potential malicious cloud events.
By combining DevOps configurations and behavioral anomaly detection rules, attack path alerts trigger if a combination of event operations takes place. These alerts scale with the dynamic nature of cloud environments and allow SOC teams to maintain awareness of security events across multiple cloud platforms.
While there are many Attack Path Policies that could assist organizations, the following Attack Path Policies could assist SOC and DevOps teams monitor and maintain cloud security:
Credential exposure risk due to a publicly exposed and unauthenticated AWS Lambda function with risky credential exposure permissions
Credential exposure risk due to a publicly exposed and vulnerable EC2 instance with risky credential exposure permissions
Credential exposure risk due to malware in Amazon EC2 instances with risky credential exposure permissions
Data breach risk due to a publicly exposed and unauthenticated AWS Lambda function with Amazon RDS database SQL query execution permissions
Data breach risk due to AWS S3 bucket containing sensitive data not configured with access log feature and is accessible by unmonitored cloud accounts
Data exposure and data loss risk due to a publicly exposed unauthenticated AWS Lambda function with permissions over sensitive S3 configuration
Indicators of Compromise
URL
https[:]//github[.]com/brentp/gargs/releases/download/v0.3.9/gargs_linux (not malicious, used by the lambda function)
IPv4
Tor Exit Nodes
109.70.100[.]71
144.172.118[.]62
176.123.8[.]245
185.100.85[.]25
185.100.87[.]41
185.220.101[.]190
185.220.101[.]19
185.220.101[.]21
185.220.101[.]29
185.220.101[.]30
185.220.101[.]86
185.220.103[.]113
192.42.116[.]181
192.42.116[.]187
192.42.116[.]18
192.42.116[.]192
192.42.116[.]199
192.42.116[.]201
192.42.116[.]208
192.42.116[.]218
198.251.88[.]142
199.249.230[.]161
45.83.104[.]137
62.171.137[.]169
80.67.167[.]81
89.234.157[.]254
94.142.241[.]194
95.214.234[.]103
VPS Endpoints
125.20.131[.]190
196.112.184[.]14
46.150.66[.]226
49.37.170[.]97
VPN Endpoints
139.99.68[.]203
141.95.89[.]92
146.70.184[.]10
178.132.108[.]124
193.42.98[.]65
193.42.99[.]169
193.42.99[.]50
193.42.99[.]58
195.158.248[.]220
195.158.248[.]60
45.137.126[.]12
45.137.126[.]16
45.137.126[.]18
45.137.126[.]41
45.94.208[.]42
45.94.208[.]63
45.94.208[.]76
45.94.208[.]85
72.55.136[.]154
95.214.216[.]158
95.214.217[.]173
95.214.217[.]224
95.214.217[.]242
95.214.217[.]33
Hash
SHA256 for Lambda.sh - 64e6ce23db74aed7c923268e953688fa5cc909cc9d1e84dd46063b62bd649bf6
Updated title Sept. 3, 2024, at 1:1o p.m. PT for clarity.
Our latest Unit 42 Attack Surface Threat Report explores the attack surface landscape of 265 global organizations worldwide. The report is based on our observable data on exposures and vulnerabilities that are publicly accessible over the internet, collected over a one-year period. It also offers recommendations on how organizations should approach active attack surface management (ASM). Here we summarize key findings from the report and recommendations from the report, providing a high-level overview of today’s attack surface landscape.
Key Findings on the Attack Surface Landscape
Change in attack surfaces inevitably leads to exposure. We observed that attack surfaces across industries are always in a state of flux. Our research indicates that, on average, an organization’s attack surface has over 300 new services every month. These additions alone account for nearly 32% of new high or critical exposures for organizations.
The media and entertainment industry experienced the highest rate of new services added, exceeding 7,000 per month.
Figure 1 shows that all industries consistently add new services to their growing attack surface. Sectors like telecommunications, insurance, pharma and life sciences add over 1,000 new services every month. Critical industries like financial services, healthcare and manufacturing add over 200 new services monthly.
Figure 1. Median count of new services introduced by a typical company in each industry during a given month across the 265 global organizations we analyzed.
For the past three years, the Unit 42 Incident Response Report has identified the most commonly targeted industries, which are also the top industries Unit 42 has provided incident response services to. In 2024, the top six industries identified were professional and legal services, high technology, manufacturing, healthcare, finance and wholesale and retail. Together, these industries accounted for 63% of cases.
While these statistics show which industries ask us for expert incident response help, other industries are at risk too.
Critical IT and security services are dangerously exposed to the internet.
Figure 2 shows that over 23% of exposures among the organizations we studied involve critical IT and security infrastructure, which opens the door to opportunistic attacks.
Figure 2. Distribution of exposure categories observed across the 265 global organizations in the last 12 months.
These exposures include vulnerabilities in the following application-layer protocols:
SNMP
NetBIOS
PPTP
It also includes vulnerabilities in internet-accessible administrative login pages of the following products:
Routers
Firewalls
VPNs
Other core networking and security appliances
Recommendations For Actively Managing Your Attack Surface
A critical challenge for most organizations is tracking and protecting all assets. The 2024 Unit 42 Incident Response report reveals that in the past year, attackers most often gained initial access through software vulnerabilities, with the largest attack campaigns exploiting internet-facing systems.
To protect against these attack surface vulnerabilities, organizations should:
Maintain persistent, comprehensive visibility Identifying and responding to attack surface risks starts with continuous, comprehensive scans of your organization's ports, services and devices.
Monitor for unsanctioned services or shadow IT Regularly check perimeter resources to distinguish between expected assets and unknown or out-of-scope ones, ensuring adherence to security baselines. Deviations from these baselines are often the most vulnerable to compromise, making them prime targets for attackers.
Remediate critical exposure risks in real time
Detection is only half of the battle. It is crucial to have processes and technology to assist security teams in identifying, communicating, tracking and automating remediation where possible.
If ASM is new to your organization, or you’d like help with improving your program, Cortex Xpanse and Unit 42 Attack Surface Assessment can jump-start your journey. This assessment service gives you better visibility into your on-premises and cloud-based internet-connected assets and recommendations on prioritized actions to help you defend your organization.
Additionally, adding the ASM Module to your XSIAM deployment provides context on internet-exposed assets to enhance threat prevention, detection and response with AI and machine intelligence.
This research reviews an attack vector allowing the compromise of GitHub repositories, which not only has severe consequences in itself but could also potentially lead to high-level access to cloud environments. This is made possible through the abuse of GitHub Actions artifacts generated as part of organizations’ CI/CD workflows. A combination of misconfigurations and security flaws can make artifacts leak tokens, both of third party cloud services and GitHub tokens, making them available for anyone with read access to the repository to consume. This allows malicious actors with access to these artifacts the potential of compromising the services to which these secrets grant access. In most of the vulnerable projects we discovered during this research, the most common leakage is of GitHub tokens, allowing an attacker to act against the triggering GitHub repository. This potentially leads to the push of malicious code that can flow to production through the CI/CD pipeline, or to access secrets stored in the GitHub repository and organization.
While the research applies to both private and public GitHub repositories, this article focuses on the discovery of vulnerable public repositories. We uncover high-profile open-source projects owned by the biggest companies in the world, which before mitigation could have led to a potential impact on millions of their consumers. All of the disclosed cases were reported to the maintainers of these projects. We received great support from all teams, and were able to collaborate to mitigate all of the discoveries quickly and efficiently.
CI/CD environments, processes and systems are an essential part of modern software organizations. They’re responsible for the crucial flow of building, testing and delivering code to production. Naturally, CI/CD pipelines use highly sensitive credentials to authenticate against various types of services, creating a significant challenge to keep a high-level of credential hygiene. This article covers the potential impact of insecure usage of GitHub Actions artifacts, as well as the methods and tools to protect against this threat.
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
Prisma Cloud customers are better protected by the attack path policies continuously monitoring and alerting on potential attack paths.
The Unit 42 Incident Response team can also be engaged to help with a compromise or to provide a proactive assessment to lower your risk.
Exploring Workflow Artifacts
Knowing how sensitive CI/CD systems are, I had to follow a hunch I had about an overlooked feature called workflow artifacts in the leading source control platform and home of many open-source projects, GitHub.
I was quite convinced I’d find sensitive data or credentials, and as it turned out, the discovery was even bigger than what I had envisioned. In fact, it impacted well-known open-source projects owned by Red Hat, Google, AWS, Canonical (Ubuntu), Microsoft, OWASP and others — and potentially reached millions of their product users.
GitHub Actions Build Artifacts
In GitHub Actions, workflow build artifacts offer a powerful mechanism for persisting and sharing data across jobs within the same workflow. These artifacts can be any files generated during your build process, such as compiled code, test reports or deployment packages.
Artifacts ensure critical data isn't lost after a workflow finishes, making the data accessible for later analysis or deployment. This is particularly useful for sharing test results or deployment packages between dependent jobs. Overall, workflow build artifacts streamline your workflows by facilitating data transfer and promoting efficient execution within the GitHub Actions environment.
The Hunch
GitHub Actions workflows frequently use secrets to interact with various cloud services and with GitHub itself. These secrets include the ephemeral, automatically created GITHUB_TOKEN used to perform actions against the repository. The Actions build artifacts are outputs generated by the execution of workflows, and once created, they’re stored for up to 90 days. In open-source projects, these artifacts are publicly available for anyone to consume.
So why not scan these artifacts for secrets?
Figure 1. GitHub Actions artifact.
This approach offers a straightforward method for identifying potential security risks.
I then compiled a list of popular open-source projects on GitHub and automated the sequence of downloading their artifacts and scanning them for secrets.
Found Some Tokens, Now What?
My hunch was spot on. I found working tokens for various cloud services, including music streaming, cloud infrastructure and more. I also found something far more interesting — various GitHub tokens. Using them, though, was not straightforward.
Let's understand why and take a technical dive into the different types of tokens created by GitHub when a workflow runs.
How GitHub Tokens Find Their Way into Artifacts
Two types of GitHub tokens kept popping up: GITHUB_TOKEN, which has a prefix of ghs_, and ACTIONS_RUNTIME_TOKEN, which is a JWT (JSON Web Token).
It's important to note that these tokens weren’t part of the repository code but were only found in repository-produced artifacts. Before determining what I could do with them, I wanted to know how these tokens ended up inside artifacts in the first place.
Most GitHub users use the actions/checkout GitHub action for the obvious need of cloning their repository code for availability during the workflow run. The default behavior of actions/checkout is to persist credentials, which means the GITHUB_TOKEN is written to the local git directory, enabling it to run authenticated git commands against the repository. Most users, I’m willing to bet, aren’t aware of this default behavior and don't require the functionality. In many cases, after all, a simple clone is all that’s required for the workflow to do its job.
Figure 2: GitHub token encoded in base64 publicly accessible and embedded in an artifact of project CycloneDX by OWASP.
From what I’ve seen, users commonly — and mistakenly — upload their entire checkout directory as an artifact. The directory contains the hidden .git folder that stores the persisted GITHUB_TOKEN, leading the publicly accessible artifacts to contain the GITHUB_TOKEN.
As seen in Figure 3, the microsoft/typescript-bot-test-triggerer project uploaded the entire checkout directory as an artifact, along with the persisted GITHUB_TOKEN stored in the .git directory.
Figure 3. Example of a Microsoft repository workflow uploading a valid GITHUB_TOKEN in an artifact.
Once the CREATE_LOG_FILE property of super-linter is set to True, super-linter creates a log file with lots of details, including environment variables. CI/CD pipelines usually contain secrets loaded as environment variables — GitHub tokens included, meaning that logging them probably isn’t a good idea.
The super-linter log file is often uploaded as a build artifact for reasons like debuggability and maintenance. But this practice exposed sensitive tokens of the repository.
The obvious choice would be leveraging the widely used GITHUB_TOKEN against the repository. It’s an ephemeral token created in any workflow job run and designed to allow workflows to interact with GitHub resources, like the workflow’s repository. The token can be set with limited scope and to expire on job completion, both of which will limit risk in the event of a token leakage.
During my research, though, I discovered that workflow artifacts are only available for download after the entire workflow finishes. Since the GITHUB_TOKEN expires when the job ends, I won’t be able to download the artifact and extract the token. Bummer! (Spoiler: This is just the beginning).
But I’m left with repos exposing their ACTIONS_RUNTIME_TOKEN, which is a JWT (JSON Web Token) with an expiration of about six hours according to the exp (expiration) property. ACTIONS_RUNTIME_TOKEN is an undocumented environment variable, used by several popular actions owned by GitHub, such as actions/cache and actions/upload-artifact, to manage caching and artifacts. Caching helps to speed up workflows by storing and reusing downloaded files or build results. We're already familiar with the role of artifacts.
By tracking a workflow run from a project that leaked a token, I could download its artifacts within the six-hour window before the token expires. Extracting the token could then be used to manage cache and artifacts.
But workflow runtimes are unpredictable unless triggered by a schedule (cron). I automated a process that downloads an artifact, extracts the ACTIONS_RUNTIME_TOKEN, and uses it to replace the artifact with a malicious one.
Subsequent workflow jobs often rely on previously uploaded artifacts. Cases of this kind open the door for remote code execution (RCE) on the runner that runs the job consuming the malicious artifact. RCE can also occur if developers download and execute a malicious artifact, leading to compromised workstations.
The video below demonstrates an attack on the SchemeCrawler project. I identified a public artifact that contains the ACTIONS_RUNTIME_TOKEN and used it to upload my own malicious artifact to replace the existing one.
Figure 5. A recorded attack on project SchemeCrawler, where I’ve injected a “malicious” artifact.
The GITHUB_TOKEN Plot Twist
Cool as it was, I craved more. There were a lot of cases where I had a leaked GITHUB_TOKEN, and I wanted to use it and push unreviewed code to the repository. But as I mentioned, these tokens were useless.
Then, with incredible timing, GitHub announced version 4 of the artifacts feature. It has impressive improvements, like 10x faster uploads. But one particular detail surprised me like an immediate call for action.
“Another common request from our users was the ability to download artifacts from the UI or API while the workflow run is in progress.”
As I read this sentence, my researcher spidey-senses tingled. It suggests that a race condition was just made possible, allowing the leaked GITHUB_TOKEN to be downloaded, extracted and used before the job finished and the token expired.
An attack flow might resemble the following:
The attacker waits for a pipeline to be triggered.
The repository triggers a pipeline.
The pipeline inadvertently uploads an artifact that includes the GITHUB_TOKEN.
Before the workflow job finishes, an attacker downloads the publicly available artifact.
The attacker extracts the token from the artifact and uses it to push malicious code to the repository.
The pipeline job ends, and the GITHUB_TOKEN is invalidated.
Figure 6: Attack flow.
Pushing Code Before the Clock Runs Out
First, I created a list of open-source projects using the upload-artifact@v4 action. The list quickly grew, especially since GitHub announced the deprecation of v3, effective November 2024. Software dependencies bots automatically create pull requests updating to v4, which accelerated this process even further. I scanned the artifacts of each of these projects for secrets and was interested in the ones exposing their GITHUB_TOKEN.
It was time for my first attempt to push code to an open-source project. To avoid harming the project, I decided that creating a branch was sufficient, as it requires write permissions, same as pushing code.
I chose a project from the list where the workflow had the contents: write permission. Spoiler alert: Most of them did, which wasn't surprising, given my previous work exploring how popular open-source projects manage their workflows’ permissions.
No luck exploiting tokens! Every time I tried to use the leaked token, it had already expired, leading to a consistent "401 Unauthorized: message: Bad Credentials" error. Usually, artifacts are uploaded as the last step of the job. The job ends right after upload is complete. Downloading and extracting the vulnerable artifact proved just slow enough for the token to expire before I could leverage it. Reviewing the workflow build logs revealed the reason it failed — a two-second delay.
I returned to my list and selected a project where the artifact upload step didn’t bring the artifact to an end but was followed by additional steps, granting me an opportunity to steal and use the token before it expired.
It worked! I was able to create a branch (write operation) in an open-source project — clair, even though as an external contributor, I obviously don't have permission to do that. I could simply push code following the same process.
Figure 7. Creation of branch impala in the “clair” open-source project by Red Hat.
Figure 8. Screen recording of the actual attack.
Let’s Win More Races
While I successfully exploited the issue, I wanted to broaden the attack's applicability. Previously, the attack relied on the workflow job having subsequent steps after the artifact upload, granting me a window to use the token. To improve the success rate, I applied some good old engineering to make it more robust.
Downloading the artifact to my own machine was too slow.
Needing to be closer to the target, GitHub Actions presented a perfect solution. It can be triggered remotely, run on the same cloud infrastructure as our targets, meaning lower latency and much faster downloads, plus high configurability.
I needed to further optimize performance and reduce communication time, Since artifacts are compressed, I selectively extracted only the git config file, skipping most of the archive content. Also, I sent dozens of requests per second while staying under the GitHub rate limit and disabled certificate verification.
Eventually, I came up with this design:
A machine that samples the target repository and waits for a workflow_run event (like an alert) to notify me when an attack is in progress.
Once a workflow was running, a malicious GitHub Actions workflow, which I named "RepoReaper," was launched.
The RepoReaper workflow waits for the exact moment an artifact containing a leaked token is present.
The RepoReaper workflow downloads the artifact, extracts the token and uses it to create a branch via the REST API on the target repository.
Target repository compromised. It could have easily contained malicious code.
Then, I could use this design to search and target open-source projects.
Projects I’ve Helped Secure
The research laid out here allowed me to compromise dozens of projects maintained by well-known organizations, including firebase-js-sdk by Google, a JavaScript package directly referenced by 1.6 million public projects, according to GitHub. Another high-profile project involved adsys, a tool included in the Ubuntu distribution used by corporations for integration with Active Directory.
All open-source projects I approached with this issue cooperated swiftly and patched their code. Some offered bounties and cool swag. Here’s partial list of affected projects I’m allowed to disclose:
This research was reported to GitHub's bug bounty program. They categorized the issue as informational, placing the onus on users to secure their uploaded artifacts.
Stopping the Leak
My aim in this article is to highlight the potential for unintentionally exposing sensitive information through artifacts in GitHub Actions workflows. To address the concern, I developed a proof of concept (PoC) custom action that safeguards against such leaks.
The action uses the @actions/artifact package, which is also used by the upload-artifact GitHub action, adding a crucial security layer by using an open-source scanner to audit the source directory for secrets and blocking the artifact upload when risk of accidental secret exposure exists. This approach promotes a more secure workflow environment.
Figure 9. The action upload-secure-artifact failed the workflow due to the existence of a GITHUB_TOKEN in the uploaded artifact.
Conclusion
As this research shows, we have a gap in the current security conversation regarding artifact scanning. GitHub's deprecation of Artifacts V3 should prompt organizations using the artifacts mechanism to reevaluate the way they use it.
Security defenders must adopt a holistic approach, meticulously scrutinizing every stage — from code to production — for potential vulnerabilities. Overlooked elements like build artifacts often become prime targets for attackers.
Reduce workflow permissions of runner tokens according to least privilege and review artifact creation in your CI/CD pipelines. By implementing a proactive and vigilant approach to security, defenders can significantly strengthen their project's security posture.
Prisma Cloud and Other Palo Alto Networks Protection and Mitigation
Prisma Cloud detects vulnerable code that leaks the GITHUB_TOKEN within artifacts, equipping security teams to prevent attackers from using it to inject code into the repository, publishing packages or triggering pipelines, all of which could result in malicious code reaching production. The platform also offers policies to significantly reduce the potential impact of a breach — ensuring minimum permissions granted to pipelines, for example.
Figure 10. Prisma Cloud detects vulnerable code that leaks the GITHUB_TOKEN within artifacts.
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
Japan: +81.50.1790.0200
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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.
This post presents our research on a methodology we call BOLABuster, which uses large language models (LLMs) to detect broken object level authorization (BOLA) vulnerabilities. By automating BOLA detection at scale, we will show promising results in identifying these vulnerabilities in open-source projects.
BOLA is a widespread and potentially critical vulnerability in modern APIs and web applications. While manually exploiting BOLA vulnerabilities is usually straightforward, automatically identifying new BOLAs is challenging for the following reasons:
The complexities of application logic
The diverse range of input parameters
The stateful nature of modern web applications
For these reasons, traditional methodologies like fuzzing and static analysis are ineffective in detecting BOLAs, making manual detection the standard approach.
To address these challenges, we utilize the reasoning and generative capabilities of LLMs to automate tasks traditionally done manually. These tasks include the following:
Understanding application logic
Identifying endpoint dependency relationships
Generating test cases and interpreting test results
By combining LLMs with heuristics, our method enables fully automated BOLA detection at scale.
Although our research is in its early stages, we have successfully uncovered quite a few BOLA vulnerabilities in both internal and open-source projects. These include the following vulnerabilities:
As we continue to refine our research, we are also proactively hunting for BOLAs in the wild.
Cortex Xpanse and Cortex XSIAM customers with the ASM module are able to detect all exposed Grafana, Harbor and Easy!Appointments instances as well as known insecure instances via targeted attack surface rules.
As explained in a previous article on BOLA vulnerabilities, BOLA occurs when an API application's backend fails to validate whether a user has the right permissions to access, modify or delete an object.
Figure 1 illustrates a simple BOLA example. In this medical application, patients can use the API api.clinic[.]site/get_history?visit_id=XXXX to access the doctor visit note.
Each patient should only have access to their own medical records. However, if the server fails to properly validate this logic, a malicious patient may manipulate the visit_id parameter in the request to access another patient's data. Figure 1 shows this manipulation in the malicious API call.
Figure 1. An example of BOLA vulnerability.
Although the concept of BOLA is simple, automating its detection presents significant challenges. Unlike other common vulnerabilities such as SQL injection, cross-site scripting (XSS) and buffer overflow, security testing tools like static application security testing (SAST) and dynamic application security testing (DAST) can’t effectively identify BOLAs. These tools rely on known patterns and behaviors of the vulnerabilities, which do not apply to BOLAs. No automated tool currently exists for detecting BOLAs.
Additionally, no development framework exists that can assist developers in preventing BOLAs. As a result, security teams that need to audit for BOLAs must manually review the application and create custom test cases. Several technical challenges contribute to the difficulty of automating BOLA detection:
Complex authorization mechanisms
Modern API applications often feature complex authorization mechanisms involving multiple roles, resource types and actions. This complexity makes it difficult for auditors to determine which actions a user should be allowed to perform on a specific resource.
Stateful property
Most modern web applications are stateful, meaning each API call can change the application's state and affect the outcomes of other API calls. In other words, the response of calling one API endpoint depends on the execution results of other API endpoints. This complex logic is typically built into the web interfaces that guide end users to properly interact with the applications. However, automatically reverse-engineering the logic from the API specification and tracking the application states is not easy.
Lack of vulnerability indicators
BOLA is a logical error without known patterns that compilers or SAST tools can recognize. At runtime, BOLA doesn't trigger any errors or exhibit specific behavior that reveals the issues. The input and output of a successful exploit typically result in successful requests with status code 200 and they do not contain any suspicious payloads, making it difficult to spot the vulnerabilities.
Context-sensitive inputs
Testing for BOLA involves manipulating input parameters of API endpoints to identify vulnerabilities. This process requires pinpointing parameters that reference sensitive data and supplying the parameters with valid values to run the tests. We rely exclusively on the API specification to understand each endpoint's functionality and parameters, making it challenging to determine if an endpoint may reveal or manipulate sensitive data.After identifying target endpoints and their parameters, the next step is to send requests to these endpoints and observe their behavior. Determining the specific parameter values for testing is difficult because only values mapping to existing objects in the system can trigger BOLAs. Automatically generating such payloads with traditional fuzzing techniques is both challenging and ineffective.
BOLABuster: AI-Assisted BOLA Detection
Given the recent advancements in generative AI (Gen AI) and the challenges of automating BOLA detection, we decided to tackle the problem with AI by developing BOLABuster. The BOLABuster methodology leverages the reasoning capabilities of LLMs to understand an API application and automate BOLA detection tasks that were previously manual and time-consuming.
BOLABuster’s algorithm, as illustrated in Figure 2, requires only the API specification for the target API application as input. BOLABuster generates all test cases from the API specification. BOLABuster currently supports OpenAPI Specification 3, the most widely adopted API specification format.
Figure 2. An overview of BOLABuster’s methodology.
BOLABuster's methodology involves five main stages:
The first stage of our methodology identifies API endpoints that may be susceptible to BOLA. We focus on authenticated endpoints with input parameters that uniquely identify data objects in the system, such as username, email, teamId, invoiceId and visitId. Endpoints with these parameters might be vulnerable to BOLA if the backend fails to validate authorization logic.
AI assists in analyzing each endpoint's functionalities and parameters to determine those that reference to or return sensitive data. Figure 3 illustrates a set of potentially vulnerable endpoints.
Figure 3. API endpoints potentially vulnerable to BOLA.
2. Uncover Endpoint Dependency
This stage analyzes the application logic to uncover dependency relationships between API endpoints. Due to the stateful nature of modern web applications, understanding the prerequisites of an API endpoint before testing is crucial.
For example, to test the checkout APIs of a shopping cart application, items must first be added to the cart. This action requires knowing the itemId and customerId.
We categorize endpoints that output required parameters for other endpoints as Producers and those that ingest these parameters as Consumers, as shown in Figure 4. Each endpoint can function as both a Producer and a Consumer.
AI assists in analyzing each endpoint's functionalities and parameters to determine if one endpoint can output values required by another endpoint's inputs.
Figure 4. An example of Producer endpoints and Consumer endpoints.
3. Generate Execution Path and Test Plan
Using outputs from the previous two stages, this stage constructs a dependency tree for each PVE. Each node represents an API endpoint, and each edge from a parent node to a child node represents a dependency relationship where the parent is the Consumer, and the child is the Producer.The root of each dependency tree is a PVE, and the path from each leaf node to the root represents an execution path that can reach the PVE. We then create a test plan for each execution path, which consists of all the PVE’s execution paths and their API calls. Figure 5 illustrates an example of a dependency tree with four execution paths.
Figure 5. A dependency tree with four execution paths.
4. Create Test Scripts
This stage converts each execution path into an executable bash script using LLMs. Each script makes a sequence of API calls to a target server, beginning with logging in to retrieve authentication tokens and ending with a call to the PVE.Each test script involves at least two authenticated users, with one user attempting to access another user's data. If one user can successfully access or manipulate another user's data, it is an indicator of BOLA.Figure 6 illustrates a high-level example of a BOLA test. The test involves two users, Alice and Bob, who log into a system and receive unique authentication tokens.Alice creates an article and a comment on this article within the system. The identifiers for the article and the comment are then passed to Bob. Bob then attempts to perform an unauthorized action—trying to delete Alice's comment. If the action is successful, it indicates a potential BOLA.
Figure 6. An illustration of testing a PVE with two users.
5. Execute Plans and Analyze
In this stage, BOLABuster executes the test scripts against the target API server, and then it analyzes the responses to determine if the PVEs are vulnerable to BOLA. We automate user registration, user login and token refresh processes to ensure uninterrupted execution of every test plan.
BOLABuster runs the test cases for the same PVE in a specific order to minimize dependencies between them. For instance, we avoid having a test case delete an object that another test case will need.
Essentially, we ensure that all the API calls within an execution path are successful except for the call to the PVE. The outcome of this call should indicate whether the PVE is vulnerable to BOLA.
The ordering algorithm ensures that applications are populated with the necessary data before it makes any access attempts. BOLABuster schedules the test scripts that include actions such as updating or deleting users or resources at the end of the execution sequence to prevent attempts to fetch deleted or modified resources.
The logs and outputs of each test plan are analyzed by AI. When the AI deems an endpoint vulnerable, humans verify the results to assess the impact of the PVE within the application context.
While we automate as many tasks as possible with AI, human validation remains essential. Our experiments show that human feedback consistently enhances AI's accuracy and reliability.
Hunt for BOLAs in the Wild
Our continuous efforts in testing and scrutinizing open-source projects using BOLABuster have led to the identification and reporting of numerous previously unknown BOLA vulnerabilities, some of which can result in critical privilege escalation. This section provides a brief overview of the vulnerabilities we discovered in three open-source projects: Grafana, Harbor and Easy!Appointments.
Grafana (CVE-2024-1313)
Grafana is a popular data visualization and monitoring tool that allows users to pull data from various sources to observe and understand complex datasets. BOLABuster uncovered CVE-2024-1313, which permits low-privileged users outside an organization to delete a dashboard snapshot belonging to another organization using the snapshot key.
Harbor (CVE-2024-22278)
Harbor is a Cloud Native Computing Foundation (CNCF) graduated container registry that hosts container images and offers features such as role-based access control (RBAC), vulnerability scanning and image signing. BOLABuster identified CVE-2024-22278, which enables a user with a Maintainer role to create, update and delete project metadata. These high-risk actions should be restricted to admins, according to the official documentation.
Easy!Appointments is a widely used appointment scheduling and management tool, particularly popular among small businesses. BOLABuster uncovered 15 vulnerable endpoints that allow low-privileged users to bypass authorization controls, leading to potential unauthorized access, data manipulation and full system compromise.
Conclusion
Our research demonstrates the significant potential of AI in revolutionizing vulnerability detection and security research. By leveraging LLMs to automate tasks that were previously manual and time-intensive, we've shown that AI can serve as a reliable assistant. This is true not only for writing code but also for debugging and identifying vulnerabilities.
Although our research is still in its early stages, the implications are profound. The methodology we've developed for BOLA detection can potentially be extended to identify other types of vulnerabilities, opening new avenues for vulnerability research. As AI technology continues to advance, we anticipate that similar approaches will enable a range of security research initiatives that were previously impractical or impossible.
It is also worth noting that this technology can be a double-edged sword. While defenders can use AI to enhance their security measures, adversaries can exploit the same technology to discover zero-day vulnerabilities more quickly and escalate cyberattacks.
The concept of fighting AI with AI has never been more relevant, as we strive to outsmart adversaries with more intelligent and precise AI-driven solutions. It is imperative for the cybersecurity community to remain vigilant and proactive in developing strategies to counteract potential threats posed by AI.
As we use this methodology to identify BOLA vulnerabilities in different products, we responsibly disclose any we find to the appropriate vendors. We also ensure product coverage for vulnerabilities identified, such as those with Grafana, Harbor and Easy!Appointments.
Cortex Xpanse and Cortex XSIAM customers with the ASM module are able to detect all exposed, Grafana, Harbor and Easy!Appointments instances as well as known insecure instances via targeted attack surface rules.
If you think you might have been compromised or have an urgent matter, contact 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
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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.
Unit 42 monitors ransomware and extortion leak sites closely to keep tabs on threat activity. We reviewed compromise announcements from 53 dedicated leak sites in the first half of 2024 and found 1,762 new posts. This averages to approximately 294 posts a month and almost 68 posts a week. Of the 53 ransomware groups whose leak sites we monitored, six of the groups accounted for more than half of the compromises observed.
In February, we reported a 49% increase year-over-year in alleged victims posted on ransomware leak sites. So far, in 2024, comparing the first half of 2023 to the first half of 2024, we see an even further increase of 4.3%. The higher level of activity observed in 2023 was no fluke.
Activity from groups like Ambitious Scorpius (distributors of BlackCat) and Flighty Scorpius (distributors of LockBit) has largely fallen off due to law enforcement operations. However, other threat groups we track such as Spoiled Scorpius (distributors of RansomHub) and Slippery Scorpius (distributors of DragonForce) have joined the fray to fill the void.
Industries most impacted by ransomware were manufacturing (16.4% of observed posts), healthcare (9.6%) and construction (9.4%). Like with manufacturing, healthcare is extremely sensitive to disruptions and downtime.
The U.S. was home to the most victims by far in the first half of 2024. With 917 compromises, the US received 52% of total attacks. In order of impact, the remaining top 10 nations were: Canada, the U.K., Germany, Italy, France, Spain, Brazil, Australia and Belgium.
Newly disclosed vulnerabilities primarily drove ransomware activity as attackers moved to quickly exploit these opportunities. Threat actors regularly target vulnerabilities to access victim networks, elevate privileges and move laterally across breached environments. We’ll list some of the most common vulnerabilities being exploited in 2024.
Palo Alto Networks customers are better protected from ransomware threats through our Network Security solutions, Prisma Cloud offerings and Cortex line of products.
Our team monitors data from dedicated leak sites (DLS) that are often only accessible through the dark web. Throughout our analysis, we compare the first half of 2024 (1H24) to the first half of 2023 (1H23) so that we are accounting for any seasonal fluctuations that can occur due to annual holidays, travel seasons and other recurring events that may impact threat activity.
Key Findings:
4.3% year-over-year increase in compromise announcements
1H24: 1,762 compromise announcements from 53 sites – with the top six groups responsible for more than half of the compromises
1H23: 1,688 compromise announcements
1H24 averaged 68 leak site posts per week
Ransomware announcements continue to increase, despite multiple notable law enforcement disruptions and arrests
The LockBit leak site remains the most active, posting misleading information and old data
In February, we reported a 49% YoY increase in victims posted on leak sites. Our analysis of 2024 so far shows that ransomware groups are maintaining that higher level of activity, even further increasing activity relative to last year.
Figure 1. Month-by-month comparison of ransomware leak site reports.
Figure 1 shows a month-by-month breakout of the numbers, comparing each of the first six months in 2023 with each of the first six months in 2024.
We observed a notable decrease in ransomware leak site reports in June of 2024. Significant decreases in activity on the LockBit and 8Base leak sites largely accounted for this drop.
Threat Group Activity
Leak site data indicates 53 ransomware groups have been active so far in 2024, but the top six ransomware groups account for a little more than half of the total compromises.
Unit 42 tracks threat groups using a naming system that pairs a modifier with a designated constellation per group. Unit 42 maintains a master list of the threat actor groups we track, along with common akas. More details on cybercrime groups are detailed in the below graphic.
As seen in Figure 2, four ransomware groups that were among the six most active in 2023 remained among the most active so far this year. During the first half of 2024, Ambitious Scorpius (distributors of ALPHV/BlackCat) and Chubby Scorpius (distributors of CL0P) dropped out of the top rankings. These groups were displaced by Dark Scorpius (distributors of BlackBasta) and Transforming Scorpius (distributors of Medusa).
Figure 2. Comparing the top six ransomware groups from all of 2023 with the first half of 2024.
Threat actors regularly target vulnerabilities to access victim networks, elevate privileges and move laterally across breached environments. Our threat landscape has been inundated with zero-day and other serious vulnerabilities, giving threat actors a large menu to choose from. According to our most recent Unit 42 Incident Response Report, vulnerabilities became the leading cause of initial access in our cases in 2023, overtaking other common methods such as phishing for the first time.
That trend continues in 2024. Below, we provide some of the more prolific vulnerabilities exploited by ransomware groups in the first half of 2024. We encourage organizations to implement a robust vulnerability management program that accounts for known exploited vulnerabilities, such as those included below.
CVE-2018-13379 - Fortinet SSL VPN
CVE-2024-1709 - ConnectWise ScreenConnect
CVE-2024-1708 - ConnectWise ScreenConnect
CVE-2024-27198 - TeamCity
CVE-2024-4577 - PHP-CGI script engine
CVE-2020-1472 - Netlogon Remote Protocol
CVE-2024-26169 - Microsoft Windows Error Reporting Service
Law Enforcement Takedowns and Disruptions
In the dynamic ransomware landscape, some threat actors have quietly scaled down or completely ceased operations in the first half of 2024. However, some high-profile ransomware groups have disappeared in very public ways.
Law enforcement activity continues to have a wide-reaching impact on the ransomware threat landscape in 2024. Takedowns of prominent ransomware groups, forums and individuals in the first half of the year have created ripples throughout the criminal ecosystem.
Law enforcement highlights from the first half of 2024 include:
February 2024: Law enforcement takedown of the LockBit 3.0 Tor site disrupted its ransomware operations.
March 2024: Affected by a December 2023 law enforcement takedown, the Ambitious Scorpius group finalized an exit scam by selling its ALPHV/BlackCat source code and pretending the FBI seized their site and infrastructure.
While infrastructure seizures by law enforcement are not new, they appear to have been more impactful than previous takedowns. Law enforcement agencies have continued seizing infrastructure and making arrests in 2024, but they have also started targeting organizations affiliated with these ransomware groups. These actions have impacted ransomware groups in different ways.
Takedown, Recovery and Exit Scam: Ambitious Scorpius
By March 2024, Ambitious Scorpius finalized an exit scam by selling its ALPHV/BlackCat source code and pretending the FBI seized their site and infrastructure.
From Takedown to Fraudulent Claims and Possible New Group: Flighty Scorpius
After its February 2024 law enforcement takedown, Flighty Scorpius stood up new infrastructure and began targeting more victims with LockBit 3.0 ransomware.
After restoring its operations, this threat actor posted dubious claims of new victims to its leak site that appeared to be old compromises, exaggerations or outright fabrications. For example, in June 2024, the group claimed to have compromised the US Federal Reserve, but further investigation revealed it was a US-based bank.
On May 7, the National Crime Agency announced a joint international effort had unmasked the leader of Flighty Scorpius and imposed various sanctions on his travel and finances. Known as LockBitSupp, the leader is alleged to be Russian national Dmitry Khoroshev. They also issued arrest warrants for additional affiliates of the group.
Seizures, Arrests, Retirements and Transitions: BreachForums
BreachForums, a criminal forum where threat actors buy and sell stolen data and access to compromised networks, has a history of name changes and takedowns. In May 2024, law enforcement seized BreachForums and arrested its administrator known as Baphomet.
The site came back weeks after the May 2024 takedown under an administrator named ShinyHunters. This ShinyHunters account might be related to the ShinyHunters hacking collective, a group we track as Bling Libra. In June 2024, the user behind the BreachForums’ ShinyHunters account reportedly retired and moved the forum to a new administrator.
Arrest of Affiliate's Key Member and Leaders: Muddled Libra
This group started nearly a decade ago, with the stated aim of targeting and disrupting terrorist organizations like ISIS. They developed GhostLocker RaaS in October 2023 as a means to fund their hacktivism activities.
The group had strict stipulations against targeting healthcare and education. If its ransomware hit victims in those sectors, GhostSec said it stepped in to mitigate the damage. The group's leader Sebastian Dante Alexander noted it favored "...higher scale corporations, which I believe — to an extent — are all greedy."
A member of the Five Families, GhostSec previously coordinated attacks with the Stormous ransomware group, another member of the Five Families. To exit the ransomware scene, GhostSec stated it will transfer GhostLocker's source code (version 3) and the rest of its ransomware operations to Stormous. The group stated that its purpose for the transfer is a clean break without an exit scam. Of note, however, the claimed break involves handing off the ransomware used to extort victims rather than ending its use.
Other Ransomware Groups
Chubby Scorpius, which distributes CL0P ransomware, was the third most active ransomware group in 2023, but its activity fell dramatically in 2024. As of June, this group accounts for less than 0.75% of the total posts in our leak site data.
Other ransomware groups that have not been active on leak sites in 2024 are Bashful Scorpius (distributors of Nokoyawa ransomware), KelvinSecurity, Losttrust, Mushy Scorpius (distributors of Karakurt), Spicy Scorpius (distributors of AvosLocker) and Stumped Scorpius (distributors of NoEscape).
While these groups might have stopped due to the economics of a constantly evolving cybercrime market, additional factors could have influenced these apparent departures. Recent high-profile takedowns of ransomware groups by law enforcement and the legal pursuit of ransomware affiliates and criminal marketplaces like BreachForums could have created an air of mistrust and fear among cybercrime threat actors.
New Kids on the Block
With the departure of various ransomware threat actors, other groups have moved to fill in the void so far in 2024. Here’s a quick look at some of the emerging ransomware groups Unit 42 has been tracking in 2024 that may have hit your radar based on recent events.
Through Unit 42 Incident Response engagements, we have observed a chain of events that indicates this group achieves initial victim access via SocGholish malware delivered through search engine optimization (SEO) poisoning. We assess the group behind SocGholish sold victim access from their infections to Spoiled Scorpius affiliates who deployed the ransomware. We also found evidence that Spoiled Scorpius used its access to victim systems to delete backups from both on-premises and cloud storage.
RansomHub ransomware is written in Golang and C++. Spoiled Scorpius has used distributed denial of service (DDoS) attacks or exploited vulnerabilities such as CVE-2020-1472 to breach its victims. The group also cold calls victims to further exert pressure on them to pay the ransom.
A June 2024 article states a connection between RansomHub and a previous RaaS first observed in 2023 called Knight (Cyclops). Spoiled Scorpius also appears to have links to Ambitious Scorpius.
Slippery Scorpius (Distributors of DragonForce)
Slippery Scorpius is our name for the group behind DragonForce ransomware. This group was first detected in November 2023. Slippery Scorpius gained notoriety in 2024, when this group started extorting victims directly through phone calls and then leaking recorded audio of the conversations.
Like many ransomware groups, Slippery Scorpius performs double-extortion, using its leak site to post the stolen data of its victims who fail to pay. Due to similarities in their code, DragonForce ransomware appears to be based on the leaked source code of LockBit 3.0.
Slippery Scorpius should not be confused with the Malaysian-based hacktivist group named DragonForce that first appeared as early as 2021. This DragonForce hacktivist group does not appear to be related to DragonForce ransomware.
Burning Scorpius (Distributors of LukaLocker)
Originally nicknamed Volcano Demon, the group we track as Burning Scorpius is behind new ransomware named LukaLocker. This ransomware has encrypted both Windows and Linux systems since June 2024.
Unlike other ransomware groups, Burning Scorpius does not host a leak site. Instead, this group contacts executives and IT leadership repeatedly through phone calls with threatening messages to directly extort its victims.
Other New Groups
Alpha ransomware, not to be confused with the ALPHV/BlackCat ransomware group, was active as early as May 2023 and its leak site first appeared in January 2024. Since their site uses MYDATA as its title, some have used MyData as its ransomware name or threat actor identifier. The leak site is reportedly unstable and frequently offline, indicating this group is relatively new, inexperienced and loosely managed. Our leak site data reveals this group has reported nine victims in the first six months of 2024.
The Trisec ransomware group emerged in February 2024 and claims to be affiliated with the Tunisian government. They specifically stated that they “only hires Tunisian blackhats,” and this group has advertised for various positions through its leak site and Telegram channel. The group claims to be both financially motivated and state-sponsored, dabbling in a variety of cybercrime. So far, its victimology appears opportunistic in both industry and region.
DoNex ransomware first appeared in March 2024 and its earliest file samples date back to February. It is a new, financially motivated group that has targeted victims in the US and Europe. Avast has developed a decryptor for victims to restore their files.
The Quilong ransomware group claimed to have compromised three plastic surgery centers in Brazil earlier in 2024, as well as a car dealership. The posted some of the alleged stolen data on their leak site, taunting medical providers with claims that they had failed to protect their patients.
The Blackout ransomware group was first active in late February 2024 and initially claimed on their leak site to have attacked healthcare entities in Canada, France and Germany. Leak site posts from this group show subsequent attacks on a Mexico-based telecommunications company and Croatian targets in the manufacturing industry.
Rebrands
After the exit scam by Ambitious Scorpius, we are keeping an eye out for indicators that this group might be returning by rebranding with a different name. If so, this group will need a strategy to gain back its affiliates, since many have been recruited by other ransomware groups.
Law enforcement actions we previously mentioned against Flighty Scorpius have led to its decline in 2024. Government agencies took down the ransomware's infrastructure and sanctioned its alleged leader in May 2024. We saw only seven verified compromises from its leak site in June, a dramatic drop compared to previous months.
As a way to revive its operations, this group could rebrand as new ransomware. While rebranding remains a possibility for Flighty Scorpius, the previous success of LockBit ransomware has already led other groups to create their own ransomware based on its codebase.
For example, new ransomware named Brain Cipher emerged in June 2024, and research has shown it is based on LockBit 3.0 code. We analyzed a Brain Cypher sample used in an attack against an Indonesian target, and our existing LockBit 3.0 prevention and detection signatures also worked on this sample.
Industries and Regions Impacted
While ransomware targeting remains largely opportunistic, industries like manufacturing remain highly susceptible to these types of attacks. As in 2023, manufacturing continues to be the sector most impacted by ransomware. At 289 compromises, 16.4% of all ransomware attacks during 1H24 affected manufacturing organizations.
Healthcare was the second most impacted industry in 1H24, rising from sixth place in 2023. Like with manufacturing, healthcare is very sensitive to disruptions. It is also riddled with a plethora of technologies and devices that can be hard to catalog and protect.
Construction is the third most impacted industry in 1H24. About 9.4% of all compromises affected organizations involved in construction.
Figure 3 shows a bar graph representing the industries most affected by ransomware attacks in the first half of 2024.
Figure 3. Industries affected by ransomware in the first half of 2024.
Unsurprisingly, the U.S. was home to the most victims by far in the first half of 2024. With 917 compromises, organizations in the U.S. received 52% of total attacks. The remaining top 10 nations where organizations were affected, in order of impact, were Canada, the U.K., Germany, Italy, France, Spain, Brazil, Australia and Belgium. Below, Figure 4 shows the breakdown.
Figure 4. Nations where organizations were affected by ransomware in the first half of 2024.
The Data and Where It Comes From
Analysis and information for this article is primarily based on publicly reported information and data from ransomware leak sites.
Our team monitors data from these sites that are often accessible through the dark web. We reviewed and compiled compromise announcements from 53 sites in the first half of 2024 to identify trends in the ransomware landscape. We also leveraged our firsthand experience with these groups through Unit 42 Incident Response engagements to develop our understanding of their tools and techniques within victim networks.
Since most ransomware groups now commonly use leak sites to pressure victims, researchers often use this data to identify trends and levels of ransomware activity for threat actors. However, defenders and researchers should use leak site data with caution as it might not always provide an accurate picture.
Threat actors will often omit victims who pay quickly from a group’s leak site. Additionally, threat actors will frequently misrepresent the source of the data on the group’s leak site.
Despite these drawbacks, this data provides valuable information on trends, newcomers and threat groups that have disappeared from the threat landscape.
Conclusion
This article reviewed trends and significant events for ransomware in the first half of 2024. We reported trends from compromises reported by ransomware leak site posts.
While leak site data indicates that manufacturing remained the most affected sector, healthcare jumped to second place, with high-profile attacks grabbing headlines during the first six months of 2024. Overall, the majority of organizations impacted by ransomware were based in the U.S.
Even with law enforcement's best efforts to dismantle and stamp out the most prolific ransomware threat actors, plenty of highly skilled and motivated groups are waiting, willing to step in and fill the void. The success and subsequent explosion of ransomware in the past few years have led to an ever-increasing pool of individuals and groups gambling for their chance at fame and fortune.
Palo Alto Networks customers are better protected from ransomware threats through Network Security solutions, Prisma Cloud offerings and Cortex line of products.
Advanced Threat Prevention can block ransomware threats at both the network and application layers, including port scans, buffer overflows and remote code execution.
Our Cortex protections include Cortex Xpanse, which detects vulnerable services exposed directly to the internet that might be exploitable and infected by ransomware. Through Cortex XDR and XSIAM, all known ransomware samples are prevented by the XDR agent out of the box using the following endpoint protection modules:
The Anti-Ransomware module to prevent encryption behaviors on systems running Microsoft Windows or macOS.
The Local Analysis module will detect ransomware binaries on Windows, macOS and Linux.
XDR also includes protection capabilities like Behavioral Threat Protection (BTP) which helps prevent ransomware activity on Windows, macOS and Linux.
Palo Alto Networks’ Cloud Security Agent (CSA) leverages XSIAM to provide cloud based detection and monitoring capabilities to both Cortex and Prisma Cloud cloud agents.
We frequently update machine learning models and analysis techniques in Advanced WildFire with information discovered from our day-to-day research on ransomware.
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
Japan: +81.50.1790.0200
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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.
Diplomatic-car-for-sale phishing lure themes have been used by Russian threat actors for years. These lures tend to resonate with diplomats and get targets to click on the malicious content.
Unit 42 has previously observed other threat groups using this tactic. For example, in 2023, a different Russian threat group, Cloaked Ursa, repurposed an advertisement for a BMW for sale to target diplomatic missions within Ukraine. This campaign is not directly connected to the Fighting Ursa campaign described here. However, the similarity in tactics points to known behaviors of Fighting Ursa. The Fighting Ursa group is known for repurposing successful tactics – even continuously exploiting known vulnerabilities for 20 months after their cover was already blown.
The details of the March 2024 campaign, which we attribute to Fighting Ursa with a medium to high level of confidence, indicate the group targeted diplomats and relied on public and free services to host various stages of the attack. This article examines the infection chain from the attack.
The URL kicking off this infection chain was hosted by a legitimate service named Webhook.site, and it was submitted to VirusTotal on March 14, 2024. Webhook.site is a service for legitimate development projects, and it allows its users to create randomized URLs for various purposes like custom automation based on the characteristics of visitors to the URLs.
In this case, Fighting Ursa abused Webhook.site to craft a URL that returned a malicious HTML page. Figure 1 below shows the HTML returned from the webhook[.]site URL.
Figure 1. HTML code used in the attack hosted on the Webhook.site service.
The HTML shown above in Figure 1 has multiple elements that attempt to automate the attack. First, it checks if the visiting computer is Windows-based. If not, it redirects to a decoy image on a URL hosted by another legitimate provider, which is a free service named ImgBB. As the final payload is Windows based, this operating system check is probably an effort to ensure that further actions taken in the attack are only taken for Windows visitors. The HTML then creates a ZIP archive from Base64 text in the HTML, offers it for download and attempts to open it with the JavaScript click() function.
Figure 2 below shows the decoy image advertising a car for sale, specifically an Audi Q7 Quattro SUV. This fake advertisement is titled “Diplomatic Car For Sale.”
The image provides different views of the vehicle. The image also contains contact details that are likely fake, as well as a phone number based in Romania. Finally, the image also lists the point of contact as the Southeast European Law Enforcement Center, possibly to lend this fake advertisement more credibility.
Figure 2. Diplomatic car for sale lure hosted on ImgBB.
Downloaded Malware
The downloaded ZIP archive is saved as IMG-387470302099.zip and contains three files listed below in Table 1.
File Size
Modified Date and Time
File Name
918,528 bytes
2009-07-13 18:38 UTC
IMG-387470302099.jpg.exe
9,728 bytes
2024-03-13 00:37 UTC
WindowsCodecs.dll
922 bytes
2024-03-13 00:37 UTC
zqtxmo.bat
Table 1. Contents of the downloaded file IMG-387470302099.zip.
Table 1 above shows that the first file IMG-387470302099.jpg.exe has a double file extension of .jpg.exe. Windows hosts with a default configuration hide file extensions, so the .jpg.exe file extension only shows as .jpg in the file name. This is a common tactic used by threat actors to trick potential victims into double-clicking the file, in this case believing it will open a car for sale advertisement.
The file named IMG-387470302099.jpg.exe is a copy of the legitimate Windows calculator file calc.exe. This file is used to sideload the included DLL file WindowsCodecs.dll, which is a component of the HeadLace backdoor.
HeadLace is modular malware that executes in stages. This stage-based loading is probably designed to prevent detection and minimize the malware's exposure to analysts. The DLL file contains a function shown below in Figure 3.
Figure 3. Code in WindowsCodecs.dll file to run a file named zqtxmo.bat.
This function is solely meant to execute the last file within the ZIP archive, zqtxmo.bat. Figure 4 below shows the content of zqtxmo.bat.
Figure 4. Contents of the zqtxmo.bat batch file.
This batch file starts a process for Microsoft Edge (start msedge) to run content passed as Base64-encoded text. As shown above in Figure 4, the decoded text is a hidden iframe that retrieves content from a different Webhook.site URL.
The batch file saves content from this second Webhook.site URL as IMG387470302099.jpg in the user's downloads directory. It then moves the downloaded file into the %programdata% directory and changes the file extension from .jpg to .cmd. Finally, the batch file executes IMG387470302099.cmd, then deletes itself as a way to remove any obvious trace of malicious activity.
Attribution
We attribute this activity with a medium to high level of confidence to Fighting Ursa based on the tactics, techniques and procedures (TTPs), characteristics of the attack infrastructure and the malware family attackers used.
This attack relies heavily on public and free services to host lures and various stages of the attack. Documentation by IBM, Proofpoint, Recorded Future and others reveal that while the infrastructure used by Fighting Ursa varies for different attack campaigns, the group frequently relies on these freely available services. Furthermore, the tactics from this campaign fit with previously documented Fighting Ursa campaigns, and the HeadLace backdoor is exclusive to this threat actor.
Conclusion
Fighting Ursa is a motivated threat actor. The infrastructure the group uses has constantly changed and evolved, as noted in a recent report from Recorded Future. Other industry reports have also shown various lures this actor uses in attempts to drop HeadLace malware.
We assess that Fighting Ursa will continue to use legitimate web services in its attack infrastructure. To defend against these attacks, defenders should limit access to these or similar hosting services as necessary. If possible, organizations should scrutinize the use of these free services to identify possible attack vectors.
Palo Alto Networks Protection and Mitigation
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
Cortex XDR detects the attack chain described above, among other protections in the Cortex XDR platform.
Cortex XSIAM and XSOAR have released a response pack and playbook for automatically detecting the Fighting Ursa threat actor. This playbook downloads the APT28 detection rules and performs extraction, enrichment, and tagging of indicators. It executes our generic Threat Hunting sub-playbook and subsequently provides analysts with recommended workarounds, empowering them to decide the best course of action with the enriched indicators.
Advanced URL Filtering identifies known URLs associated with this activity as malicious.
The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the IoCs shared in this research.
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
Japan: +81.50.1790.0200
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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.
Indicators of Compromise
HTML page hosted on webhook site with decoy image and payload zip file:
In a recent audit of open-source web applications, threat researchers from Unit 42 have identified a broken object-level authorization (BOLA) vulnerability that impacts Harbor versions prior to 2.9.5. Harbor is a widely used cloud-native container registry that plays a role in cloud environments by hosting container images and providing features such as role-based access control (RBAC), vulnerability scanning and image signing. It is an open-source CNCF Graduated project with over 22,600 stars and 1.8 million downloads. The vulnerability we identified is tracked as CVE-2024-22278, with a CVSS score of 6.4.
We found the vulnerability as part of our development of an automated BOLA detection tool leveraging generative AI, part of a larger effort to explore how AI can enhance security capabilities.
Exploiting this vulnerability allows someone using a Maintainer role to create, update and delete a project's metadata. These are privileged actions that are forbidden in the Harbor UI and prohibited according to the official documentation. Unauthorized alterations to metadata pose significant risks, including data exposure, compromise of content integrity and circumvention of vulnerability scanning mechanisms.
To mitigate these risks, organizations should update Harbor to version v2.9.5, v2.10.3 or v2.11.0 immediately. This update addresses the identified vulnerability and helps secure the application against potential attacks. Harbor has published more information in their advisory on the issue.
Cortex Xpanse and Cortex XSIAM customers with the ASM module are able to detect all publicly exposed Harbor instances through a targeted attack surface rule.
BOLA, also known as insecure direct object references (IDOR), are a prevalent type of vulnerability in modern APIs and web applications. BOLA vulnerabilities are ranked as the number one risk in the OWASP API top 10 and the fourth most reported vulnerability type in the HackerOne Global Top 10.
As explained in our previous research on BOLA, BOLA occurs when an application fails to properly check if a user has the necessary permissions to access, modify or delete an object. The "object" in the BOLA acronym refers to various types of data within a system. These objects include messages, photos, trips, user profiles and invoices.
Attackers can exploit BOLA vulnerabilities in API endpoints by altering object identifiers within authentication requests. Such manipulations can lead to unauthorized access of user data, resulting in data leaks, data manipulation or even complete account takeovers.
As discussed in another article disclosing BOLA vulnerabilities, testing for BOLA is typically done manually. In our research using AI to automate detection, we’ve found and responsibly disclosed BOLA vulnerabilities in several open-source projects.
Overview of Harbor
Harbor is a popular container registry that uses policies and role-based access control (RBAC) to manage and secure container images. User actions are determined by assigned roles, and only an administrative role can perform critical actions such as project configurations and vulnerability scanning.
A project in Harbor contains a collection of repositories, where each repository can hold multiple versions of container images. To enforce access control, Harbor applies RBAC to its projects, so that only users with the appropriate roles can perform certain operations.
When considering project access, we must first understand the two types of projects as defined by Harbor:
Public: In this type of project, any user can pull images to share repositories with other users.
Private: In this type of project, only users who are members of the project can pull images.
For individual projects, Harbor defines five project-level roles with distinct permissions. Each role is tailored to facilitate specific aspects of the project.
Limited Guest: This role can pull images but not push, it cannot see logs or other project members.
Guest: This role is read-only access, it can pull and retag images but not push.
Developer: This role is read and write access within a project.
Maintainer: This role has elevated permissions, including the ability to scan images, view replication jobs, and delete images and helm charts.
ProjectAdmin: This role has full read-write and management privileges, such as adding or removing members and initiating vulnerability scans.
Explanation of Harbor Vulnerability, CVE-2024-22278
This BOLA in Harbor is based on a project's metadata.
In Harbor's source code, this metadata refers to specific information and settings associated with a project. These settings control crucial configurations of a project, such as making a project private or public, allowing only verified images to be deployed and enforcing vulnerability scanning on pushed images.
According to Harbor's documentation, only the ProjectAdmin role is permitted to modify these configuration settings.
We tested this in Harbor to confirm, but upon assessing the Harbor APIs, we observed inconsistent behavior between the Harbor web UI and APIs.
We first confirmed that a user with a Maintainer role cannot create, update or delete a project's configuration metadata through the web UI. Figure 1 shows the Harbor UI console from a Maintenance login. Note the five checkable boxes in Figure 1 are all gray. Even if a user checks or unchecks these boxes, these settings will not change.
Figure 1. For a Maintenance login, configuration checkboxes in the Harbor UI console are all gray.
Figure 2 shows the same configuration settings in the Harbor UI console with a ProjectAdmin role login. In this case, the checkable boxes are not gray, which provides a visual indication that these settings can be changed.
Figure 2. For a ProjectAdmin login, configuration checkboxes in the Harbor UI console are not gray, so these settings can be changed.
However, when checking the Maintainer role using Harbor's API, we noticed that our Maintainer role could alter a project's metadata using valid {meta_name} values as specified in the source code. These requests were:
PUT /projects/{project_name_or_id}/metadatas/{meta_name}
POST /projects/{project_name_or_id}/metadatas/{meta_name}
We confirmed the above requests using a Maintainer role though the API could indeed alter a project's metadata. These are functions that should only be done in a ProjectAdmin role.
This vulnerability allows a user with a Maintainer role to perform the tasks that only a ProjectAdmin should be able to do.
Vulnerability Impact
Although a Maintainer role has high privileges and can potentially harm the project in various ways if acting maliciously, this BOLA vulnerability extends those Maintainer role privileges even further. This allows the Maintainer to make a project public, deploy unverified images and bypass mandatory vulnerability scanning protocols.
If an attacker gains access to a Harbor system through a Maintainer role, this BOLA allows the attacker to make ProjectAdmin changes. These changes could include deploying vulnerable or malicious images, exposing sensitive project data and further compromising the project's integrity and security posture.
Figure 3 shows us using Postman for an API call to change a private project to public. We did this from an account with Maintenance-level access. We confirmed this API call from a maintenance account did in fact change a project's permissions from private to public.
Figure 3. Making a project public by modifying its metadata using an API through Postman from a Maintenance account.
This issue qualifies as a BOLA vulnerability because it permits unauthorized manipulation of specific objects, such as project metadata configurations, due to inadequate enforcement of object-level authorization checks in the application.
Fixes and Mitigations
Harbor has released a fix to CVE-2024-22278 and suggested users upgrade to version v2.9.5, v2.10.3 or v2.11.0 to mitigate the BOLA risk.
Disclosure Process
April 24, 2024: We reported the vulnerability to Harbor’s maintainers through email
May 6, 2024: Harbor’s maintainer confirmed the vulnerability
July 02, 2024: CVE-2024-22278 has been reserved
July 31, 2024: Harbor released versions v2.9.5, v2.10.3 and v2.11.0 that all patched the vulnerability
Conclusion
This post details a BOLA vulnerability Unit 42 researchers discovered in Harbor using a new automatic methodology that leverages AI. As API use increases exponentially, so does the prevalence of API vulnerabilities and BOLA vulnerabilities in particular. Due to the ease of exploitation and potential impacts of this vulnerability, we encourage affected organizations to update to the patched version as soon as possible.
Researchers at Palo Alto Networks are actively developing new technology that leverages AI to automate the detection of BOLA vulnerabilities. Although this initiative is still in its early stages, we’re making significant progress toward creating more scalable, efficient and effective detection solutions.
To mitigate the risks related to this vulnerability, organizations should update Harbor to version v2.9.5, v2.10.3 or v2.11.0 immediately. This update addresses the identified vulnerability and helps secure the application against potential attacks.
Cortex Xpanse and Cortex XSIAM customers with the ASM module are able to detect all publicly exposed Harbor instances through a targeted attack surface rule.
If you think you might have been compromised or have an urgent matter, contact 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
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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 this post, we explore the evolution of domain registration and network attacks associated with terms related to generative AI (GenAI). These trends are strongly correlated with the key milestones and developments in GenAI such as the launch of ChatGPT and its integration into the Bing search engine – and the buzz of interest around these events.
We analyzed domains registered with wording that appears related to GenAI. In the process, we uncovered insights regarding the characteristics of suspicious activity seeking to capitalize on the trend, including textual patterns and the volume of traffic these domains receive. To provide a comprehensive understanding of the underlying cyberthreats, we conducted several case studies detailing different attack types, including the delivery of potentially unwanted programs, the distribution of spam and the use of monetized domain parking.
Since ChatGPT’s launch in November 2022, GenAI has consistently attracted the public’s interest, and we have been actively tracking the related cyber threats since then, following how scammers have sought to take advantage of people searching for information about GenAI. Throughout 2023 and 2024, the related discussion expanded and new products emerged, and the network security team at Palo Alto Networks witnessed a surge of network abuses that leveraged the popularity of this hot topic. This trend highlighted the critical need for enhanced focus and resources dedicated to detecting and mitigating GenAI-related scams.
Palo Alto Networks customers are better protected against various network threats seeking to leverage terminology associated with GenAI through Cloud-Delivered Security Services such as Advanced DNS Security, Advanced URL Filtering and Advanced WildFire. If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.
When adversaries take advantage of trending topics, the initial strategy often involves registering domains that incorporate relevant keywords. Therefore, our analysis started with retrieving historical newly registered domains (NRD) that contain GenAI keywords such as chatgpt, prompt and sora.
Palo Alto Networks detects over 200,000 daily NRD from zone files, WHOIS databases and passive DNS. We retrieved around 225 GenAI-related domains registered every day since November 2022.
Figure 1 presents the daily count of domain registrations leveraging GenAI-related keywords, along with the number identified as suspicious. We labeled the domains in the following categories as suspicious:
The domain registration trend is clearly correlated to the fluctuating popularity of the topic, with data peaks aligning with major ChatGPT milestones. Following Microsoft's announcement of ChatGPT integration with Bing on Feb. 7, 2023, we observed a surge in the number of new domains where many of them contain both trademarks (e.g., msftchatgpt[.]com).
Another significant spike occurred on March 14, 2023, coinciding with the official release of GPT-4. The next peak corresponds to the announcement of new GPTs on Nov. 6, 2023, during which numerous related domains, like gptsotre[.]com, were registered.
The breaking news about Sora, an upcoming text-to-video generation model developed by OpenAI, attracted significant public attention for GenAI after Feb. 15, 2024. Specifically, there were about 760 GenAI-related domains registered every day in the following week.
The average rate of suspicious GenAI-related domains is 28.75%, which is 22 times higher than the rate for general NRDs, based on our previous research. This shows that GenAI is a highly abused topic and emphasizes the importance of continuously monitoring related network threats.
We further analyzed the textual patterns for these interesting new domains. We split them based on the embedded keywords to calculate the number of domains and suspicious rate for each keyword.
Figure 2 plots the statistics for the most frequently used keywords. Remarkably, over 72% of the domains associate themselves with popular GenAI applications by including keywords like gpt or chatgpt.
Figure 2. Top 10 most common GenAI-related keywords contained in NRDs.
The most abused keyword is gpt, whose suspicious rate is 76%. This word, though not exclusively related to the GenAI topic, demonstrates a significant correlation with it. After filtering out domains unrelated to GenAI, this term was rarely used for domain creation prior to 2023, while its popularity surged along with the GenAI trend.
As interest in GenAI grows and more people seek to become experts in its use, prompt engineering emerges as a hot topic. We also observed that prompt frequently coexists with gpt and engineering in domain names. Our findings suggest that people must exercise caution when visiting websites offering tutorials on prompt engineering, as a significant percentage of them are shady.
GenAI-related DNS Traffic
While the number of domain registrations indicates the level of interest from both developers and attackers, the traffic to these domains provides insights into their actual impact on the public. We cross-checked the GenAI-related domains with our passive DNS dataset to calculate their popularity and track their traffic trends.
We obtained several insights about GenAI network traffic from the DNS requests volume for the related NRDs.
Figure 3 presents a general upward trend for GenAI-related traffic. There was a significant growth phase from January-September 2023. After this surge, the GenAI-related DNS traffic plateaued at a high level.
Among all traffic toward these NRDs, 35% was directed toward suspicious domains.
This suspicious traffic generally mirrored the total traffic trend but with two spikes in March and October 2023.
Since December 2023, the volume of suspicious traffic has remained elevated.
The overall traffic distribution among different domains presented a pronounced long-tailed pattern, showing that just a few major players garnered the most attention in GenAI.
The well-known legitimate GenAI services, including ChatGPT (OpenAI), Midjourney and Stable Diffusion (Stability AI), accounted for 92.37% of all GenAI-related traffic.
The top 15 most visited domains got more than 74% of the traffic.
The top 50 domains got over 91% of the traffic.
Figure 3. Normalized DNS traffic for GenAI-related NRDs.
Figure 4 plots the traffic volume for the most popular GenAI-related domains. OpenAI’s domains take the top two positions, significantly outpacing other services. Two of these domains are suspicious—marked in red in the chart—and have attracted considerable traffic, placing them among the top 15. Among the 50 most popular domains, 44% are identified as suspicious and these 22 domains account for 16% of the total GenAI-related traffic.
Figure 4. Top 15 most popular GenAI-related domains.
Network Abuse Case Study
In this section, we will illustrate different types of network abuses that are behind the GenAI URLs. These examples show how adversaries take advantage of the public interest in GenAI and related products.
Potentially Unwanted Program Delivery
Well-known GenAI services are not available in every corner of the world. For example, ChatGPT is not accessible in China. This obstacle creates opportunities for threat actors to exploit the public interest in GenAI in these regions. We identified a campaign targeting Chinese users with potentially unwanted programs (PUP).
This campaign involves 13 domains registered between October 2023 and February 2024. Each domain contains the keyword chatgpt and follows a similar naming pattern:
Chatgptproapp[.]com
Chatgptios[.]cn
Chatgpt005[.]cn
Chatgptapp000[.]cn
Chatgptapp999[.]cn
Chatgpt000[.]cn
Chatgpt008[.]cn
Chatgpt178[.]cn
Chatgpt009[.]cn
Chatgpt0002[.]cn
Chatgpt188[.]cn
Chatgptapp888[.]cn
Chatgpt138[.]cn
Chatgpt006[.]cn
All domains are hosted by name servers from dnspod[.]net and share the same common IP address in Hong Kong.
This campaign directs visitors to a proxy service for ChatGPT. As shown in Figure 5, users are allowed two free interactions with ChatGPT. After that, the website asks the user to register and purchase more credits to continue.
Figure 5. Chinese ChatGPT proxy website.
Figure 6 shows the website's prompt to download its application, which is compatible with Android, PC and iOS platforms. The Android APK with the SHA256 bad2294523c7abd42c3184d1e513bf851cb649a4acd9543cdf5d54d21f52c937 requests access to sensitive data on the victim device, indicating its potentially harmful nature.
Figure 6. PUP delivery page.
Spam Distribution
In addition to registering new domains, adversaries also exploited the GenAI trend by embedding related keywords into their URLs. One of the examples is a spamming campaign that used chatgpt or ai to generate subdomains, combining them with paths such as the following:
exclusive-product
product
invite
exclusive
We identified the following five domains from this campaign:
Ketlenpack[.]online
Oha-chatbot[.]xyz
Janoub-hightech[.]com
Internationaljobsite[.]com
33115c[.]com
Adversaries used ChatGPT-related URLs to spread spam messages. They leveraged different websites with comment sections to insert suspicious URLs. Figure 7 shows these comments lure visitors to click on their links with promises of passive income derived from ChatGPT.
Figure 7. ChatGPT-related spamming comment.
Monetized Domain Parking
Monetized domain parking is a convenient method adversaries use to benefit from trending topics. Adversaries register domains that are likely to attract a lot of traffic and link these to monetized parking platforms, converting the visit volume into revenue.
One such GenAI-related parking campaign we have identified involved nine domains:
Bardassai[.]com
Gemini-addons[.]com
Gemini-agents[.]com
Gemini-agi[.]com
Gemini-super-intelligence[.]com
Gemini-superintelligence[.]com
Geminisuperintelligence[.]com
Gpt-vision[.]com
My-gpt-cpa[.]com
All these domains lead traffic to monetization services at sedoparking[.]com and sedodna[.]com through different types of redirections, including server-side HTTP redirects and client-side HTML redirections. These redirection chains took visitors to various shady landing pages.
Figure 8 shows one such landing page from the campaign. This phishing page asks permission to install what is purported to be an ad-blocking extension but is, in fact, an ad injector.
Each visit to the same URL does not go through the same redirection chain. Sometimes it will point the visitors to legitimate websites for cloaking. However, we have observed various suspicious landing pages that contain malware, phishing and adult content.
Figure 8. Phishing landing page of monetized domain parking campaign.
Conclusion
By analyzing domains and URLs associated with public interest in GenAI, we observed that GenAI-related domain registrations and corresponding traffic volume align closely with real-world news, revealing that adversaries keenly follow and exploit trending topics. The high suspicious percentage of these new domains underscores the necessity for proactive detection against network attacks leveraging GenAI-related keywords.
Some of these domains rank among the most visited websites. Furthermore, we present detailed case studies on a variety of cyberthreats, demonstrating how adversaries leverage GenAI for distributing PUP and spam, or to directly monetize web traffic.
We closely monitor trending topics to proactively detect related cyberthreats. Palo Alto Networks customers are better protected from the threats discussed in this article through the following products:
Palo Alto Networks has been actively researching and developing security capabilities using AI. In an effort to audit web applications for Broken Object-Level Authorization (BOLA) vulnerabilities, Unit 42 researchers developed an automated BOLA detection tool leveraging GenAI.
In 2023, we used our tool to test an open-source project, Easy!Appointments, and found 15 BOLA vulnerabilities. We notified the vendor, who has since patched the vulnerabilities. The number of issues we found highlights the prevalence of BOLA vulnerabilities in API applications and underscores the importance of continuously scrutinizing software for these potentially severe issues.
Easy!Appointments is a popular tool used for scheduling and managing appointments, as well as synchronizing data with widely used calendar services. The vulnerabilities we discovered allow low-privileged and logged in users (such as customers) to view and manipulate appointments created by more privileged users (such as providers and admins).
The vulnerabilities we discovered, tracked as CVE-2023-3285 to CVE-2023-3290 and CVE-2023-38047 to CVE-2023-38055, all affect different API endpoints. They have been assigned CVSS scores ranging from 5 to 9.9, with seven vulnerabilities scoring 9.9.
Upon discovering these vulnerabilities, we collaborated closely with the maintainers to patch all the issues in the latest version 1.5.0. To mitigate the risks, organizations are advised to upgrade to Easy!Appointments version 1.5.0 or later immediately. Please reach out to info@easyappointments.org for more information on updating to the latest version.
Cortex Xpanse and Cortex XSIAM customers with the ASM module are able to detect all exposed Easy!Appointments instances as well as known insecure instances via targeted attack surface rules.
Broken object-level authorization (BOLA), also known as insecure direct object references (IDOR), is a prevalent type of vulnerability in modern APIs and web applications. It is ranked as the top risk in the OWASP API top 10 and the fourth most reported vulnerability type in the HackerOne Global Top 10.
As explained in another recent article on a BOLA vulnerability, BOLA occurs when an application fails to properly check if a user has the necessary permissions to access, modify or delete an object. The term object in this context refers to various types of data within a system, examples of which include messages, photos, trips, user profiles and invoices.
Attackers can exploit BOLA vulnerabilities in API endpoints by altering object identifiers within requests. Such manipulations can lead to unauthorized access to user data, resulting in data leaks, manipulation of data or even complete account takeovers.
BOLA Detection
While manually looking for BOLAs is generally straightforward, automating this process is challenging. Testing for BOLA has historically been performed manually due to the complexity of web applications' workflow and business logic, along with the stateful nature of modern web applications.
Researchers at Palo Alto Networks are actively developing new technology that leverages AI to automate the detection of BOLA vulnerabilities. We're internally using these AI detection operations to allow us to test new advancements daily.
Easy!Appointments is an open-source web application designed for scheduling appointments. It is highly customizable, allowing integration with existing websites and synchronization with Google Calendar and CalDAV servers.
The software is free and supports commercial use, targeting professional users through premium services. It is popular among large organizations and a committed developer community maintains it.
Easy!Appointments features a permissions system for different user roles. Every role except admin is considered low-privileged.
Customer: This role can only access the booking page to manage their appointments.
Provider: This role manages appointments and customer information but cannot handle administrative tasks like managing services or system settings.
Secretary: This role is similar to providers but doesn't serve appointments directly. It manages schedules for assigned providers without accessing administrative settings.
Admin: This role has full access to all system resources and actions, including service definitions, user management and system settings.
Explanation of Vulnerabilities
This section outlines the 15 vulnerable API paths uncovered in our research. Most of these vulnerabilities are exploitable through APIs, not UI consoles. Each path may be vulnerable to one or multiple HTTP methods, such as GET, POST, PUT and DELETE.
The lack of sufficient checking and validation of caller identities at the backend makes most API endpoints vulnerable to BOLA. Among the 15 CVEs identified, nine are rated as Critical severity (CVSS 9.0 or higher), five as High severity (CVSS between 7.0-9.0), and one as Medium severity (CVSS between 4.0-6.9).
CVE-2023-3287 (CVSS=9.9): A BOLA vulnerability in POST /admins allows a low-privileged user to create a high-privileged user (admin) in the system. This results in privilege escalation.
CVE-2023-38048 (CVSS=9.9): A BOLA vulnerability in GET, PUT, DELETE /providers/{providerId} allows a low-privileged user to fetch, modify or delete a privileged user (provider). This results in unauthorized access and unauthorized data manipulation.
CVE-2023-38049 (CVSS=9.9): A BOLA vulnerability in GET, PUT, DELETE /appointments/{appointmentId} allows a low-privileged user to fetch, modify or delete an appointment of any user (including admin). This results in unauthorized access and unauthorized data manipulation.
CVE-2023-38050 (CVSS=9.1): A BOLA vulnerability in GET, PUT, DELETE /webhooks/{webhookId} allows a low-privileged user to fetch, modify or delete a webhook of any user (including admin). This results in unauthorized access and unauthorized data manipulation.
CVE-2023-38051 (CVSS=9.9): A BOLA vulnerability in GET, PUT, DELETE /secretaries/{secretaryId} allows a low-privileged user to fetch, modify or delete a low-privileged user (secretary). This results in unauthorized access and unauthorized data manipulation.
CVE-2023-38052 (CVSS=9.9): A BOLA vulnerability in GET, PUT, DELETE /admins/{adminId} allows a low-privileged user to fetch, modify or delete a high-privileged user (admin). This results in unauthorized access and unauthorized data manipulation.
CVE-2023-38053 (CVSS=9.9): A BOLA vulnerability in GET, PUT, DELETE /settings/{settingName} allows a low-privileged user to fetch, modify or delete the settings of any user (including admin). This results in unauthorized access and unauthorized data manipulation.
CVE-2023-38054 (CVSS=9.9): A BOLA vulnerability in GET, PUT, DELETE /customers/{customerId} allows a low-privileged user to fetch, modify or delete a low-privileged user (customer). This results in unauthorized access and unauthorized data manipulation.
CVE-2023-38055 (CVSS=9.6): A BOLA vulnerability in GET, PUT, DELETE /services/{serviceId} allows a low-privileged user to fetch, modify or delete the services of any user (including admin). This results in unauthorized access and unauthorized data manipulation.
CVE-2023-3285 (CVSS=7.7): A BOLA vulnerability in POST /appointments allows a low-privileged user to create an appointment for any user in the system (including admin). This results in unauthorized data manipulation.
CVE-2023-3286 (CVSS=7.7): A BOLA vulnerability in POST /secretaries allows a low-privileged user to create a low-privileged user (secretary) in the system. This results in unauthorized data manipulation.
CVE-2023-3288 (CVSS=7.7): A BOLA vulnerability in POST /providers allows a low-privileged user to create a privileged user (provider) in the system. This results in privilege escalation.
CVE-2023-3289 (CVSS=7.7): A BOLA vulnerability in POST /services allows a low-privileged user to create a service for any user in the system (including admin). This results in unauthorized data manipulation.
CVE-2023-38047 (CVSS=8.5): A BOLA vulnerability in GET, PUT, DELETE /categories/{categoryId} allows a low-privileged user to fetch, modify or delete the category of any user (including admin). This results in unauthorized access and unauthorized data manipulation.
CVE-2023-3290 (CVSS=5): A BOLA vulnerability in POST /customers allows a low-privileged user to create a low-privileged user (customer) in the system. This results in unauthorized data manipulation.
CVE-2023-38049
To illustrate the issue that underpins the vulnerabilities we identified, let’s look at CVE-2023-38049 as an example. A user with a secretary role could exploit the vulnerability to modify an arbitrary user's appointment. According to the official documentation, the secretary role is intended to perform organizational tasks only for their assigned providers.
In particular, a malicious secretary could perform GET, PUT and DELETE operations on the API path /appointments/{appointmentId} to modify another user's appointment. It is important to note that these operations cannot be performed by a secretary through the user interface. They can only be executed via API calls. This results in a discrepancy between the API and UI behavior.
We created an admin user and used it to create an appointment with appointment_id equal to 1. Figure 1 shows the response of GET/appointments/1 request. The response includes information such as the following:
Appointment ID
Start and end times
Location
Customer
Provider
Service
Hash
This data is sensitive and should only be accessible to the user who created the meeting.
Figure 1. An admin’s appointment data.
We then used a low-privileged secretary user to manipulate the appointment created by the admin user through the vulnerable endpoint, PUT /appointments/{appointmentId}. Figure 2 shows the HTTP requests sent with the secretary user.
Figure 2. A low-privileged user manipulating admin’s appointment.
Vulnerability Impact
Figure 3 shows the appointment being modified with different start and end times, location, and identities of the provider and customer. Despite these changes, the appointment hash remained unchanged, giving the false impression that the original appointment was not altered.
Figure 3. The “new,” manipulated appointment.
Disclosure Process
Aug. 23, 2023: We reported the vulnerabilities to Easy!Appointments’ maintainers through email
Oct. 9, 2023: Easy!Appointments’ maintainer confirmed the vulnerabilities
April 24, 2024: Unit 42 researchers sent a follow-up email to the maintainer to inquire about the patch release timeline
May 6, 2024: 15 CVEs were reserved
May 14, 2024: Easy!Appointments released version 1.5.0-alpha.1 (develop) that patched all the vulnerabilities
July 1, 2024: Easy!Appointments released version 1.5.0-beta.1 (develop) that patched all the vulnerabilities
July 7, 2024: Easy!Appointments released version 1.5.0 (production) that patched all the vulnerabilities
Conclusion
As the use of APIs is increasing exponentially, so is the prevalence of API vulnerabilities and BOLA vulnerabilities in particular. This article details the 15 BOLA vulnerabilities Unit 42 researchers discovered in Easy!Appointments using a new automatic methodology that leverages AI. Due to the ease of exploitation and potential impacts of these vulnerabilities, we encourage affected organizations to update to the patched version as soon as possible.
Researchers at Unit 42 are committed to fortifying open-source software and innovating technology to discover new vulnerabilities more efficiently and effectively. Palo Alto Networks customers are better protected by our latest research findings and insights.
Cortex Xpanse and Cortex XSIAM customers with the ASM module are able to detect all exposed Easy!Appointments instances as well as known insecure instances via targeted attack surface rules.
If you think you might have been compromised or have an urgent matter, contact 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
Get updates from Unit 42
Peace of mind comes from staying ahead of threats. Subscribe today.
Get the latest news, invites to events, and threat alerts
![Bar graph displaying normalized DNS traffic comparing malicious (red) and legitimate (blue) domains, with bars for various named domains like "chatgpt[.]com" and "openai[.]com," where "chatgpt[.]com" has the highest traffic overall. Of the many legitimate domains, only two are malicious.](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/07/chart-5.png)
Get updates from Unit 42 