The Shift to Threat-Informed Prioritization: Operationalizing CISA BOD 26-04
In this post, we examine how CISA BOD 26-04 shifts the industry away from flat CVSS scoring and details how Flashpoint bridges the critical data gaps left by public vulnerability repositories.
With the recent issuance of Binding Operational Directive (BOD) 26-04, CISA has officially shifted federal policy away from static severity scores and flat patching timelines toward threat-informed prioritization. The move reflects a reality security teams have grappled with for years: not all critical vulnerabilities post the same risk, and not all active vulnerabilities receive the highest CVSS scores.
Traditional vulnerability management programs have often relied on severity-based patching models that force resource-constrained teams to focus on large volumes of high-scoring vulnerabilities. Yet research consistently shows that threat actors routinely exploit a broader range of weaknesses, including lower-scoring vulnerabilities on internet-facing assets, to gain initial access and move laterally through victim environments.
While BOD 24-04 represents a significant step forward, there are still hidden challenges organizations will face as they adopt a risk-based approach. The operational reality is that executing a truly risk-based matrix validates what Flashpoint has maintained for years: effective vulnerability prioritization requires deep, contextual threat data. Unfortunately, the needed real-world metadata for this kind of context are simply not supported by public sources of vulnerability intelligence.
Understanding BOD 26-04
BOD 26-04 evaluates the urgency of a vulnerability by cross-referencing a security flaw against four distinct operational variables:
Asset Exposure: Is the asset publicly accessible via the internet?
Known Exploited Status (KEV): Is there verifiable evidence of active exploitation in the wild?
Exploit Automation: Can a threat actor completely automate the weaponization and delivery of the exploit?
Technical Impact: Does a successful exploit result in partial disruption or total compromise of the target system?
By analyzing these variables in tandem, organizations can tier their response and execute clear, defensible SLA metrics.
Risk Priority
Real-World Matrix Conditions
Required SLA & Operational Action
P1: Immediate Risk
In KEV + Publicly Exposed + Automatable + Total Impact
3 Days (Includes Mandatory Forensic Triage)
P2: Urgent Risk
In KEV + Publicly Exposed + (Either Non-Automatable OR Partial Impact)
7 Days
P3: Elevated Risk
In KEV + Internal / Non-Publicly Exposed Asset
14 Days
P4: Standard Risk
Not in KEV + Publicly Exposed + Automatable + Total Impact
30 Days
Deferred Risk
Not in KEV + Internal Asset OR Lower Technical Impact
Next Scheduled System Upgrade / Maintenance
According to CISA, the pilot testing of this model has shown that fewer than 1% of an organization’s typical vulnerability backlog requires urgent, immediate remediation, while over 60% can be safely deferred to standard system maintenance cycles. However, implementing this framework successfully requires access to granular, real-world data points that public sources of vulnerability intelligence simply do not support.
“Speaking with security teams in the wake of this directive, it is clear that BOD 26-04 is a major paradigm shift. While the ability to safely defer more than half of your patch backlog is an invaluable efficiency gain for modern organizations, executing that strategy effectively requires ground-truth intelligence on exploit automation and adversary intent that public registries simply cannot deliver.”
Josh Lefkowitz, CEO and Co-founder at Flashpoint
The Data Challenge
To operationalize this model successfully, organizations will require a high-fidelity intelligence pipeline that combines comprehensive threat and vulnerability intelligence into clear, context-rich insights that support prioritization and decision making. You cannot confidently defer remediation without verifiable intelligence that proves the vulnerability lacks active exploit history or automation maturity.
Unfortunately, relying on public data feeds like the CVE database or the National Vulnerability Database (NVD) to fuel this matrix creates an immediate operational bottleneck. Public repositories have historically struggled under severe analysis backlogs, leading to processing delays and missing Common Platform Enumeration (CPE) data. Furthermore, public feeds are inherently reactive; they do not monitor illicit communities where exploit code is developed, nor do they track the real-time weaponization metrics needed to meet BOD 26-04’s tight 3-day or 7-day compliance window.
How Flashpoint Solves the Prioritization Gap
Flashpoint Vulnerability Intelligence bridges the gap between public data limitations and the requirements of real-world exposure management. Independently researched and enriched, Flashpoint provides the precise contextual signals required by the CISA BOD 26-04 matrix:
By integrating Flashpoint’s continuous intelligence into operational workflows, security teams can automatically validate exposure, assess automation potential, and confidently claim the operational relief that risk-based prioritization promises.
“We are convinced by Flashpoint’s superior vulnerability coverage, timeliness in the updates, and long-term monitoring of exploits. We also really appreciate Flashpoint’s proprietary CVSS rating and classifications based on expert knowledge of the standard and practical use in the industry. Having all this curated information at your fingertips is a game changer.”
Vulnerability Manager, Telecommunications
Prioritize Vulnerability Risk Using Flashpoint
CISA’s BOD 26-04 represents a critical shift away from severity-based patching and toward defensive efficiency. However, the effectiveness of this model is entirely dependent on the fidelity of your threat data.
Without best-in-class comprehensive vulnerability intelligence, security teams will be forced back into reactive patching cycles. Request a demo to learn more how Flashpoint helps security teams move beyond the constraints of static scoring and align their vulnerability management workflows with actual risk.
During our recent threat hunting activities, we found EtherRAT malware being distributed by a website with a strange homepage. This homepage allowed us to discover a vast malicious infrastructure distributing malware, malicious documents, remote desktop software, and phishing pages.
EtherRAT is a RAT developed in Node.js which allows an attacker to gain complete control over the machine and execute arbitrary code returned by the Command and Control (C2) server. The malware uses the Etherium blockchain to obtain the C2 server, hence the “Ether” part of the name. EtherRAT is typically distributed via MSI, PowerShell, or JavaScript scripts.
An open directory that distributes EtherRAT: where it all began
While threat hunting, we found an open directory that was distributing MSI installers and PowerShell scripts, which ultimately distributed EtherRAT. In the analyzed cases, the PowerShell scripts and MSI installers were distributed from a “/install” folder. The versions have a progressive number, ranging from v1 to v10.
Open Directory hosting EtherRAT MSI
The returned home page caught our attention and prompted us to further explore the campaign.
The homepage returned by the EtherRAT distribution website
Analyzing domains and associated IPs with the EtherRAT distribution, we detected other similar home pages with a hacking-style theme. They appeared to belong to a larger distribution chain, which also distributes phishing, remote control software, and other malware. These websites usually have several folders with malware and phishing related content, and what is displayed depends on the specific infection chain.
Different websites that resolve to the same IP addresses have previously returned pages related to fake companies or default templates. The use of these new pages could therefore be a method to make detection more difficult for automated scanners or researchers. Here are some of the home pages we found:
Some of the malicious websites indexed on Google
EtherRAT is an interesting RAT, as it has few lines of code and allows the execution of arbitrary code returned by the C2 server. Furthermore, using the Ethereum blockchain to obtain the C2 server makes it more resilient to infrastructure takedowns.
Technical analysis of EtherRAT
The detected websites usually distribute an MSI or PowerShell script with the version name, such as v1.msi, v2.ps1, and so on.
MSI Loader
The MSI file “v9.msi” contains three components:
MSI Filename
Description
KmPuGimn.cmd
BAT launcher
cDQMlQAru0.xml
First Jscript loader
MRaQCipBIZeiZNx.log
Encrypted EtherRAT
When the MSI is executed, the “KmPuGimn.cmd” file is started:
conhost --headless cmd /c "KmPuGimn.cmd"
This obfuscated BAT file performs different operations:
Extracts the other files in a random folder in %LOCALAPPDATA%.
The final stage is to deploy EtherRAT. EtherRAT allows the attacker to:
Execute arbitrary JavaScript code received by the C2 server. This allows the attacker to execute new commands, perform operations on files and folders, modify the registry, and exfiltrate data.
Get a new C2 server using the Ethereum blockchain.
Reobfuscate itself.
Save the logs to “svchost.log”.
Part of decrypted EtherRAT code
The EtherRAT uses Ethereum’s “eth_call” JSON-RPC method to retrieve the active C2 URL from a smart contract on the Ethereum mainnet.
After startup, the RAT sends its own source code to the C2 server. The C2 responds with a newly obfuscated version of the script, which is written back to disk, making each execution generate a new file hash.
POST /api/[REOBF_PATH]/<victim-uuid>
Body: { "code": "<current_script_contents>", "build": "<build_id>" }
After the EtherRAT execution, we observed different post-compromised cmd.exe activities to check the environment. For example:
The activities performed by the PowerShell loaders are very similar to the last stage of the JS script of the MSI installer:
Downloads Node.js if it’s not present.
Create the necessary directories.
Decode the EtherRAT with a custom decryption algorithm.
Execute Node.js with conhost.exe and the decrypted EtherRAT payload.
We detected some variants of the PowerShell loader hosted on these websites; namely that the functions’ names and the decryption functions change in the analyzed PowerShell scripts.
The decryption of EtherRAT payload with the custom decryption algorithm
Tracking the malicious infrastructure
When we analyzed the different websites with the “hacking-theme” pages, we found that in the past many had hosted multiple phishing pages in some specific paths. For example:
/zht/sharep-redirect.html
/bl/me.php
/t/teams
/teams/Windows/invite.php
It seems that these domains and IPs are actually part of a much larger infrastructure that distributes malware, phishing, malicious documents, and remote software. It is possible that these infrastructures are shared by multiple threat actors who activate different URL endpoints based on the specific campaign.
Interestingly, the majority of the domains related to this malicious infrastructure in the past also returned an HTML page related to a “Bulletproof Infrastructure” service.
We found that these phishing campaigns typically start via emails with documents attached, such as PDF or Excel files. These documents ask the user to click a link to view another document. Below are two examples of the phishing documents attached to the emails:
These phishing pages typically ask the user to enter their email address, then continue the infection chain and distribute phishing or malware pages. Below are some of the phishing pages detected within the malicious infrastructure:
Misconfigurations exposed the phishing kits
While tracking malicious websites, we found one with an open directory containing part of the phishing kit used in the campaigns.
Open directory hosting part of phishing kits
The open directory contained several folders with code and pages related to the phishing campaigns.
Phishing kit code
Additionally, some domains were misconfigured and allowed the download of “cl.zip”, which contained the source code for the “URL Cloaker” pages.
Identity Is the New Attack Surface: How Infostealers Are Reshaping Enterprise Risk
Our new guide explores how infostealers are fueling modern identity-based attacks and how organizations can build a proactive defense before stolen access is weaponized.
A publicly exposed database surfaced in early 2026 containing more than 149 million stolen login credentials. The records were not tied to a single breach or organization. Instead, they had been quietly collected over time from devices infected with information-stealing malware, with each record containing usernames, passwords, session data, and the context needed to use them.
Unlike traditional breach dumps, this data was structured, searchable, and immediately actionable. Credentials were mapped to specific services, session artifacts reflected active logins, and much of the information was recent enough to enable direct access without triggering traditional security controls.
This incident reflects a broader shift in the threat landscape.
More than 11.1 million devices were infected with infostealers last year, fueling a supply of over 3.3 billion stolen credentials, session cookies, cloud tokens, and other forms of identity data now circulating across illicit markets.
For security teams, the challenge is no longer simply detecting a breach after it occurs. It is understanding when access may already exist — where compromised credentials are circulating, how they are being used, and how quickly they can be weaponized.
Drawing on Flashpoint’s Primary Source Collection (PSC) and analyst-driven intelligence, this guide helps IT, Threat Intelligence, Fraud, and HUNT teams understand how infostealers operate, how stolen identity data fuels real-world attacks, and how organizations can move from reactive response to proactive defense.
The guide explores:
How today’s most active infostealers power modern attack chains
How threat actors weaponize stolen credentials, cookies, and session data
How organizations can operationalize infostealer intelligence for proactive defense
How to evaluate infostealer intelligence providers and detection capabilities
Why Identity Has Become the Preferred Attack Surface
For years, security teams focused on vulnerabilities, malware delivery, and network intrusion as the primary paths to compromise. Increasingly, however, threat actors are taking a different
Modern infostealers such as Lumma, StealC, Vidar, Acreed, and Rhadamanthys provide attackers with something more valuable than initial access: usable identity. These malware families collect credentials, browser artifacts, session cookies, application data, and host metadata that help threat actors understand how a victim authenticates and what systems they can access.
A single infected device can expose credentials, browser artifacts, session cookies, application data, host metadata, and access to enterprise SaaS platforms. Together, these artifacts create a detailed profile of how a user authenticates, what systems they access, and how those systems trust that identity.
This is what makes infostealer data so valuable.
“For years, organizations have invested heavily in detecting malware, blocking exploits, and hardening infrastructure. Meanwhile, attackers have increasingly shifted to a simpler strategy: logging in with valid identities.
Infostealers have fundamentally changed the economics of access. Threat actors no longer need to compromise a network directly when billions of credentials, session cookies, and authentication artifacts are already circulating in underground ecosystems. The challenge for defenders has risen from preventing compromise to identifying where access already exists and how quickly it can be weaponized.”
Ian Gray, Vice President of Intelligence at Flashpoint
Identity data is inherently reusable. A stolen credential can be tested across multiple services. A session cookie can potentially allow attackers to hijack authenticated sessions. Browser and host metadata can help threat actors recreate a victim’s environment and bypass security controls designed to detect suspicious logins.
What begins as a single infection can quickly evolve into access across multiple systems, applications, and organizations.
What Is an Identity-Based Attack?
Identity-based attacks occur when threat actors use legitimate credentials, session cookies, authentication tokens, or other identity artifacts to gain access to systems and applications. Rather than exploiting a vulnerability or deploying malware inside a target environment, attackers authenticate as trusted users using stolen identity data.
This shift is one of the primary reasons infostealers have become so valuable. Modern infostealer logs often contain far more than usernames and passwords. They may also include browser cookies, session information, host metadata, application data, and other artifacts that help attackers understand how a user authenticates and what systems they can access. When combined, this information enables account takeover, fraud, lateral movement, and other forms of identity-based abuse.
From Credential Theft to Identity Exploitation
The way threat actors operationalize stolen data is evolving just as rapidly as the data itself.
Historically, attackers often had to manually review stolen credentials and determine which accounts were worth pursuing. Today, that process is increasingly automated.
Infostealer logs can be aggregated, tested, and prioritized at scale, allowing threat actors to rapidly identify valid access across enterprise systems, SaaS platforms, VPNs, and cloud environments.
Flashpoint identifies this as a hybrid threat: the convergence of large-scale identity compromise and automated exploitation.
Once valid access is identified, attackers can move quickly. Credentials may be reused across services. Session data can be leveraged for account takeover. Access can be sold to ransomware operators, fraud actors, or other criminal groups. In many cases, exposure itself becomes part of the attack lifecycle rather than merely a precursor to it.
The result is a threat landscape where stolen identity data is not simply stored and sold. It is continuously tested, validated, reused, and operationalized.
Turning Exposure Into Actionable Intelligence
For defenders, prevention remains important. But prevention alone is no longer enough.
Organizations must also be able to identify when credentials, session cookies, and other identity artifacts have already been exposed and are circulating within underground ecosystems.
The earliest opportunity to intervene is often after data has been exfiltrated but before attackers have successfully operationalized it.
Achieving that visibility requires more than traditional breach feeds or aggregated datasets.
Flashpoint’s Primary Source Collection approach provides direct visibility into the forums, marketplaces, Telegram channels, malware repositories, and illicit communities where infostealer activity originates. Rather than relying solely on recycled breach data, Flashpoint continuously collects from the environments where stolen identity data is first shared, sold, and operationalized.
However, collection alone is not enough.
Raw infostealer logs are noisy, fragmented, and difficult to operationalize at scale. Flashpoint transforms these logs into structured intelligence through a multi-stage workflow that includes:
Source ingestion from underground ecosystems
Normalization and de-duplication of collected data
Automated parsing and enrichment of credentials, cookies, host metadata, and malware attribution
Structured output that supports alerts, investigations, and integrations across existing security workflows
This process helps defenders understand not only what was exposed, but who may be affected, how exposure occurred, what systems may be at risk, and how quickly action is required.
Building a Proactive Defense Across the Identity Layer
The rise of infostealers has fundamentally changed how organizations should think about attack surface management.
The attack surface is no longer limited to infrastructure, endpoints, or internet-facing applications. It now includes the digital identities of employees, partners, vendors, and customers.
Security teams need visibility into the identity layer itself — understanding where exposure exists, how attackers are leveraging stolen data, and what actions should be taken before access is exploited.
By combining direct visibility into underground ecosystems with structured, actionable intelligence, organizations can identify compromised accounts earlier, uncover infection trends, prioritize response efforts, and reduce the likelihood of downstream compromise.
More than 11.1 million devices were infected with infostealers in the last year.
Over 3.3 billion credentials, session cookies, cloud tokens, and identity artifacts are circulating across illicit markets.
Flashpoint analysts identified 30+ active infostealer strains being sold across underground ecosystems.
Flashpoint’s credential database contains 48+ billion credentials, including more than 1 billion tied to infostealer activity.
More than 4.2% of infostealer-exposed credentials include browser cookies that may support session hijacking.
Flashpoint can collect and parse some infostealer logs within one to two days of infection.
Frequently Asked Questions (FAQ)
FAQ: Infostealers and Identity-Based Threats
What is an infostealer?
An infostealer is a type of malware designed to collect sensitive information from an infected device. Depending on the strain, this can include usernames and passwords, browser cookies, session tokens, saved payment information, cryptocurrency wallets, system metadata, and other identity-related artifacts.
How do infostealers work?
Infostealers infect a victim’s device and collect information such as credentials, browser data, session cookies, autofill information, cryptocurrency wallet data, and system metadata. The stolen information is packaged into files known as infostealer logs, which can then be sold, shared, or operationalized by threat actors.
What information can infostealers steal?
Depending on the malware family, infostealers can collect usernames and passwords, session cookies, authentication tokens, browser history, saved payment information, cryptocurrency wallet data, system information, installed applications, and other identity-related artifacts. The goal is to provide attackers with enough information to access accounts and impersonate legitimate users.
What are the most common infostealers?
The infostealer ecosystem changes rapidly, but Flashpoint analysts currently track strains such as Lumma (also known as LummaC2/Remus), StealC, Vidar, Acreed, and Rhadamanthys among the most prominent malware families driving credential theft and identity-based attacks.
Why are infostealers so dangerous?
Infostealers provide attackers with more than credentials. Modern infostealer logs often contain the context needed to use stolen data, including session information, browser artifacts, and device metadata. This allows threat actors to perform account takeovers, move laterally within environments, and gain access to business-critical systems. According to Flashpoint’s 2026 Global Threat Intelligence Report, more than 11.1 million devices were infected with infostealers last year, contributing to a pool of over 3.3 billion stolen credentials, session cookies, cloud tokens, and other identity artifacts.
What is an infostealer log?
An infostealer log is a package of data collected from an infected device. Logs may contain credentials, cookies, browser data, application information, host metadata, and other artifacts that help attackers understand how a victim authenticates and what systems they can access.
Can infostealers bypass multi-factor authentication (MFA)?
In some cases, yes. While multifactor authentication remains a critical security control, stolen session cookies and authenticated session data can sometimes allow threat actors to hijack existing sessions without needing to complete the MFA process themselves. Flashpoint found that more than 4.2% of infostealer-exposed credentials in its dataset were associated with browser cookies, highlighting the growing importance of session-based risk.
How do threat actors obtain infostealer logs?
Infostealer logs are frequently bought and sold across illicit marketplaces, forums, Telegram channels, and other underground communities. Many are distributed through Malware-as-a-Service (MaaS) offerings that make infostealer capabilities accessible to a wide range of threat actors. Flashpoint analysts identified more than 30 unique infostealer strains actively offered for sale across underground ecosystems.
How can organizations detect credential exposure from infostealers?
Organizations can monitor underground sources where stolen data is shared and sold, identify exposed credentials associated with their domains, and investigate related artifacts such as cookies, host metadata, and malware attribution. The earlier exposure is identified, the greater the opportunity to remediate before attackers operationalize access. Flashpoint collects and parses some infostealer logs within one to two days of infection, helping organizations detect exposure closer to the point of compromise.
What should organizations do if employee credentials appear in an infostealer log?
Organizations should immediately assess the scope of exposure, reset affected credentials, invalidate active sessions, review authentication activity, investigate the infected device, and determine whether additional accounts or systems may have been impacted.
How is Flashpoint’s approach to infostealer intelligence different from traditional breach monitoring?
Many organizations rely on aggregated breach feeds or credential dumps that may be weeks or months old by the time they are discovered. Flashpoint’s Primary Source Collection (PSC) approach provides direct visibility into the forums, marketplaces, Telegram channels, and underground communities where stolen identity data is first shared, sold, and operationalized.
In addition to collecting raw infostealer logs, Flashpoint parses and enriches the data with context such as malware attribution, session cookies, host metadata, browser artifacts, and affected identities. Today, Flashpoint’s credential database contains more than 48 billion credentials, including over 1 billion tied to infostealer activity, providing organizations with actionable intelligence rather than raw exposure data.
Understanding Illicit Ecosystems: Weaponizing Mainstream Apps and Social Infrastructure
As part of our ongoing series, we focus on the shared infrastructure that fuels threat actors; the intersection of mainstream social media, open-source messaging platforms, and gaming communities.
Threat actors and their illicit communities do not exist in a vacuum. To scale their operations, coordinate financial fraud, deploy malware, and recruit new talent, threat actors must interface with the broader digital world. This means leveraging everyday, public digital spaces to facilitate illicit activity, effectively hiding in plain sight.
The Clearnet Threat Landscape: Hiding in Plain Sight
When conceptualizing the cybercriminal underground, it is easy to focus exclusively on Tor-based onion sites or restricted-access dark web forums and marketplaces. However, a massive portion of modern illicit activity thrives on the clearnet. Threat actors heavily utilize commercial social media and public messaging networks to coordinate fraud, deploy malware, and run public relations campaigns for their operations.
At first glance, conducting illicit operations on highly monitored, mainstream platforms seems counterintuitive. However, the massive, continuous volume of legitimate traffic on the clearnet provides a form of operational security. By blending into the noise, threat actors can maintain a highly accessible digital presence. This visibility is crucial for their business models: it allows them to maintain a low barrier to entry for potential recruits and targets who know exactly what markers to look for, or who are systematically funneled into these spaces.
How Threat Actors Weaponize Consumer Platforms
The misuse of mainstream communication tools has changed how threat actors interact. Rather than waiting for users to seek out the dark web, cybercriminals are actively meeting their targets or co-conspirators on platforms designed for daily socialization.
Discord
Originally built to connect gaming communities, Discord’s rapid growth and robust infrastructure have inadvertently made it a target for malicious activity. Cybercriminals treat the platform as a multi-functional tool for both technical infrastructure, social engineering, and radicalization.
On a technical level, advanced persistent threats (APTs) and other threat actors exploit Discord’s content delivery network (CDN) to host and distribute malware. Because traffic to Discord domains is generally trusted by corporate networks, threat actors can potentially use it to deliver payloads—such as infostealers and remote access trojans (RATs)—bypassing standard security perimeters.
Beyond hosting malware, extremist groups across various ideological spectrums often target the platform’s demographic, which skews heavily towards younger tech-savvy users. This group provides an impressionable pool of adolescents who may be susceptible to grooming, indoctrination, and recruitment into illicit operations.
Case Study: The Targeting and Recruitment Mechanics of “The Com”
While monitoring The Com, Flashpoint analysts have observed the systematic use of platforms like Discord, Roblox, and Minecraft to run predatory extortion pipelines. The mechanics of this ecosystem takes place through a multi-phase methodology:
Platform Scouting: Recruiters patrol servers on popular youth-centric gaming platforms, such as Discord, Roblox, and Minecraft. They look for minors showing signs of social isolation, depression, disordered eating, or a desire to belong.
Building Trust and “Love Bombing”: Initial engagements are seemingly harmless. However, trust is built quickly to establish a sense of indebtedness. Recruiters offer gifts such as in-game perks/currency, premium subscriptions, or other digital items. In some cases, a romantic facade is used to establish a connection. In either scenario, “love bombing” creates an immediate feeling of psychological obligation in the target.
Platform Migration: Once rapport is established, the recruiter moves the target away from the game and into an encrypted app or private Discord server, following a public-to-private strategy. By moving the interaction away from the original platform’s safety controls, the recruiter can isolate the target in a more controlled environment.
Once isolated, perpetrators coerce victims into sending sensitive imagery or CSAM. This material is immediately compiled and weaponized as leverage for blackmail via doxxing. This creates a severe psychological trap in which the victim feels compelled to partake in escalating illegal activity to keep their previous actions hidden. This drives the victim to transition from a victim into an aggressor to escape their own abuse.
Telegram
While many social media and messaging platforms can serve as an initial funnel for engagement, Telegram has been known to be used from time to time as an operational hub for the broader illicit ecosystem. Since the arrest of Pavel Durov, Telegram has begun working more closely with law enforcement, leading to several key arrests and major disruptions due to their cooperation.
The platform occupies a unique space in threat intelligence and open source intelligence (OSINT). While the vast majority of its user base is entirely benign, its minimal moderation policy and robust channel architecture have made it vital to public and private intelligence gathering.
Telegram functions as an open marketplace and real-time coordination center for a vast spectrum of threat actors. Flashpoint has observed it being used by:
State-sponsored APT groups and hacktivists
Geopolitical actors and mercenary groups distributing battlefield intelligence and propaganda
Cybercriminal syndicates coordinating financial fraud schemes, check fraud, and the sale of compromised data.
Furthermore, threat actors routinely use other public-facing platforms like X (formerly Twitter) alongside Telegram to amplify their impact. They leverage the broad reach of social media to broadcast proof of their compromises, hype up ransomware leaks, and exert public pressure on corporate victims during extortion cycles. Concurrently, Telegram often acts as the backend repository where the stolen data is hosted, discussed, and monetized.
Monitor the Clearnet Using Flashpoint
The evolution of illicit ecosystems demonstrates that the lines between the dark web and the clearnet have intersected. Whether analyzing the activities of extremist and threat actor groups or tracking the predatory pipelines of The Com, defenders must look beyond traditional intelligence sources.
Because malicious actors rely heavily on consumer messaging apps and social platforms to coordinate attacks, leak data, and target people, monitoring these public-to-private pipelines is an essential component of threat intelligence. Uncovering these physical and cyber threats requires best-in-class threat intelligence and OSINT investigations capable of parsing the massive noise of the clearnet to find the signals of illicit coordination.
Request a demo to see how Flashpoint empowers security teams to monitor these decentralized threat landscapes to proactively protect their critical assets.
Check out the rest of our “Understanding Illicit Ecosystems” series:
The Future of Threat Defense Resides at the IP Layer
For years, network security operated on a relatively predictable premise: inspect traffic, identify malicious content, and block it. Because deep content inspection created a seemingly robust defense in depth, relatively static legacy approaches—like reliance on threat intelligence feeds—were allowed to simply persist in the background.
The weaponization of agentic AI and highly evasive techniques has fundamentally shattered that model. Attackers are no longer just iterating on old threats. They are launching attacks at staggering velocity, completely outpacing threat feeds, and employing evasion tactics that actively starve legacy prevention solutions of the content they rely on to inspect.
Our new research report from Unit 42, Attackers Are Evading Threat Prevention at the Internet Edge, reveals how adversaries are actively exploiting the contextual vacuum at the IP layer to bypass standard security controls. For security leaders, understanding this shift is no longer optional. As the nature of the threat fundamentally changes, our strategic approach to network security must definitively change with it.
The AI-Accelerated, Evasive Attack Lifecycle
To understand why legacy defenses are failing, we must look at how adversaries are accelerating and obfuscating every stage of the attack lifecycle. As these threats progress, the commonly used network indicators we have long relied upon are vanishing, collapsing traditional defenses and leaving defenders with little to act on.
Powered by frontier AI, adversaries now automate reconnaissance and exploitation at huge scale and speed, while using anonymizers to mask their intent. Once an intrusion is launched, orchestration shifts to highly evasive command and control (C2). Attackers hide communications using advanced encryption and AI-built malware-less techniques. They’re also bypassing traditional web and DNS inspection entirely by routing traffic directly to IP addresses—a tactic Unit 42 found in 23% of modern malware
Ultimately, the takeaway is clear: network threat prevention can no longer rely solely on detecting malicious payloads. As AI-driven attacks continue to minimize their footprint, security strategies must augment content inspection with real-time IP layer monitoring to left-shift threat detection and counter these rapid, machine-speed threats at the network foundation.
Existing Approaches Aren’t Working
Where content-based detection falls short, many security vendors and organizations still rely on IP threat intelligence feeds to pick up the slack in an attempt to filter out malicious connections on the network layer. However, after years of operating under this model, the results are in—the traditional feed is showing its age.
Attackers have long relied on proxies, anonymizers, residential routers and public cloud providers as a tactic to evade detection. However, agentic AI morphs this process, enabling rapid infrastructure rotation and stealth at an unprecedented scale. As this autonomous evasion accelerates, experienced network defenders continue to run into the well-known limitations of classic IP blocklists:
Too slow to keep pace: Unit 42 found an average 20-day lag time before new threats hit popular feeds. Because agentic AI enables adversaries to autonomously rotate proxy IPs in hours, these lists are obsolete at the moment of delivery.
Fundamentally incomplete: IP feeds are unable to see a massive portion of the modern attack surface. Unit 42 research indicates that 52% of malicious IPs used for direct-to-IP connections are completely absent from these lists.
Unactionable on shared infrastructure: Even known threats are often impossible to block. The Unit 42 team reports that 37% of direct-to-IP traffic uses reputable CDNs and cloud providers. IP feeds cannot distinguish malicious connections from legitimate ones, making blocking too risky for business continuity.
A management nightmare: Among the security teams that Unit 42 polled, 30% indicate resource-intensive vetting and false-positive triage as their top pain point. To avoid breaking legitimate traffic, feeds are frequently relegated to an alert-only mode, defeating the entire purpose of prevention.
If modern and agentic AI-enabled attacks can outrun traditional network payload-based detections, we need a new weapon in the network defender’s arsenal. We can no longer depend on yesterday’s IP feeds to secure such an extremely agile threat environment.
The Blueprint for Modernizing the Internet Edge
To outpace the impact of agentic AI and advanced evasion on network threat prevention, security leaders must redefine their defense strategy and shift-left to track the attacker infrastructure itself—monitoring the exact IP layer locations where adversaries build and control their campaigns. Deep content inspection remains essential, but securing the modern edge requires establishing the context and intent of a connection before a session is established.
To achieve this goal, organizations must move beyond the limitations of static defense and adopt a modern security blueprint:
Proactive protection against attacker infrastructure: While high-quality threat feeds remain essential for SOC investigations and incident response, relying on them for frontline, real-time prevention creates major blind spots. Instead, security teams must use real-world, global telemetry to proactively identify and block connections to attacker-controlled hosts before requesting a URL or file.
Zero trust principles applied to the network layer: An IP address without a negative reputation does not equal a safe connection. Continuous verification requires extending zero trust down to the network foundation. It validates the real-time behavior and intent of every single session to ensure attackers cannot hide in the contextual vacuum of the IP layer.
Reducing the attack surface with rich contextual attributes: Traditional IP blocking is like a blunt instrument that creates unacceptable false positives and alert fatigue. To modernize the edge, security teams need deep, attribute-based visibility across the entire Internet address space to reduce noise and replace legacy IP feeds entirely.
By moving away from point-in-time assumptions and embracing real-time, inline protection, security leaders can reclaim the advantage at the network foundation.
To see how these evasion tactics operate in the wild, read the latest Unit 42 report, Attackers Are Evading Threat Prevention at the Internet Edge. You’ll find this report valuable in understanding the systemic gaps in legacy risk models and learning why continuous verification must be our new mandate.
For more than two decades, XSS was the gathering ground for the Russian-speaking cybercriminal underground. Evolving from its former name, DaMaGeLaB, XSS evolved from a mid-tier message board into a top-tier hacking forum.
XSS is home to vendors of various crime types, including loaders, phishing, scamming, carding, malware development, distributed denial-of-service (DDoS) bots, and related services. It also facilitates the trade of illicit goods and services, while simultaneously serving as a networking and recruitment hub for threat actors.
XSS forum content falls within the following main sections:
“Programming, Development”: Includes posts and articles about programming languages and administration.
“Library”: Includes news articles, databases, and discussions around software and tools. Users also post about vulnerabilities and exploits.
“Business Decisions”: Users discuss different investments, the sale of digital goods, trading, start-ups of fraudulent businesses, and news about cryptocurrencies.
“Lounge Zone, Resting”: Content involves lifestyle discussions, hobbies, and cybercriminal community rumors and scandals.
“Trading Platform”: Users sell and look to buy network access, malware, counterfeit documents, and advertise their services. This is where users hire and look for work or partners.
“People’s Court”: Used for complaints and arbitration and contains lists of phishing forums and scammers.
“Ours”: Contains information about the XSS project, discussions on issues, suggestions, and initiatives for forum improvement.
“Private: Underground”: Closed section for only forum members.
XSS forum main sections (Source: XSS)
XSS Disruption: July 2025 Takedown
On July 23, 2025, law enforcement organizations reportedly seized XSS as part of a multinational operation with Ukrainian authorities, French police, and Europol. Alongside the domain seizure, French authorities reported the arrest of XSS’s longtime administrator in Ukraine.
This arrest triggered an immediate chain reaction that has had lasting effects on the Russian-speaking underground—with the XSS ecosystem splintering into several competing factions.
The Current State of the Russian-Speaking Underground
While the original XSS architecture was severely disrupted, the surrounding Russian-speaking cybercriminal ecosystem remains intensely active. However, instead of a centralized hub, the XSS ecosystem is spread out through competing environments that emerged directly from the fallout of the takedown.
DamageLib
Launched by the legacy moderators of XSS, DamageLib represents a structural pivot away from standard illicit forums. Concluding that the old XSS site was compromised by law enforcement, the moderators launched a new model that completely abandons commerce—shutting down all buying, selling, and auctions entirely—-to eliminate user tracking and surveillance. Instead, it focuses strictly on technical materials and tutorials.
Rehub
Recognizing that displaced cybercriminals still required a commercial venue to trade, a former XSS moderator launched Rehub quickly after the emergence of DamageLib. Rehub immediately integrated a commercial platform, successfully recruiting prominent threat actors into its moderation team to establish underground credibility.
The forum is still in its development stage, with its content being populated, and an active member base being built.
XSS[.pro]
In early August 2025, an unknown entity launched an alleged resurrection of the forum on a new domain [.pro], utilizing old backups that preserved legacy user data, threads, and forum deposits. However, this new version has been met with significant distrust from Exploit and DamageLib, believing the [.pro] domain to be a honeypot controlled by law enforcement.
XSSF Forum
Started by a pro-Russian Telegram hacking group, this community actively targets EU and Ukrainian digital infrastructure. According to user discussions on DamageLib, this forum is not related to XSS. In addition, Flashpoint analysts note that targeting Ukrainian infrastructure directly contradicts its original community rules. The authenticity of this forum and its ownership has not been verified.
Monitor a Fractured Underground Using Flashpoint
While law enforcement achieved a significant victory over XSS, they did not eliminate the Russian-speaking cybercriminal underground. Instead, they broke the foundational trust mechanics that had kept it centralized for twenty years.
This has left the Russian-speaking underground in a deeply fractured state that is still intensely active and highly adaptive. For defenders and analysts, this threat has not diminished—it has diversified. Tracking this ecosystem no longer means watching a single centralized community, but rather actively mapping out the live migrations, shifting rules, and behavioral patterns across these splintered groups.
Request a demo to learn how Flashpoint helps security teams aggregate intelligence from these scattered factions into a single source of truth, empowering your organization to proactively monitor and intercept emerging threats.
The Mini Shai-Hulud Worm and the New Era of CI/CD Exploitation
In this post we break down the technical mechanics of TeamPCP’s recent campaign, the impact on the developer ecosystem, and the urgent steps needed to secure software supply chains.
The developer ecosystem recently faced one of its most significant architectural threats to date, with the threat actor group TeamPCP unleashing Mini Shai-Hulud—a self propagating worm and multi-ecosystem threat. Potentially affecting millions of developers and thousands of companies, Mini Shai-Hulud has fundamentally compromised the trust layer of modern CI/CD pipelines.
The operational tempo of Mini Shai-Hulud has accelerated with every campaign. What began as opportunistic credential theft has now evolved into a high-speed, automated operation that can compromise hundreds of packages in under thirty minutes. From the exfiltration of approximately 3,800 internal GitHub repositories to the poisoning of critical libraries like TanStack and AntV, TeamPCP’s campaign has been incredibly effective in exploiting developer tooling and identity infrastructure.
What is Mini Shai-Hulud?
Mini Shai-Hulud is deployed as a 498 KB obfuscated script executed using the Bun JavaScript runtime. The deliberate choice of Bun, rather than Node.js, is a tactical evasion technique as most endpoint detection and response (EDR) platforms and security information and event management (SIEM) solutions have behavioral rules tuned to Node.js execution patterns.
How Mini Shai-Hulud Works
The worm propagates by stealing npm and GitHub authentication (OIDC) tokens from developer environments, then using those credentials to publish malicious versions of packages the compromised user maintains. To accomplish this, the worm scrapes runner process memory to extract short-lived identity tokens, which it then exchanges for per-package npm trusted-publisher tokens without requiring any long-lived npm secrets.
Credential Exfiltration and Command-and-Control
Mini Shai-Hulud targets credentials across 130 file paths, including npm tokens, GitHub personal access tokens, AWS, GCP, and Azure configuration files, Kubernetes kubeconfig files, Docker credentials, HashiCorp Vault tokens, 1Password and Bitwarden CLI vaults, SSH private keys, and Bitcoin wallet files.
Exfiltration occurs across multiple channels: the Session Protocol network, the GitHub Git Data API using dynamically created Dune-themed repositories on victim accounts, HTTPS to the threat actor-controlled domain, and an api for GitHub Actions workflow exfiltration.
The worm uses a dead-drop command-and-control (C2) architecture via GitHub’s public commit search API. An installed daemon (kitty-monitor, deployed as a systemd service on Linux or a LaunchAgent on macOS) polls GitHub for commits containing the string “firedalazer,” parses RSA-PSS-signed command payloads from matching commits, and executes them. This technique leverages GitHub as a trusted relay, making C2 traffic difficult to block without disrupting legitimate GitHub usage.
The worm then uses a persistence mechanism as a dead-man’s switch: a GitHub personal access token named “IfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner” is created on compromised developer machines. If an operator revokes this token without first disabling the persistence mechanism, the worm destroys all home directory data on the compromised device.
AI Agent Hijacking
Beyond standard persistence mechanisms, Mini Shai-Hulud targets AI coding agents. The SafeDep analysis documents that the worm modifies Claude Code’s settings .json to insert a SessionStart hook, enabling the worm to be reinstated with full LLM API privileges even if the infected npm packages are later removed, or the npm cache is cleared. A similar technique targets Visual Studio Code’s tasks.json file using the “runOn”: “folderOpen” trigger, and Codex configuration files are also targeted.
These AI agent hijacking techniques represent a novel attack surface: by persisting within trusted AI tool configurations, the malware can exfiltrate all code and secrets processed by those tools during future development sessions.
Four Waves of Supply Chain Attacks
Flashpoint has observed at least four documented waves of TeamPCP npm and PyPI supply chain attacks in 2026, leveraging Mini Shai-Hulud to compromise developer tooling ecosystems and steal credentials, cloud keys, and source code across tens of thousands of organizations.
The following timeline tracks the escalation of TeamPCP and the Mini Shai-Hulud waves throughout 2026:
Wave 1: Initial SAP Packages (April 2026)
The first documented wave of Mini Shai-Hulud attacks targeted a small number of SAP-ecosystem npm packages in April 2026. While TeamPCP had already proven their CI/CD attack capabilities in March 2026 by compromising Aqua Security’s Trivy scanner and Checkmarx KICS via GitHub Actions, this initial wave served primarily as a proof-of-concept for the self-propagation mechanism and a reconnaissance phase for TeamPCP’s access broker network. Further, these attacks demonstrated the group’s ability to compromise widely used security tooling—a development that significantly undermines defenders’ ability to trust automated CI/CD pipeline scanning results.
Wave 2: TanStack, Mistral AI, and Guardrails AI (May 2026)
Leveraging a GitHub Actions cache-poisoning technique, TeamPCP published malicious versions of 42 TanStack packages across 84 releases, impacting a project with over 518 million cumulative downloads.
The attack also compromised Mistral AI and Guardrails AI, extending the attack surface to the AI developer tools ecosystem. Forged commit authorship was used to blend the attacker’s commits into AI-assisted development environments where Claude Code is commonly deployed.
TeamPCP simultaneously listed Mistral AI source code for sale on BreachForums, claiming possession of approximately 5 GB of data across 450 internal Mistral repositories.
TeamPCP BreachForums posts advertising Mistral AI internal source code and repositories for sale, May 2026. (Source: Flashpoint)
Wave 3: AntV Ecosystem (May 2026)
Targeting AntV enterprise data visualization ecosystem, TeamPCP compromised the atool npm account, which held publishing rights across a broad catalog of AntV packages. In 22 minutes, 637 malicious versions were published across 323 packages—a scale and speed that overwhelmed standard security monitoring pipelines.
Each infected package contained the Mini Shai-Hulud worm, which, upon execution, created up to 2,500 compromised repositories on victim accounts within hours.
Wave 4: Co-Ownership of BreachForums and GitHub Breach
In the most recent wave, TeamPCP announced its assumption of co-ownership of BreachForums, the largest English-language cybercriminal forum currently active. This development significantly elevates TeamPCP’s standing and operational reach. As co-owners, the group stated it would manage platform operations, handle dispute resolution, staff and vet moderation personnel, and host monetary contests for the community. The announcement positions TeamPCP as both an active threat actor and a platform-level infrastructure operator, with the ability to shape forum policies, curate the availability of criminal tooling, and influence the broader access broker and ransomware ecosystem.
Additionally, by poisoning a GitHub employee’s development environment, TeamPCP exfiltrated approximately 3,800 internal GitHub repositories. Within the stolen data were highly sensitive codebases such as:
copilot-api and copilot-token-service
actions-runtime
billing-platform
enterprise-crypto
authentication
codeql-core
detection-engineering
csirt
azure-config
TeamPCP BreachForums posts advertising GitHub internal source code for sale. (Source: Flashpoint)
Recommended Immediate Actions
Critically, the theft of internal source code from one of the world’s most widely used code hosting platforms creates incredible downstream risk for organizations that depend on GitHub Copilot and GitHub Actions for their own software development pipelines. Organizations running AI coding agents such as Claude Code and VS Code with extensions in their CI/CD pipelines face heightened exposure. Security teams should treat AI agent configuration files as sensitive assets subject to integrity monitoring and change-control policies.
If your organization uses npm, PyPi, or AI-assisted development tools, Flashpoint recommends the following immediate steps:
Audit and remove: Immediately audit CI/CD environments and remove all infected versions of AntV, TanStack, Mistral AI, and Bitwarden CLI packages.
Rotate credentials: Rotate all cloud credentials (AWS, GCP, Azure) and npm tokens.
Disable persistence first: Before revoking suspicious GitHub tokens, ensure the kitty-monitor daemon is disabled to avoid triggering the “dead-man’s switch” wiper.
Lock down IDEs: Restrict the installation of VS Code extensions to an approved allow-list and monitor for unauthorized changes to settings.json or tasks.json.
Block C2 infrastructure: Block all traffic to identified TeamPCP C2 domains.
Track TeamPCP and Defend against Mini Shai-Hulud Using Flashpoint
Flashpoint assesses with high confidence that TeamPCP will continue to scale its supply-chain attacks against npm, PyPI, and developer tooling ecosystems. The group’s shift from direct execution to orchestrating a broader ecosystem via BreachForums signals a maturation into a platform-layer criminal operation. While TeamPCP has hinted that the group may be approaching “retirement” due to law enforcement pressure, this should be treated with caution. Whether a misdirection or a genuine exit plan, the open-sourcing of Shai-Hulud means the tradecraft is available to the wider cybercriminal community.
Organizations should reference the OpenSSF npm Best Practices guidance for a practical baseline in hardening their package consumption posture. Flashpoint customers can gain access to known Indicators of Compromise (IOCs) and MITRE ATT&CK Mapping for Mini Shai-Hulud by logging into Flashpoint Ignite. To learn more about how Flashpoint tracks threat actor groups like TeamPCP and protects the software supply chain, request a demo.
Understanding Illicit Ecosystems: The Hybrid Threat of “The Com”
In this post, we dive into the decentralized architecture of “The Com,” exposing its hybrid ecosystem of hacking, extortion, and real-life violence—and how it fuels a ruthless pipeline of cyber-fraud cycles and adolescent exploitation.
The Community, more widely known as “The Com” is a sophisticated hybrid threat ecosystem in which cybercrime serves as the venture capital for domestic terrorism. Existing since the early 2010s, it operates in the “edgesphere”, a grey area where mainstream social media overlaps with underground criminal networks, blending nihilistic violent extremism (NVE) with high-level financial fraud. In The Com, cybercrime against Fortune 500 companies is the primary revenue stream used by members to fund a domestic terror network that aims to radicalize youth and encourage real-world violence.
However, The Com poses more than just financial risk, it is a self-serving victim-to-perpetrator pipeline. It uses stolen capital to recruit adolescents, who they view as a disposable workforce, turning them from a victim to a perpetrator. Despite being a decentralized web of individuals rather than a traditional threat actor organization, The Com has managed to grow by hiding in the gaps between corporate security, parental oversight, and law enforcement.
How The Com is Structured
The Com is often mischaracterized as a single, formal organization. In reality, its ecosystem is unstructured and lacks a shared culture or leadership. However, the various factions within the ecosystem are extremely organized, supporting three broad categories of criminal activity: cybercrime, exploitation of minors, and real-world physical violence.
Federal investigations have shown that The Com includes a mix of adults and minors, men and women. While the exact number of members is difficult to determine, Flashpoint estimates that the broader ecosystem of The Com is in the thousands. While being a global threat, its most active core members are concentrated in Western English-speaking countries: the United Kingdom, the United States, and Canada.
Understanding the Key Pillars of The Com
While The Com is a decentralized ecosystem, its internal structure is defined by a high degree of operational alignment. Individual crews and networks within each pillar exhibit a shared psychology and standardized tradecraft that ensures their criminal activities remain effective and repeatable.
However, Flashpoint notes that members of these pillars do not operate alone. Their interaction with members of other pillars (extortion and real-world violence) amplifies the intended threat.
HACKER Com: The Economic Engine of The Com
Hacker Com acts as the ecosystem’s economic engine and primary technical arm. Its primary function is to hack major corporations and commit financial fraud to fund the broader community’s activities and lifestyle. Seeing themselves as the elite technical tier of The Com, Hacker Com members are motivated primarily by financial gain and the thrill of outsmarting corporate security infrastructures. Notable crews within this pillar include Scattered Spider, LAPSUS$, ShinyHunters, and DragonForce.
TTPs Used by HACKER Com
The following tactics, tools, and procedures (TTPs) have been observed by HACKER COM groups:
Social Engineering (Vishing)
Hacker Com members capitalize on TTPs that target human vulnerabilities instead of relying solely on software and other exploits. Vishing is a signature move of the Scattered Spider crew, whose native English-speaking members call corporate IT helpdesks impersonating employees of that company.
Analysts note these threat actors are likely Gen Z who socially engineer older support staff by mimicking the impatient attitudes and vernacular of young tech executives, essentially hacking the generation gap. They leverage this form of social engineering to convince support staff to reset passwords or even re-enroll new multifactor authentication (MFA) devices, which grants them access to the victims’ networks.
Supply Chain Targeting
Crews in this pillar have also successfully breached major targets by attacking their trusted vendors. For instance, Lapsus$ compromised Okta by targeting its third-party contractor, Sykes, while Scattered Spider has repeatedly targeted Okta’s identity services to pivot into their clients’ networks.
Living-off-the-land (LOTL)
Once inside a network, threat actors avoid detection by using legitimate, preexisting software and other remote admin tools such as AnyDesk, Ngrok, and Teleport to maintain persistence and move laterally. They often gamify this access, mocking victims for allowing them to simply “log in” using standard admin tools rather than having to hack their way in via complex exploits. They treat the ease of access as a testament to the victim’s incompetence.
SIM Swapping
A SIM swap attack is a foundational TTP used by financially motivated actors that involves social engineering mobile carriers to hijack a target’s phone number, usually resulting in the takeover of high-value cryptocurrency accounts.
EXTORT Com: The Ideological Engine of The Com
The Extort Com pillar functions as a machine designed for psychological control, coercion, and sexual exploitation of minors. Its goals intersect squarely with NVE ideologies, resulting in a marketplace and production center for CSAM and extreme violence, where members often trade these materials as a form of social currency.
Targets are migrated from public channels, which include social media and video games such as Roblox and Minecraft, to private ones maintained by The Com. Once moved, the dynamic shifts from recruitment to active exploitation, which is done to ensure the victim’s compliance.
IRL Com: The Enforcement Engine of The COM
The “In Real Life” (IRL) pillar serves as the physical enforcement arm of the ecosystem, effectively bridging the gap between virtual threats and reality. Sometimes referred to by law enforcement as “IRL Terror,” members often turn online animosity and disputes into real-world harm against people and their property.
Protect Against Converging Threats Using Flashpoint
The evolution of The Com represents a fundamental shift in the global threat landscape. It is not enough to view cybercrime as a purely financial risk or domestic extremism as a purely ideological one, the two have merged into a self-sustaining engine where stolen corporate capital fuels the radicalization and exploitation of the next generation.
As The Com continues to professionalize its tradecraft and expand its reach, the boundary between our digital and physical worlds will only continue to thin. To protect against this decentralized threat, organizations will require a mutli-layered defense strategy that is powered by intelligence that is sourced at the heart of these groups. Request a demo to learn more.
Last year, we published research1 about a North Korean Lazarus subgroup targeting financial and cryptocurrency organizations, encountered during multiple incident response engagements. This Lazarus subgroup overlaps with activity linked to AppleJeus2, Citrine Sleet3, UNC47364, and Gleaming Pisces5. In one investigation, we observed that the actor had replaced ThemeForestRAT and PondRAT with a more sophisticated memory-only toolset. This follow-up post covers all three malware families from that toolset: DPAPILoader, RemotePELoader and RemotePE.
The three form a chain. DPAPILoader decrypts and loads RemotePELoader from disk using the Windows Data Protection API (DPAPI). RemotePELoader beacons to a C2 server and waits until it receives the next stage: RemotePE, a RAT executed entirely in memory and never written to disk, leaving no filesystem artifacts. At the time of writing, we have not found samples of RemotePELoader or RemotePE on VirusTotal.
The toolset’s environmental keying, memory-only execution, EDR evasion, and low forensic footprint suggest it is purpose-built for long-term observation campaigns. This allows the actor to quietly maintain access over an extended period before moving to a high-impact final objective such as data theft or a large-scale financial heist, consistent with this actor’s known history. We are sharing samples with detection rules and indicators of compromise (IOCs) to help defenders identify and respond to this toolset in their environments.
Figure 1: The three-stage chain: DPAPILoader decrypts and loads RemotePELoader from disk, which retrieves and executes RemotePE in memory
DPAPILoader is implemented as a DLL whose purpose is to decrypt and load an encrypted payload from disk using DPAPI. In the incident response case, it was found as C:\Windows\System32\Iassvc.dll, installed under the service name “Internet Authentication Service.” This service runs Iassvc.dll automatically on system startup, providing persistence for the toolset. The filename and service name are chosen to mimic the legitimate Windows Server Internet Authentication Service (IAS) and its accompanying DLL C:\Windows\System32\iassvcs.dll (note the extra ‘s’ in the filename).
In Listing 1, we list a Windows service record, extracted from the forensic image using Dissect6, that shows the masquerading in detail.
name (string) = Ias
displayname (string) = Internet Authentication Service
description (string) = Internet Authentication Service (IAS) is a component of Windows Server operating systems that provides centralized user authentication, authorization and accounting.
servicedll (path) = %SystemRoot%\system32\Iassvc.dll
imagepath (path) = %systemroot%\system32\svchost.exe
imagepath_args (string) = -k netsvcs -p
objectname (string) = LocalSystem
start (string) = Auto Start (2)
type (string) = Service - Own Process (0x10)
errorcontrol (string) = Normal (1)
Listing 1: Service record from Dissect showing Windows service that runs DPAPILoader
The sample from our investigation first checks whether it is running under C:\Windows\System32\Svchost.exe. It then loops over all files matching the wildcard path C:\ProgramData\Microsoft\Windows\DeviceMetadataStore\en-US*.*. This directory normally contains Microsoft Cabinet files used for device metadata packages. DPAPILoader skips any file beginning with the Cabinet magic bytes (MSCF / 4D 53 43 46), filtering out legitimate metadata packages. Any file that passes this check and is larger than 51200 bytes (50 KiB) is decrypted using DPAPI and loaded into memory using libpeconv7 , an open-source reflective PE loading library.
Across the DPAPILoader samples we observed, the loading mechanism and host process differ, as documented in the Observed Samples section, but the core behaviour is consistent.
DPAPI Encryption
DPAPILoader uses the Windows Data Protection API (DPAPI) to decrypt its payload. DPAPI ties cryptographic keys to a specific user account, with key management handled entirely by the OS. The caller only invokes encrypt and decrypt functions.
This offers the actor two advantages. First, the encrypted payload on disk is never in plaintext: if a sample is uploaded to VirusTotal, it is useless without the victim’s DPAPI keys. Static analysis is effectively impossible without them. Second, each deployment produces a unique encrypted blob, meaning the payload hash differs across victims and evades hash-based detection. The only prerequisite is prior access to the target machine to encrypt and drop the payload, something the actor has at this stage of the intrusion.
After DPAPI decryption, the payload is additionally XORed with 0x8D before loading. This is consistent across all observed DPAPILoader samples. This approach is an instance of environmental keying8, where malware is bound to a specific victim environment and cannot be analysed or executed elsewhere.
Observed Samples
We identified three DPAPILoader samples spanning roughly nine months, with differences in loading mechanism, host process, and payload storage.
The first sample (Iassvc.dll) is loaded as a Windows service via Svchost.exe, the second (sspicli.dll) is sideloaded by ESET’s edp.exe, and the third (wmiclnt.dll) uses the WmiOpenBlock export with no identified host process.
PE timestamp
DLL name
Export
String obfuscation
2023-11-14
Iassvc.dll
ServiceMain
XOR 0x8D
2024-02-21
sspicli.dll
InitSecurityInterfaceW
XOR 0x8D
2024-08-21
wmiclnt.dll
WmiOpenBlock
DPAPI + XOR 0x8D
Table 1: Observed DPAPILoader samples by PE timestamp
The first two samples load the DPAPI-encrypted payload from the DeviceMetadataStore path. The third embeds the encrypted payload directly in the DLL, removing the dependency on a separate file on disk.
The second and third samples were found on VirusTotal. Without the victims’ DPAPI keys, we are unable to decrypt them. Both are a practical demonstration of the environmental keying discussed earlier.
The first sample comes from our incident response case, where a full forensic image of the compromised machine gave us access to the victim’s DPAPI keys, allowing us to trivially decrypt the payload using a Dissect9 shell:
Figure 2: Decrypting the DPAPI-encrypted PE payload using Dissect
It turns out the decrypted payload is another loader, which we named RemotePELoader.
RemotePELoader is decrypted from the DPAPI payload on disk and is responsible for retrieving the core module from a C2 server and loading it into memory. Both the loader and the core module share a configuration file stored on disk, and are designed to work as a pair, deployed together as part of the same installation. Upon execution, RemotePELoader spawns a thread that first applies evasion techniques, reads the configuration, and then enters a C2 polling loop. It has no RAT functionality of its own; its sole purpose is to load the next stage.
HellsGate & EDR Evasion
RemotePELoader applies two evasion techniques before performing any further actions. The first is HellsGate10 (specifically the TartarusGate11 variant), a technique that dynamically resolves Windows syscall numbers at runtime. It scans the loaded ntdll.dll for syscall stubs to obtain the numbers for NtOpenSection, NtMapViewOfSection, NtUnmapViewOfSection, NtProtectVirtualMemory, and NtClose. Using these direct syscalls, RemotePELoader iterates the Process Environment Block’s module list and remaps each DLL from its \KnownDlls section object, a kernel-maintained mapping of trusted system DLLs, replacing any hooked in-memory copies with clean ones and effectively unhooking all userland security product hooks.
The second is patching Event Tracing for Windows (ETW), a Windows mechanism used by security products to monitor process behaviour at runtime. RemotePELoader patches function EtwEventWrite() in the current process using a well-known technique, overwriting it with the following bytes.
48 33 c0 ; XOR RAX, RAX
c3 ; RET
Listing 2: Bytes written to EtwEventWrite to disable ETW event generation
This causes EtwEventWrite to immediately return 0, suppressing all ETW event generation and preventing security tooling that relies on ETW telemetry from receiving events.
Together, these two techniques hinder detection by endpoint security products that rely on userland API hooking or ETW telemetry.
Configuration
After applying evasion techniques, RemotePELoader reads a configuration file using the same wildcard search as DPAPILoader:
The configuration file is smaller than the encrypted RemotePELoader payload, so it identifies it by looking for a file that does not begin with Cabinet magic bytes and is smaller than 20480 bytes (20 KiB). When found, it decrypts the contents using DPAPI and XORs all bytes with 0x8D.
Figure 3: Decrypting the DPAPI-encrypted config using Dissect
The configuration file structure is depicted in Listing 3.
struct RemotePEC2Config // sizeof=0xb38
{
int dwReconnectMinutes; // minutes to wait after C2 session ends
int dwSleepUntilEpoch; // UNIX epoch wake-up timestamp
int dwSleepMin; // minimum sleep time between C2 polls
int dwSleepMax; // maximum sleep time between C2 polls
wchar_t wsC2Url_1[260]; // C2 URL (up to three)
wchar_t wsC2Url_2[260];
wchar_t wsC2Url_3[260];
wchar_t wsProxy[260]; // optional proxy address
char sProxyUserName[128]; // optional proxy username
char sProxyPassword[128]; // optional proxy password
wchar_t wsUserAgent[260]; // configurable HTTP user-agent string
};
Listing 3: RemotePE C2 configuration structure on disk
Since both RemotePELoader and the configuration file reside in the same directory, a size check is used to distinguish between them, without it, the configuration file could be mistakenly loaded as a PE, or the PE read as a configuration file. This shared logic, combined with the identical cryptographic scheme, further ties the two loaders together as a coordinated toolset.
C2 Communication
After reading the configuration, RemotePELoader enters a loop until it receives a PE payload from the server. On the first run it sleeps until the configured wake-up timestamp and on subsequent iterations it sleeps for a random interval within the configured bounds. It then finds an active C2 server via a check-in request and keeps polling for a PE payload. If no payload is returned, it restarts the loop. Once a payload is received, it sends a confirmation request to the active C2, loads the retrieved PE payload using libpeconv, and exits the thread.
RemotePELoader communicates with the C2 server over HTTP, using POST requests. Host information is passed via the HTTP Cookie header, with a check-in request identified by the presence of at_check=true. The server responds with a JSON object where the odata.metadata key contains the C2 session ID. Once a session ID is obtained, subsequent requests replace the at_check cookie with ai_session, set to the session ID received from the server. The table below documents each cookie field used in the check-in request.
Cookie name
Cookie value description
MSCC
Random buffer with regex [0-9a-z]{24} prepended to the string “-c1=2-c2=2-c3=2”
MicrosoftApplicationsTelemetryDeviceId
Bot ID
MSFPC
Random numbers with format string “%08lx%08lx%08lx%08lx”
HASH
Random number with format string “%04x”
LV
Current year and month in YYYYMM format
V
Constant number
LU
Epoch of current time
MS0
Random numbers with format string “%08lx%08lx%08lx%08lx”, likely to indicate RemotePELoader request
Once a C2 session is established, RemotePELoader polls the server at random intervals between the configured minimum and maximum sleep times. In our tests, the server did not immediately return a payload, suggesting an actor-in-the-loop model where the operator manually decides when to deliver it. When the operator delivers the payload, the server returns a JSON object where the odata.metadata key contains the PE payload, AES-GCM encrypted and Base64-encoded.
Figure 4: RemotePELoader C2 session showing the server returning the encrypted PE payload
All messages exchanged with the C2 server are AES-encrypted, except for the initial check-in response containing the session ID. The AES key and nonce for each message are derived using SplitMix64, seeded with a random value generated by a Mersenne Twister PRNG. Each message is structured as follows, with the seed prepended to the AES-GCM tag and ciphertext:
struct C2Message {
uint64_t aes_seed; // SplitMix64 seed for AES key and nonce
unsigned char aes_tag[16]; // AES authentication tag
unsigned char ciphertext[]; // AES-GCM encrypted data
};
Listing 4: C2 message structure used by RemotePELoader and RemotePE
The decrypted payload is RemotePE, a fully-fledged RAT that runs entirely in memory, covered in the next section.
RemotePE: Final-stage, in-memory RAT
RemotePE is a fully-fledged RAT that we retrieved directly from a RemotePELoader C2 server by emulating its C2 protocol.
Written in C++ using object-oriented programming, RemotePE is a multithreaded program that appears to share a codebase with RemotePELoader. Both components share the same on-disk configuration file, this is by design: if an operator updates the configuration and the host reboots, both components need to read the same updated values to maintain access. Furthermore, C2 logic, including session handling, AES-GCM encryption, and the C2Message structure are equal. Also, in the samples from our investigation, RemotePELoader and RemotePE each verify they were loaded by the previous stage by checking that lpReserved == 0x1000 in DllMain, enforcing the integrity of the chain.
Control flow
RemotePE starts two threads at startup. The first, IChannelController, handles C2 communication. The second, IMiddleController, processes commands received from the C2 server. When the C2 server ends the current session, both threads stop and RemotePE either exits or sleeps until the configured wake-up time.
The IChannelController thread first locates an active C2 server and then polls it for commands. Between each polling iteration, the thread sleeps for a configured random interval, or wakes immediately if command output is available. In that case, the output is sent back to the C2 server without waiting for the next polling interval, allowing the operator to issue the next command promptly. Received commands are pushed to a queue consumed by IMiddleController. The IMiddleController thread processes commands from the queue and pushes output back to a queue read by IChannelController. Each C2 message from the server consists of a list of entries delimited by $, where each entry is a bundle of commands (see the C2 Protocol section). Commands can optionally be executed in a separate thread, and all output is merged into a single reply sent back to the server.
While sleeping, RemotePE also checks for the existence of a Windows event named 554D5C1F-AABE-49E4-AB57-994D22ECED28. If present, it wakes immediately and restarts both controller threads. Neither RemotePE nor the loaders create this event, implying it is created externally as an out-of-band mechanism to wake RemotePE on demand.
Commands
RemotePE supports six categories of commands, identified by their C++ runtime type information (RTTI) class names. The table below lists each class along with the functionality it exposes. An operator invokes a function by specifying its class ID and function ID, along with any required parameters.
Table 3: RemotePE commands with their RTTI class names
Internal class name
Class ID
Function ID
Description
IConfigProfile
0
0
Get the current C2 configuration
1
Set the C2 configuration
IConsole
1
0
Get the current working directory
1
Change the current working directory
2
Execute a command and return its output
3
Get loaded modules (DLLs)
4
Register a new module (DLL)
5
Invoke a registered module’s function pointer with arguments
6
Unload a module (DLL)
IFileExplorer
2
0
Get information on the drives of the system
1
List the files in a directory
2
Delete a file
3
Rename a file
4
Read from a file
5
Write to a file
6
ZIP a file or directory and return it as data
IProcess
3
0
Get process listing
1
Kill process by ID
2
Search for a file in the directories of a given environment variable
3
Create a process
4
Create a process as a user
ITimer
4
0
Sleep for X minutes, non-persistent
1
Sleep for X minutes, and persist this also in the C2 configuration on disk
2
Exit RemotePE
IPing
5
N/a
A no-op command
Most commands provide standard RAT functionality. One notable exception is the file deletion command, which overwrites each file with constant bytes seven times before renaming and deleting it, a secure deletion pattern consistent with PondRAT and POOLRAT, two malware families previously associated with this actor. Unlike some implementations that overwrite with random bytes, RemotePE uses constant bytes, though the multi-pass overwrite and rename pattern is shared.
RemotePE also implements a plugin system that allows the operator to dynamically register DLL payloads at runtime. These payloads must be valid both as a Windows DLL and as reflective shellcode, with the DLL entry point re-executed to unload them: a dual-format requirement and unload behaviour that matches pe_to_shellcode12 , which refers to such payloads as “shellcodified DLLs”. RemotePE can hold multiple plugins simultaneously, which the operator can invoke via the IConsole commands described above.
C2 Protocol
Similar to RemotePELoader, the IChannelController thread begins by locating an active C2 server via a check-in request, then polls it in a loop. The request format is largely identical to that of RemotePELoader, with one exception: RemotePE uses the MUID cookie instead of MS0, which the C2 server likely uses to differentiate between the two families. Session handling is identical to RemotePELoader. For a full description of cookie fields, see the RemotePELoader C2 Communication section.
Though RemotePE communicates with the same C2 server as RemotePELoader, the protocol diverges after the initial check-in. The outer message structure is identical to RemotePELoader’s C2Message (seed, AES-GCM tag, and ciphertext). The decrypted ciphertext, however, contains a RemotePE-specific structure, see Listing 5.
struct C2Command {
uint32_t payload_size;
uint16_t class_id; // class ID from the commands table
uint16_t function_id; // function ID from the commands table
uint32_t request_id; // used to match responses
unsigned char payload[]; // variable length, payload_size bytes
};
struct C2CommandBatch {
uint16_t command_count;
C2Command commands[]; // variable length, command_count entries
};
Listing 5: RemotePE C2 command structures
Command responses sent back to the server use the structures defined in Listing 6.
struct C2CommandResponse {
uint32_t response_size;
uint32_t error; // error code, if any
uint32_t request_id; // used to respond to a C2Command request
unsigned char payload[]; // variable length, compressed, response_size bytes
};
struct C2CommandResponseBatch {
uint16_t command_count;
C2CommandResponse commands[]; // variable length, command_count entries
};
Listing 6: RemotePE command output structures
When IChannelController receives a C2CommandBatch, it decrypts it and pushes the commands to the queue consumed by IMiddleController, as described in the Control Flow section. Command output is compressed using MSZIP via the Windows Cabinet compression API (cabinet.dll).
Figure 5: RemotePE command parsing
Figure 5 shows the C2 server command parsing of the IMiddleController thread. At first, command batches can be delimited by the “$”, where each command of a batch is traversed. After running the commands, all command outputs that were not run as a separate thread are merged into a C2 reply that is sent back to the server.
Command output is compressed, and the whole C2CommandResponseBatch structure is AES-GCM encrypted and Base64-encoded, before being sent back to the C2 server in the armAuthorization JSON key. An example of this is shown in Figure 6. The JSON keys and HTTP cookie names used within the C2 protocol, e.g., armAuthorization, odata.metadata, and MSFPC are also used within the Microsoft ecosystem.
Figure 6: RemotePE returning command output to the C2 server via the armAuthorization JSON key
A example Python script to decrypt C2 command responses can be found here:
Figure 7: Example of a decrypted C2 command response
Retrieved Samples
We obtained four RemotePE samples: three retrieved from active C2 servers and one recovered through forensic analysis. The C2 servers were identified during the incident response engagement or through fingerprinting. Ordering the samples by PE compile timestamp reveals incremental changes across versions, primarily in the config loading mechanism and bot identification method, suggesting active development between mid-2023 and mid-2024.
PE timestamp
Config loading
Bot ID
2023-07-04
Find DPAPI encrypted config on disk
SOFTWARE\Microsoft\SQMClient\MachineId
2023-10-17
C2 URLs passed via lpThreadParameter, fixed User-Agent
SOFTWARE\Microsoft\SQMClient\MachineId
2024-04-18
Find DPAPI encrypted config on disk
SOFTWARE\Microsoft\SQMClient\MachineId
2024-05-11
DPAPI config path passed via lpThreadParameter
Software\Microsoft\Cryptography\MachineGuid
Table 4: Observed RemotePE samples by PE timestamp
The 2023-10-17 sample does not use DPAPI and instead receives its C2 urls directly via lpThreadParameter, parsed using CommandLineToArgvW. Unlike the other samples, it also performs HellsGate syscall resolution and ETW patching itself, rather than relying on RemotePELoader to do so. This suggests that early versions of RemotePE were more standalone and not exclusively tied to the DPAPILoader/RemotePELoader chain, capable of being deployed by any loader passing the configuration as a thread parameter.
The table below shows the time between our initial check-in and RemotePE payload delivery across six successful retrieval sessions, along with the payload delivery time converted to Korea Standard Time (KST, UTC+9).
C2 session started (UTC)
Payload returned (UTC)
Delta
Payload returned (KST,UTC+9)
2024-02-07 00:21
2024-02-07 01:09
48 min
2024-02-07 10:09
2024-12-09 08:48
2024-12-09 09:08
20 min
2024-12-09 18:08
2024-12-10 23:57
2024-12-11 00:46
49 min
2024-12-11 09:46
2025-01-10 08:21
2025-01-10 08:21
0 min
2025-01-10 17:21
2025-02-10 21:56
2025-02-10 23:03
67 min
2025-02-11 08:03
2025-07-09 11:57
2025-07-10 07:50
20 hrs
2025-07-10 16:50
Table 5: RemotePELoader C2 session and RemotePE payload delivery timestamps
Many other sessions yielded no payload. All six successful payload deliveries fall within daytime hours in the UTC+9 timezone (08:00–19:00 KST), as shown in Table 5.
Infrastructure
The RemotePE C2 infrastructure is hosted on Namecheap shared hosting, consistent with what we observed in earlier campaigns involving ThemeForestRAT and PondRAT. As with those campaigns, the use of shared hosting makes IP-based blocking ineffective, since the same server hosts legitimate domains.
Through fingerprinting of C2 server characteristics, we identified additional domains and servers beyond those found during the incident response engagement. These are listed in the IOCs section.
At the time of writing, several C2 servers we identified never returned a payload during our emulated sessions, though some remain live. Others that had previously delivered RemotePE appear to no longer do so. Whether this reflects the infrastructure going dormant, being abandoned, a change in C2 protocol, or the actor detecting unexpected connections is unclear.
Conclusion
The DPAPILoader, RemotePELoader, and RemotePE toolset represents a deliberate effort to minimise forensic footprint. A RemotePELoader sample from disk uploaded to VirusTotal is useless without the victim’s DPAPI keys. Furthermore, by combining environmental keying via DPAPI with fully in-memory execution of the final payload, the actor ensures that forensic imaging of the disk will not yield recoverable artifacts of RemotePE.
The actor-in-the-loop delivery model and the toolset’s low detection rate (neither RemotePELoader nor RemotePE appeared on VirusTotal prior to this publication) suggest this toolset may be reserved for high-value targets where long-term, stealthy access is the objective, consistent with this Lazarus subgroup’s known focus on financial and cryptocurrency organisations.
Defenders should focus on host-based detection. The most reliable indicators are DPAPI-encrypted blobs in unexpected directories, in our case this was the DeviceMetadataStore directory, though this can vary. Another indicator is to look for suspicious DLLs masquerading as legitimate Windows services or sideloaded DLLs.
For network-based detection, SNI fields and DNS queries for known C2 domains are the most actionable opportunities. Pivoting on Namecheap shared hosting infrastructure also proved effective in identifying additional malicious C2 servers during our investigation. Organisations with TLS inspection can detect the characteristic cookie fields and JSON keys, though care should be taken to avoid false positives given the traffic’s close resemblance to legitimate Microsoft traffic.
We are sharing the samples, including decrypted versions that would otherwise remain inaccessible due to environmental keying, both for preservation and to help defenders detect and respond to this toolset. YARA rules and IOCs are provided below.
Indicators of Compromise
If you have any questions or need assistance based on these findings, please contact Fox-IT CERT at cert@fox-it.com. For urgent matters, call 0800-FOXCERT (0800-3692378) within the Netherlands, or +31152847999 internationally to reach one of our incident responders.
Domains
Domain
First seen
Last seen
livedrivefiles[.].com
2023-07-17
2025-07-27
aes-secure[.]net
2023-09-18
*
azureglobalaccelerator[.]com
2023-09-18
*
msdeliverycontent[.]com
2024-02-19
2026-05-09
akamaicloud[.]com
2024-02-19
2025-02-14
intelcloudinsights[.]com
2024-04-13
2026-04-23
devicelinkintel[.]com
2024-08-16
*
Table 6: RemotePE(Loader) C2 domains. Entries marked with * in the “Last seen” column were still active at the time of writing.
In the past few years, Fox-IT and NCC Group have conducted multiple incident response cases involving a Lazarus subgroup that specifically targets organizations in the financial and cryptocurrency sector. This Lazarus subgroup overlaps with activity linked to AppleJeus1, Citrine Sleet2, UNC47363, and Gleaming Pisces4. This actor uses different remote access trojans (RATs) in their operations, known as PondRAT5, ThemeForestRAT and RemotePE. In this article, we analyse and discuss these three.
First, we describe an incident response case from 2024, where we observed the three RATs. This gives insights into the tactics, techniques, and procedures (TTPs) of this actor. Then, we discuss PondRAT, ThemeForestRAT and RemotePE, respectively.
PondRAT received quite some attention last year, we give a brief overview of the malware and document other similarities between PondRAT and POOLRAT (also known as SimpleTea) that have not yet been publicly documented. Secondly, we discuss ThemeForestRAT, a RAT that has been in use for at least six years now, but has not yet been discussed publicly. These two malware families were used in conjunction, where PondRAT was on disk and ThemeForestRAT seemed to only run in memory.
Lastly, we briefly describe RemotePE, a more advanced RAT of this group. We found evidence that the actor cleaned up PondRAT and ThemeForestRAT artifacts and subsequently installed RemotePE, potentially signifying a next stage in the attack. We cannot directly link RemotePE to any public malware family at the time of this writing.
In all cases, the actor used social engineering as an initial access vector. In one case, we suspect a zero-day might have been used to achieve code execution on one of the victim’s machines. We think this highlights their advanced capabilities, and with their history of activity, also shows their determination.
A Telegram from Pyongyang
In 2024, Fox-IT investigated an incident at an organisation in decentralized finance (DeFi). There, an employee’s machine was compromised through social engineering. From there, the actor performed discovery from inside the network using different RATs in combination with other tools, for example, to harvest credentials or proxy connections. Afterwards, the actor moved to a stealthier RAT, likely signifying a next stage in the attack.
In Figure 1, we provide an overview of the attack chain, where we highlight four phases of the attack:
Social engineering: the actor impersonates an existing employee of a trading company on Telegram and sets up a meeting with the victim, using fake meeting websites.
Exploitation: the victim machine gets compromised and shortly afterwards PondRAT is deployed. We are uncertain how the compromise was achieved, though we suspect a Chrome zero-day vulnerability was used.
Discovery: the actor uses various tooling to explore the victim network and observe daily activities.
Next phase: after three months, the actor removes PerfhLoader, PondRAT and ThemeForestRAT and deploys a more advanced RAT, which we named RemotePE.
Figure 1: Overview of the attack chain from a 2024 incident response case involving a Lazarus subgroup
Social Engineering
We found traces matching a social engineering technique previously described by SlowMist6. This social engineering campaign targets employees of companies active in the cryptocurrency sector by posing as employees of investment institutions on Telegram.
This Lazarus subgroup uses fake Calendly and Picktime websites, including fake websites of the organisations they impersonate. We found traces of two impersonated employees of two different companies. We did not observe any domains linked to the “Access Restricted” trick as described by SlowMist. In Figure 2, you can see a Telegram message from the actor, impersonating an existing employee of a trading company. Looking up the impersonated person, showed that the person indeed worked at the trading company.
Figure 2: Lazarus subgroup impersonating an employee at a trading company interested in the cryptocurrency sector
From the forensic data, we could not establish a clear initial access vector. We suspect a Chrome zero-day exploit was used. Although, we have no actual forensic data to back up this claim, we did notice changes in endpoint logging behaviour. Around the time of compromise, we noted a sudden decrease in the logging of the endpoint detection agent that was running on the machine. Later, Microsoft published a blogpost7, describing Citrine Sleet using a zero-day Chrome exploit to launch an evasive rootkit called FudModule8, which could explain this behaviour.
Persistence with PerfhLoader
The actor leveraged the SessionEnv service for persistence. This existing Windows service is vulnerable to phantom DLL loading9. A custom TSVIPSrv.dll can be placed inside the %SystemRoot%\System32\ directory, which SessionEnv will load upon startup. The actor placed its own loader in this directory, which we refer to as PerfhLoader. Persistence was ensured by making the service start automatically at reboot using the following command:
sc config sessionenv start=auto
The actor also modified the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SessionEnv\RequiredPrivileges registry key by adding SeDebugPrivilege and SeLoadDriverPrivilege privileges. These elevated privileges enable loading kernel drivers, which can bypass or disable Endpoint Detection and Response (EDR) tools on the compromised system.
Figure 3: PerfhLoader loaded through SessionEnv service via Phantom DLL Loading which in turn loads PondRAT or POOLRAT
In a case from 202010, this actor used the IKEEXT service for phantom DLL loading, writing PerfhLoader to the path %SystemRoot%\System32\wlbsctrl.dll. The vulnerable VIAGLT64.SYS kernel driver (CVE-2017-16237) was also used to gain SYSTEM privileges.
PerfhLoader is a simple loader that reads a file with a hardcoded filename (perfh011.dat) from its current directory, decrypts its contents, loads it into memory and executes it. In all observed cases, both PerfhLoader and the encrypted DLL were in the %SystemRoot%\System32\ folder. Normally, perfhXXX.dat files located in this folder contain Windows Performance Monitor data, which makes it blend in with normal Windows file names.
The cipher used to encrypt and decrypt the payload uses a rolling XOR key, we denote the implementation in Python code in Listing 1.
def crypt_buf(data: bytes) -> bytes:
xor_key = bytearray(range(0x10))
buf = bytearray(data)
for idx in range(len(buf)):
a = xor_key[(idx + 5) & 0xF]
b = xor_key[(idx - 3) & 0xF]
c = xor_key[(idx - 7) & 0xF]
xor_byte = a ^ b ^ c
buf[idx] ^= xor_byte
xor_key[idx & 0xF] = xor_byte
return bytes(buf)
Listing 1: Python implementation of the XOR cipher used by PerfhLoader
The decrypted content contains a DLL that PerfhLoader loads into memory using the Manual-DLL-Loader project11. Interestingly, PondRAT uses this same project for DLL loading.
Discovery
After establishing a foothold, the actor deployed various tools in combination with the RATs described earlier. These included both custom tooling and publicly available tools. Table 1 lists some of the tools we recovered that the actor used.
Tool
Tool Origin
Description
Screenshotter
Actor
A tool that takes periodic screenshots and stores them locally
Keylogger
Actor
A Windows keylogger that writes user keystrokes to a file
Chromium browser dumper
Actor
A browser dump tool that dumps Chromium-based browser cookies and credentials
Table 1: Tools observed during incident response case (public and actor-developed)
Interestingly, the Fast Reverse Proxy client we found was the same client found in the 3CX compromise by Mandiant15. This client is version 0.32.116 and is from 2020, which is remarkable. We also found traces of a Themida-packed version of Quasar17, a malware family we did not see this Lazarus subgroup use before.
The actor used PondRAT in combination with ThemeForestRAT for roughly three months, to afterwards clean up and install the more sophisticated RAT called RemotePE. We will now discuss these three RATs.
PondRAT
PondRAT is a simple RAT, which its authors seem to refer to as “firstloader”, based on the compilation metadata string objc_firstloader that is present in the macOS samples.
In our case, PondRAT was the initial access payload used to deploy other types of malware, including ThemeForestRAT. Judging from network data, apart from ThemeForestRAT activity, we observed significant activity to the PondRAT C2 server, indicating it was not just used for its loader functionality. In the incident response case from 2020 we encountered POOLRAT in combination with ThemeForestRAT. This could indicate that PondRAT is a successor of POOLRAT.
Overview
PondRAT is a straightforward RAT that allows an operator to read and write files, start processes and run shellcode. It has already been described by some vendors. As far as we know, the earliest sample is from 2021, referenced in a CISA article18. Based on PondRAT’s user-agent, we also noticed that PondRAT was used in an AppleJeus campaign Volexity wrote about19 (MSI file with hash 435c7b4fd5e1eaafcb5826a7e7c16a83). 360 Threat Intelligence Center wrote about PondRAT as well20, linking it to Lazarus and later writing about it being distributed through Python Package Index (PyPI) packages21. Vipyr Security wrote22 about malware that was dropped through malicious Python packages distributed through PyPI, which turned out to be PondRAT. Unit42 published an analysis23 of the RAT, referring to it as PondRAT and showing similarities between PondRAT and another RAT used by Lazarus: POOLRAT.
As described by Unit42, there are similarities between POOLRAT and PondRAT. There is overlap in function and class naming and both families check for successful responses in a similar way.
POOLRAT has more functionality than PondRAT. For example, POOLRAT has a configuration file for C2 servers, can timestomp24 files, can move files around, functionalities that PondRAT lacks. We think this is because there is no need for more functionality if its main function is to load other malware, allowing for a smaller code base and less maintenance.
Command and Control
PondRAT communicates over HTTP(S) with a hardcoded C2 server. Messages sent between the malware and the server are XOR-ed first and then Base64-encoded. For XORing it uses the hex-encoded key 774C71664D5D25775478607E74555462773E525E18237947355228337F433A3B.
Figure 4: PondRAT check-in request
Figure 4 contains an example check-in request to the C2 server. The tuid parameter contains the bot ID, control indicates the request type, and the payload parameter contains the encrypted check-in information. In this case, control is set to fconn, indicating it is a bot check-in, matching with the corresponding function name FConnectProxy(). When receiving a server reply starting with OK, PondRAT fetches a command from the server. For at least one Linux and macOS variant, the parameter names and string values consisted of scrambled letters, e.g. lkjyhnmiop instead of tuid and odlsjdfhw instead of fconn.
Commands
PondRAT has basic commands, such as reading and writing files and executing programs. Table 2 lists all commands and their names from the symbol data. When a bot command is executed, the response includes both the original command ID and a status code indicating either success (0x89A) or failure (0x89B).
Command ID / Status code
Symbol name
Description
0x892
csleep
Sleep
0x893
MsgDown
Read file
0x894
MsgUp
Write file
0x895
Ping
0x896
Load PE from C2 in memory
0x897
MsgRun
Launch process
0x898
MsgCmd
Execute command through the shell
0x899
Exit
0x89a
Status code indicating command succeeded
0x89b
Status code indicating command failed
0x89c
Run shellcode in process
Table 2: PondRAT command IDs and their descriptions
Windows
Only the Windows samples we analysed had support for commands 0x896 and 0x89C. The DLL loading functionality seems to be based on the open-source project “Manual-DLL-Loader”25. As a sidenote, we analysed another POOLRAT Windows sample that used the “SimplePELoader” project26.
POOLRAT’s Little Brother
As mentioned by Palo Alto’s Unit42, PondRAT has similarities with POOLRAT. There is overlap in XOR keys, function naming and class naming. However, there are more similarities. Firstly, the Windows versions of PondRAT and POOLRAT use the format string %sd.e%sc "%s > %s 2>&1" for launching a shell command. Format strings have been discussed in the past27 and this specific format string was linked to Operation Blockbuster Sequel. Furthermore, PondRAT has a peculiar way of generating its bot ID, see the decompiled code below.
Figure 5: Bot ID generation for PondRAT (left) and POOLRAT (right)
Figure 5 shows how PondRAT and POOLRAT compute their bot ID. For PondRAT, tuid is the bot ID. It computes two parts of a 32-bit integer, that are split in two based on the bit_shift variable. Some of the POOLRAT samples compute the bot ID in a similar manner. The sample 6f2f61783a4a59449db4ba37211fa331 has symbol information available and contains a function named GenerateSessionId() that has this same logic.
More similarities can be found as part of the C2 protocol. PondRAT provides feedback to commands issued by the C2 server by returning the command ID concatenated with the status code. POOLRAT uses the same concept, see Figure 6.
Figure 6: Command status concatenation for PondRAT (left) and POOLRAT (right)
Another similarity can be found when comparing the Windows versions of POOLRAT and PondRAT. When running a Shell command (command ID 0x898) with PondRAT, the Windows version creates a temporary file with the prefix TLT in which it saves the command output. Then, it reads the file and sends the contents back to the C2 server and subsequently removes it. However, the way it removes the temporary file is remarkable.
It generates a buffer with random bytes and overwrites the file contents with it. Then, it renames the file 27 times, replacing all letters with only A’s, then B’s, etc. and with the last iteration renames all letters with random uppercase letters. For instance, when the file C:\Windows\Temp\tlt1bd8.tmp is deleted, it would first be renamed to C:\Windows\Temp\AAAAAAA.AAA, then to C:\Windows\Temp\BBBBBBB.BBB, and lastly to something like VYLDVAP.XQA. POOLRAT’s Windows version has the same functionality, see Figure 7.
Figure 7: Windows file name generation for PondRAT (left) and POOLRAT (right)
These similarities show that apart from variable data and symbol names, PondRAT is similar to POOLRAT in coding concepts as well. This further strengthens the connection between the two.
Summary
PondRAT is a simple RAT. Judging from the symbol data of macOS samples, its authors seem to refer to the malware as firstloader, a RAT that targets all three major operating systems. In our case, we observed it in combination with social engineering campaigns, whereas others have seen PondRAT being dropped through malicious software packages. Despite being simple in nature, it seems to do the job, given the frequency in which it is used. Judging from past incidents we investigated, PondRAT is a successor of POOLRAT.
Run, ThemeForest, Run!
In two incident response cases we found traces of a different RAT being used in conjunction with POOLRAT or PondRAT. We named it ThemeForestRAT, based on the substring ThemeForest which it uses in its C2 protocol. It is written in C++ and contains class names such as CServer, CJobManager, CSocketEx, CZipper and CUsbMan. ThemeForestRAT has more functionalities compared to PondRAT and POOLRAT.
In an earlier incident response case in 2020, we observed ThemeForestRAT in combination with POOLRAT. In the case from 2024, we observed it together with PondRAT. Its continued activity over at least five years demonstrates that ThemeForestRAT remains a relevant and capable tool for this actor. Besides Windows, we have observed Linux and macOS versions of the malware.
We believe that on Windows, this RAT is injected and executed in memory only, for example via PondRAT, or a dedicated loader, and is used as stealthier second-stage RAT with more functionality. The fact there are no direct samples of ThemeForestRAT on VirusTotal indicates it is quite successful in staying under the radar.
Overview
On startup, ThemeForestRAT attempts to read the configuration file from disk. When absent, it generates a unique bot ID and uses the hardcoded C2 configuration settings in the binary to create the configuration file.
Interestingly, the Windows variant creates two Windows events and accompanying threads that are used for signalling purposes (see Figure 8). However, the first thread related to the class CUsbMan only creates the temporary directory Z802056 and returns, this turned out to be legacy code as we will describe later.
The second thread monitors for new Remote Desktop (RDP) sessions and notifies the main thread when one is detected. Additionally, the thread checks for new physical console sessions and can optionally spawn extra commands under this session if this is enabled in the configuration.
Figure 8: ThemeForestRAT startup code creating two Windows events and threads for signalling
After creating these two threads it hibernates before connecting to the C2 server. The default hibernation period is three minutes but when it runs for the first time it checks in immediately. There are two cases where ThemeForestRAT wakes up from hibernation, either the hibernation period has passed, or one of the two events is signalled.
When it wakes up from hibernation it randomly selects a C2 server from its list and attempts to establish a connection. Upon receiving a response:OK acknowledgment, it downloads a 4-byte file that must decrypt to the 32-bit constant 0x20191127 to establish a valid C2 session. If this fails it will retry a different C2 and start over again, when the list of servers is exhausted it will go back into hibernation and try again later.
If it succeeds in establishing a C2 session, ThemeForestRAT sends basic system information including its wake-up reason to the C2 server, and the operator can now interact with the RAT as it keeps polling for new commands. When the operator sends an OnTerminate or OnSleep command (see Table 4), the C2 session ends, and the RAT goes back to hibernation.
Listing 2: ThemeForestRAT system information structure that is sent after establishing a C2 session
Listing 2 shows the structure definitions that ThemeForestRAT uses for sending system information when establishing a C2 session. The job_id field indicates the OS type, 0x10005 for Windows, and 0x20005 for both Linux and macOS as they share the same structure.
Configuration
The configuration file of ThemeForestRAT is encrypted with RC4 using the hex-encoded key 201A192D838F4853E300 and contains the following settings:
64-bit unique bot ID
List of ten C2 server URLs
Command interpreter, for example cmd.exe (not used)
List of optional commands to execute under the user of the active console session (Windows only, empty by default)
Matching array to enable the optional console command
Last check-in timestamp
Hibernation time between C2 sessions in minutes, default value is 3
C2 callback settings, for example to immediately check in on a new active RDP connection
The configuration can be parsed using the C structure definition from Listing 3.
Listing 3: ThemeForestRAT configuration structure definition for Windows
The configuration path that the RAT reads from disk is hardcoded. On macOS and Linux, this is an absolute path, while on Windows it looks in the current working directory where the RAT is launched. In Table 3 we list the observed configuration paths and hardcoded configuration file sizes for ThemeForestRAT.
Operating system
ThemeForestRAT configuration file on disk
File size
Windows
netraid.inf
43048 bytes
Linux
/var/crash/cups
43044 bytes
macOS
/private/etc/imap
43044 bytes
Table 3: Observed ThemeForestRAT configuration paths and their file sizes on Windows, Linux and macOS
Command and Control
ThemeForestRAT communicates over HTTP(S). The filenames it uses for retrieving commands from the C2 server are prefixed with ThemeForest_. The response data is sent back to the operator as a file prefixed with Thumb_, see Figure 6. On Windows it uses the Ryeol Http Client28 library for HTTP communications, and on macOS and Linux it uses libcurl. ThemeForestRAT has a single hardcoded C2 in the binary, but its configuration can be updated by sending the SetInfo command.
Figure 9: ThemeForestRAT sending encrypted system information to C2 server on initial check-in
Commands
In terms of command functionality, ThemeForestRAT supports over twenty commands, at least twice as much as PondRAT. The Linux and macOS versions contain debug symbols, which allows us to map the command IDs to function names where available.
Symbol name
Command ID
Description
ListDrives
0x10001000
Get list of drives
CServer::OnFileBrowse
0x10001001
Get directory listing
CServer::OnFileCopy
0x10001002
Copy file from source to destination on victim machine
CServer::OnFileDelete
0x10001003
Delete a file
FileDeleteSecure
0x10001004
Delete a file securely
CServer::OnFileUpload
0x10001005
Open a file for writing on victim machine
CServer::FileDownload
0x10001006
Download file from victim machine
Run
0x10001007
Execute a command and return the exit code
CServer::OnChfTime
0x10001008
Timestomp file based on another file on disk
–
0x10001009
–
CServer::OnTestConn
0x1000100a
Test TCP connection to host and port
CServer::OnCmdRun
0x1000100b
Run command in background and return output
CServer::OnSleep
0x1000100c
Hibernate for X seconds, this will also be saved in the configuration file
CServer::OnViewProcess
0x1000100d
Get process listing
CServer::OnKillProcess
0x1000100e
Kill process by process ID
–
0x1000100f
–
CServer::OnFileProperty
0x10001010
Get file properties
CServer::OnGetInfo
0x10001011
Get current RAT configuration
CServer::OnSetInfo
0x10001012
Update and save RAT configuration file
CServer::OnZipDownload
0x10001013
Download a directory or file as a compressed Zip file
CServer::OnTerminate
0x10001014
Flush configuration to disk and hibernate until next wake up
(Data)
0x10001015
Data
(JobSuccess)
0x10001016
Job succeeded
(JobFailed)
0x10001017
Job failed
GetServiceName
0x10001018
Return current service name
CleanupAndExit
0x10001019
Remove persistence, configuration file, and terminate RAT
RecvMsg
0x1000101a
Force C2 check-in
RunAs
0x1000101b
Spawn a process under the user token of given Windows Terminal Services session
–
0x1000101c
–
WriteRandomData
0x1000101d
Write random data to file handle
CServer::OnInjectShellcode
0x1000101e
Inject shellcode into process ID
Table 4: ThemeForestRAT command IDs and their descriptions
Note that the symbol names in Table 4 that start with CServer:: are from the debug symbols and the other names are deduced based on analysis of the command.
Shellcode Injection
On Windows, the CServer::OnInjectShellcode command injects shellcode into a given process ID using NtOpenProcess, NtAllocateVirtualMemory, NtWriteVirtualMemory and RtlCreateUserThread Windows API calls. The shellcode is encrypted using the same algorithm used in PerfhLoader (see Listing 1). In the macOS and Linux samples we have analysed, this command is defined as an empty stub.
RomeoGolf’s Little Brother
In 2016, Novetta released a detailed report called Operation Blockbuster29, in which a Novetta-led coalition of security companies analysed malware samples from multiple cybersecurity incidents. The investigation linked the 2014 Sony Pictures attack to the Lazarus Group and revealed that the same actor had been behind numerous other attacks against government, military, and commercial targets using related malware since 2009.
Operation Blockbuster’s malware report describes RomeoGolf, a RAT that resembles ThemeForestRAT in several ways:
Uses the temporary folder Z802056, although not used in ThemeForestRAT, is still created
Overlapping command IDs and functionality
Same unique identifier generation using 4 calls to rand()
Configuration file with extension *.inf on Windows
Timestomping of the configuration file based on mspaint.exe
Two signalling threads for USB and RDP events
Figure 10 shows the RomeoGolf startup logic for generating its bot ID and two signalling threads that is identical to ThemeForestRAT (see Figure 5).
Figure 10: RomeoGolf startup creates two signalling threads, comparable to ThemeForestRAT (see Figure 5).
As can be seen in Table 5, the functionality to detect and copy data from newly attached logical drives has been removed in ThemeForestRAT, while leaving the temporary directory creation intact. Also, the thread to check for new RDP sessions has been extended in ThemeForestRAT to optionally spawn up to ten extra configured commands under the user of the active physical console session.
RomeoGolf
ThemeForestRAT
Compilation date
Fri Oct 11 01:20:48 2013
Thu Sep 07 06:40:40 2023
Known configuration file
crkdf32.inf
netraid.inf
Configuration file timestomped to
mspaint.exe
mspaint.exe
USB thread logic
1. Creates %TEMP%\Z802056 2. Checks for newly attached drives and copies data to above folder 3. Signal on newly attached drives
1. Creates %TEMP%\Z802056
RDP thread logic
1. Signal on new active RDP sessions
1. Start configured commands under the user of the new active console session 2. Signal on new active RDP session if configured
C2 communication
Fake TLS
HTTP(S)
Highest known command id
0x10001013
0x1000101e
Table 5: Differences and similarities between RomeoGolf and ThemeForestRAT
While RomeoGolf used Fake TLS30 and its own custom server for its C2 communications, ThemeForestRAT uses the HTTP protocol and shared hosting for its C2 servers.
Onto the next stage with RemotePE
In the 2024 incident response case, we observed the actor cleaning up PondRAT and ThemeForestRAT, to deploy a more advanced RAT, which we named RemotePE. RemotePE is retrieved from a C2 server by RemotePELoader. RemotePELoader is encrypted on disk using Window’s Data Protection API (DPAPI) and is loaded by DPAPILoader. Using DPAPI enables environmental keying and makes it difficult to recover the original payload without access to the machine. DPAPILoader was made persistent through a created Windows service.
Figure 10: RemotePELoader check-in request to retrieve RemotePE payload
In Figure 10, we show a RemotePELoader check-in request used to retrieve RemotePE from the C2 server. RemotePE is written in C++ and is more advanced and elegant. We think that the actor uses this more sophisticated RAT for interesting or high-value targets that require a higher degree of operational security. Interestingly, it too uses the file renaming strategy PondRAT and POOLRAT Windows samples implement, except it skips the last random iteration.
We will publish a more thorough analysis of RemotePE in a future blogpost.
Summary
This blog is about a Lazarus subgroup that we have encountered multiple times during incident response engagements. This is a capable, patient, financially motivated actor who remains a legitimate threat.
We first discussed an incident response case from 2024, where this actor impersonated employees of trading companies to establish contact with potential victims. Though the method of achieving initial access remains unknown, we suspect a Chrome zero-day was used.
After initial access, two RATs were used in combination: PondRAT and ThemeForestRAT. Though PondRAT has already been discussed, there are no public analyses of ThemeForestRAT at the time of writing. For persistence, phantom DLL loading was used in conjunction with a custom loader called PerfhLoader.
PondRAT is a primitive RAT that provides little flexibility, however, as an initial payload it achieves its purpose. It has similarities with POOLRAT/SimpleTea. For more complex tasks, the actor uses ThemeForestRAT, which has more functionality and stays under the radar as it is loaded into memory only.
Lastly, we found the actor replaced ThemeForestRAT and PondRAT with the more advanced RemotePE. A detailed analysis of RemotePE will be published in the near future. So, stay tuned!
In Table 6 and 7, we list indicators of compromise related to the incident response cases we investigated and other artifacts we link to this actor.
Incident Response Support
If you have any questions or need assistance based on these findings, please contact Fox-IT CERT at cert@fox-it.com. For urgent matters, call 0800-FOXCERT (0800-3692378) within the Netherlands, or +31152847999 internationally to reach one of our incident responders.
Indicators of Compromise
Type
Indicator
Comment
net.domain
calendly[.]live
Fake calendly.com
net.domain
picktime[.]live
Fake picktime.com
net.domain
oncehub[.]co
Fake oncehub.com
net.domain
go.oncehub[.]co
Fake oncehub.com
net.domain
dpkgrepo[.]com
Potentially related to Chrome exploitation
net.domain
pypilibrary[.]com
Unknown, visited by msiexec.exe shortly after dpkgrepo[.]com
net.domain
pypistorage[.]com
Unknown, connection seen under SessionEnv service
net.domain
keondigital[.]com
LPEClient server, connection seen under SessionEnv service
AI Threat Report: How Artificial Intelligence Is Used Across Illicit Communities
A monthly analysis of how artificial intelligence is used in illicit communities, based on Flashpoint proprietary intelligence and direct visibility into real threat actor environments.
A finance employee joins a video call with their CFO and several colleagues. The request is routine. The faces match. The voices sound authentic. Minutes later, $25 million is transferred—only to be discovered later that every participant on the call, except one, was AI-generated.
Techniques behind incidents like this—synthetic video, voice cloning, scripted interactions—are now being discussed openly in the same environments where threat actors exchange tools and methods. In April 2026 alone, Flashpoint analysts identified 2,328,958 posts discussing artificial intelligence in the context of illicit activity.
This volume reflects a larger shift: artificial intelligence is now deeply embedded across cybercrime ecosystems, influencing fraud, impersonation, social engineering, and access operations at scale. It shows up in how content is generated, how identities are replicated, and how workflows are executed and refined over time.
That’s why we created the monthly AI Threat Report to examine how threat actors are using artificial intelligence in real-world illicit environments. Drawing on Flashpoint proprietary intelligence and direct visibility into primary source communities across forums, marketplaces, and chat services, the report analyzes the tactics, tools, and operational patterns shaping malicious AI use. Analysis of April’s activity shows a focus on prompt-sharing, jailbreak methods, and alternative models that support fewer safeguards or moderation controls.
AI Activity Volume and What It Represents
In April 2026, Flashpoint analysts identified 2,328,958 posts discussing artificial intelligence in the context of illicit activity across forums, marketplaces, and chat services.
Mentions of AI in conjunction with illicit advertisements and discussions in April 2026. (Source: Flashpoint)
The underlying activity was concentrated around a familiar set of use cases and workflows:
identity verification bypass
fraud enablement and scripting
impersonation through synthetic media
prompt-sharing and jailbreak workflows
However, the emphasis within those discussions shifted in several places in April.
Posts tied to custom malicious LLM development appeared less frequently than discussions centered on usability: how to bypass safeguards, generate more reliable outputs, or move activity onto platforms perceived as less restrictive.
References to alternative models and prompt collections appeared more often throughout the month, alongside requests for jailbreak methods and phishing-oriented outputs.
This activity points to a more mature stage of adoption. The focus is less on building entirely new tooling and more on improving reliability, portability, and ease of use within workflows that already exist.
That pattern shows up repeatedly across monitored sources. Users exchange prompts, repost working methods, and refine outputs through direct feedback. In many cases, the same underlying techniques continue circulating with only minor changes between platforms or communities.Looking across April activity helps identify which methods continue to generate demand, where threat actors are adapting around platform restrictions, and which workflows remain active across multiple environments.
Where AI Activity Is Concentrated
AI-related activity in April remained concentrated on a small number of platforms, though the distribution shifted noticeably compared to March.
Telegram accounted for the majority of observed activity, with 1,395,075 posts tied to AI services and discussions. Reddit, GitHub Gist, Pastebin, Discord, and smaller forums accounted for significantly lower volumes.
Posts selling AI services (in red) and posts seeking to purchase AI services (in blue) on Telegram in April 2026. (Source: Flashpoint)
The lower Telegram volume does not indicate reduced interest in AI-enabled activity. The platform continues to function as a primary distribution layer for prompts, jailbreak methods, fraud tooling, and service advertisements.
Across April, the same prompts, offers, and workflows appeared repeatedly across channels, often reposted with only minor adjustments. Sellers updated listings based on user feedback, while buyers requested revisions tied to specific outputs or platforms.
Other platforms served more targeted roles:
GitHub Gist and paste sites hosted scripts or supporting material
forums supported reputation building and longer technical discussions
Discord communities centered around specific models, prompt collections, or jailbreak workflows
The activity remains connected across environments. Methods introduced in one community frequently reappear elsewhere, particularly when they produce reliable outputs or help users work around moderation controls.Tracking how these discussions move between sources helps identify which workflows continue to gain traction and which techniques are becoming more broadly operationalized.
AI-Enabled Fraud and Identity Verification Bypass
Across April, Flashpoint analysts observed 63,763 posts advertising or discussing KYC bypass methods using artificial intelligence, including deepfake-enabled verification workflows.
The methods were active across Telegram channels dedicated to identity verification bypass services.
Posts continued to advertise:
synthetic video generation designed to mimic live verification behavior
voice cloning and scripted interaction prompts
bundled “KYC bypass kits” tailored to onboarding and verification workflows
Some offerings included guidance on how to adapt responses for specific platforms or verification requirements. Others promoted combinations of synthetic video, matching fake documentation, and AI-generated scripts designed to support impersonation attempts from start to finish.
The broader workflow remains consistent. AI supports how identities are replicated, how verification checks are navigated, and how fraud operations are scaled across different services.
This activity connects directly to the wider access ecosystem already observed across illicit communities. Stolen credentials, session tokens, phishing infrastructure, and AI-enabled impersonation methods increasingly operate alongside one another within the same workflows.
Across April, posts tied to these methods continued to show active refinement through user feedback, reposting, and platform-specific variations.
For security teams, this activity remains relevant at the control layer. Verification systems, onboarding workflows, and account recovery processes continue to be tested in the same environments where these methods are exchanged and improved.
Malicious LLM Usage and Prompt-Based Workflows
Across April, discussions tied to malicious or unrestricted LLM usage focused heavily on jailbreak methods, prompt-sharing workflows, and access to alternative models perceived as less restricted than mainstream platforms.
The top observed malicious LLMs mentioned within Flashpoint Collections in April 2026. (Source: Flashpoint)
Flashpoint analysts observed a significant increase in discussions related to VeniceAI, driven in part by newly created Reddit and Discord communities dedicated to the platform. The increase highlights continued interest in models that users believe operate with fewer safeguards or moderation controls than services like ChatGPT or Gemini.
The activity centers on usability and output reliability.
Posts reference:
jailbreak prompts designed to bypass safeguards
phishing and fraud-oriented prompt collections
step-by-step instructions for generating specific outputs
requests for prompts tailored to impersonation or social engineering workflows
Many of these prompts are shared in collections that include updates, revisions, or support channels. Users exchange feedback when prompts stop working, outputs degrade, or platforms introduce new restrictions. Updated versions frequently follow within short timeframes.
This type of activity reinforces how prompt engineering has developed into its own service layer across illicit communities. The focus is not limited to the underlying model itself, but to the ability to generate repeatable outputs that can be applied directly within fraud, phishing, or impersonation workflows.
Across April, the same prompt structures and jailbreak methods appeared repeatedly across multiple sources, often with only small adjustments tied to platform or target.
The emphasis remains on accessibility, portability, and ease of use rather than custom model development.
Operational Patterns and What Holds Across Sources
Across April, the same behaviors continued to appear across different environments with only minor variation.
Prompt libraries, jailbreak methods, phishing workflows, and identity verification bypass techniques circulated across Telegram channels, forums, Discord communities, and paste sites. The wording changed slightly between platforms, though the underlying structure and outputs remained consistent.
This reuse is visible in how content moves between sources. A jailbreak prompt shared in one channel appears elsewhere with revised wording or additional instructions. A phishing workflow posted to a forum is copied into a paste site and redistributed through Telegram. Users request modifications, test outputs, and repost updated versions when restrictions change or methods stop working.
That cycle appeared repeatedly throughout April.
The activity also showed strong feedback loops tied to usability. Discussions focused heavily on which prompts generated reliable outputs, which models produced fewer restrictions, and which workflows required the least adjustment before use.
Across monitored sources, the same operational priorities appeared consistently:
reliability of outputs
ease of reuse
ability to bypass safeguards
compatibility with existing fraud and impersonation workflows
Looking across April activity reinforces how AI-enabled methods continue to mature through repetition, iteration, and distribution across connected communities.
What Security Teams Should Take Away
The activity tracked in this report shows how artificial intelligence is being used in environments where techniques are developed, tested, and shared before they surface elsewhere.
Across these communities, methods tied to fraud, impersonation, and access are reused, adjusted, and circulated in forms that others can apply directly. That process does not require significant change to move from discussion into use.
For security teams, the priority is maintaining visibility into how these methods are evolving and where they are being applied. That visibility supports earlier detection, more focused response, and a clearer understanding of which techniques are actively in circulation.
Monitoring these sources provides that context. It connects observed activity to the methods behind it and helps teams track how those methods develop over time.
If you want to see how this activity maps to your environment, request a demo.
Over the past few weeks, we have reached a critical turning point in cybersecurity. Following the launch of our Frontier AI Defense initiative, we’ve continued testing the latest frontier models (including Anthropic’s Mythos and Claude Opus 4.7, as well as OpenAI’s GPT-5.5-Cyber) as part of the Trusted Access for Cyber program.
The urgency to innovate continues to ramp up. As Lee Klarich recently detailed in his Defender's Guide to the Frontier AI Impact on Cybersecurity, our current landscape is defined by a brief three-to-five-month window to gain a strategic advantage over attackers. To outsmart AI-based exploits, enterprises must decisively address vulnerabilities across their code and stand up the right security stack to enable real-time, automated defenses.
With such a ticking clock in front of us, acting rapidly and at-scale to support our customers is paramount. Today, we exponentially grow our scale of delivery by expanding our Frontier AI Alliance.
Since introducing this initiative, our collaboration with initial partners – Accenture, Deloitte, IBM, NTT DATA, and PwC – has already begun changing the defensive math for our customers. This is a moment that calls for radical collaboration across the entire security ecosystem, so today we are proud to welcome a new cohort of strategic partners – Cognizant, HCLTech, Kyndryl, TCS, Infosys, McKinsey & Company, Orange Cyberdefense, and Wipro – who will join us in delivering AI readiness at scale.
While this expansion significantly increases our reach, this is only the beginning. We are committed to a continuous evolution of this alliance and will be adding more critical partners in the future across the globe to ensure our customers have the most robust defense network possible.
By combining our technology with these partners’ deep consulting expertise, we are delivering:
Machine-Speed Security: Natively integrating Frontier AI to provide real-time, automated defense against autonomous threats.
Intelligence-Led Resilience: Leveraging Unit 42® experts to fast-track the discovery and remediation of exposures at machine speed.
Hardened Defenses: Utilizing early access to frontier models from partners like OpenAI and Anthropic to simulate and block attack chains before they hit the mainstream.
The stakes are high. The attack cycle has compressed with the time from initial access to data exfiltration collapsing to just 39 seconds. Machine-speed MTTR (mean time to respond) is no longer an ambitious goal, it is a requirement.
This initiative underscores our commitment to providing every client with integrated, real-time protection.
This blog contains forward-looking statements that involve risks, uncertainties and assumptions, including, without limitation, statements regarding the benefits, impact, or performance or potential benefits, impact or performance of our products and technologies or future products and technologies. These forward-looking statements are not guarantees of future performance, and there are a significant number of factors that could cause actual results to differ materially from statements made in this blog. We identify certain important risks and uncertainties that could affect our results and performance in our most recent Annual Report on Form 10-K, our most recent Quarterly Report on Form 10-Q, and our other filings with the U.S. Securities and Exchange Commission from time-to-time, each of which are available on our website at investors.paloaltonetworks.com and on the SEC's website at www.sec.gov. All forward-looking statements in this blog are based on information available to us as of the date hereof, and we do not assume any obligation to update the forward-looking statements provided to reflect events that occur or circumstances that exist after the date on which they were made.
On May 4th, 2026, The GentlemenRaaS administrator acknowledged on underground forums that an internal backend database (Rocket) had been leaked. This leak exposed 9 accounts, including zeta88 (aka hastalamuerte), who runs the infrastructure, builds the locker and RaaS panel, manages payouts, and effectively acts as the administrator of the program.
The internal discussions provide a rare end‑to‑end view of the operation: they detail initial access paths (Fortinet and Cisco edge appliances, NTLM relay, OWA/M365 credential logs), the division of roles, the shared toolsets, and the group’s active tracking and evaluation of modern CVEs such as CVE-2024-55591, CVE-2025-32433, and CVE-2025-33073.
Screenshots from ransom negotiations were also leaked, showing a successful case where the group received 190,000 USD, after starting with an initial demand (anchor) of 250,000 USD.
Further chats indicate that stolen data from a UK software consultancy was later reused to attack a company in Turkey. The Gentlemen used this during negotiations as a dual‑pressure tactic: they portrayed the UK firm as the “access broker,” while mentioning to provide “proof” to the Turkish company that the intrusion originated from the UK side and encouraging it to consider legal action against the consultancy.
By collecting all available ransomware samples, Check Point Research identified 8 distinct affiliate TOX IDs, including the administrator’s TOX ID. This suggests that the admin not only manages the RaaS program but also actively participates in, or directly carries out, some of the infections.
Introduction
The Gentlemen ransomware‑as‑a‑service (RaaS) operation is a relatively new group that emerged around mid‑2025. Its operators advertise the service across multiple underground forums, promoting their ransomware platform and inviting penetration testers and other technically skilled actors to join as affiliates.
In 2026, based on victims listed on the data leak site (DLS), The Gentlemen appears to be one of the most active RaaS programs, with approximately 332 published victims in just the first five months of 2026. This volume places the group as the second most productive RaaS operation in that period, at least among those that publicly list their victims.
During our previous publication, Check Point Research analyzed a specific infection carried out by an affiliate of this RaaS. In that case, the affiliate used SystemBC, and the associated command‑and‑control (C&C) server revealed more than 1,570 victims.
In this publication, we focus on the affiliate program itself and the actors who participate in it. On May 4th, 2026, The Gentlemen administrator acknowledged the leak of an internal database used by the group, which contained operational information about their infrastructure, affiliates, and victims. Check Point Research obtained what appears to be a partial leak of the group’s internal chats and related data, which was briefly posted on an underground forum before being removed. Later on, the leak also appeared on another underground forum.
The leaked material includes detailed conversations between the RaaS operators and their affiliates across several internal channels (such as INFO, general, TOOLS, and PODBOR). In these chats, they coordinate ongoing intrusions, exchange toolsets and EDR‑kill packages, discuss infrastructure and backend components (including the Rocket database and NAS storage), review CVEs and exploit paths (for example Fortinet, Cisco, and NTLM relay issues), and talk about specific victims, campaigns, and payouts. Together, these messages provide a rare inside view of how The Gentlemen plans, executes, and scales its ransomware operations.
The Gentlemen RaaS Admin
The Gentlemen RaaS administrator has been very active and vocal on various underground forums, trying to attract affiliates with an aggressive profit-sharing model: 90% for affiliates and 10% for the operator.
In September 2025, in one of the first posts promoting the RaaS program, the account Zeta88 published a message advertising the service and inviting individual penetration testers to join as affiliates.
Figure 1 — Zeta88 advertising The Gentlemen’s RaaS.
Later on, the official posts for this ransomware program started to be published by another account, The Gentlemen. The administrator also shared their TOX ID across several forums.
Figure 2 — RaaS admin in underground forum.
The same TOX ID can be seen on the onion data leak site (DLS), where it is used by affiliates or compromised victims to contact the administrator.
Figure 3 — Onion page TOX ID.
In a post on an underground forum, where the administrator demonstrated how affiliates can build the ransomware, we can see the administrator’s profile page, where their TOX ID is again visible in the corresponding field.
Figure 4 — Image uploaded by RaaS admin.
In the second shared image, we again observe the same TOX ID and see how the target or victim entry is supposed to look from an affiliate’s perspective.
Figure 5 — Image uploaded by RaaS admin.
Considering that the initial post was made by Zeta88, it is likely that this account belongs to the administrator and that their TOX ID is F8E24C7F5B12CD69C44C73F438F65E9BF560ADF35EBBDF92CF9A9B84079F8F04060FF98D098E. This assessment is based on the fact that the same TOX ID appears consistently across different contexts: in the early recruitment posts, in the onion data leak site (DLS), and in the screenshots showing the administrator’s profile and communication fields. Taken together, these overlaps strongly suggest that Zeta88, the later The Gentlemen account, and this TOX ID are all controlled by the same RaaS administrator.
RaaS Affiliates
Check Point Research collected most of the available artifacts related to The Gentlemen RaaS from online sources. Based on the current 412 public victims listed on the data leak site (DLS), and considering that there are likely additional victims who paid and therefore were not published, we identified 29 unique campaigns in public sources such as VirusTotal.
For each of these 29 campaigns, we extracted the TOX ID associated with the corresponding affiliate. Our analysis shows that these campaigns were conducted by 8 unique TOX IDs.
There are almost certainly more affiliates involved in this group, however, based on our current locker visibility, we can confidently confirm 29 discovered campaigns and ransomware samples.
Based on this small collection of samples, most of the campaigns appear to have been conducted by the affiliate using the TOX ID 98C132E2B20B531BE6604397D97040C1E9EB42FCE12EDF119BCE8B4031CA5C70DAF5E65FA3C3. It is also noteworthy that the RaaS administrator’s TOX ID has been observed in four unique infections. This suggests that the administrator not only manages the RaaS program but also actively participates in, or directly carries out, some of the infections.
RaaS Leak
On May 4th, 2026, on an underground forum, the RaaS administrator published a post acknowledging the claims of an internal leak involving their so‑called Rocket database, an internal backend system used to store operational data, and addressed his affiliates directly about the incident.
Figure 6 — The Gentlemen RaaS post.
The message continues in a dismissive tone toward the leak seller and then shifts focus back to “more interesting” topics. These include a full overhaul of the communication structure, the deployment of a new NAS with unlimited storage, and several technical upgrades to the locker, such as removing hardware breakpoints, performing NTDLL unhooking, and patching ETW to suppress Event Tracing for Windows.
Demanding ransom from a RaaS
On May 5th, 2026, the account n7778 with TOX ID 7862AE03A73AAC2994A61DF1F635347F2D1731A77CACC155594C6B681D201F7AD6817AD3AB0A advertised the sale of The Gentlemen’s hacked data on underground forums for 10,000 USD, payable in Bitcoin.
Figure 7 — Account selling The Gentlemen RaaS Data.
In the following days, the same account posted two MediaFire links containing proof files supporting the claimed leak.
Figure 8 — Partial leaks.
The first leaked data is a text file that contains the contents of the shadow file from The Gentlemen’s server, including user account entries and their password hashes. The file lists many usernames, among them zeta88, 3NT3R, B1d3n, C0CA, d0wnloAd1, equal1z3r, F3N1X, Gblog88, JLL, LDW, n0n3, PRTGRS, W1Z. Notably, we again see the zeta88 account, the same handle that was used in the initial underground post advertising the RaaS program, further linking this server to the RaaS administrator.
Figure 9 — shadow file content.
The second leaked data set contains partial conversations between the RaaS operators and their affiliates across several internal channels (such as INFO, general, TOOLS, and PODBOR). In these chats, they coordinate ongoing intrusions, exchange toolsets and EDR‑kill packages, discuss infrastructure and backend components, review CVEs and exploit paths, and talk about specific victims, campaigns, and payouts.
While the partial leaked data that we obtained is around 44.4 MB, a screenshot shared by the same account on another underground forum shows a total size of approximately 16.22 GB, which likely corresponds to the full leaked data set.
Figure 10 — Full leaked data screenshot.
Roles & Structure
The group appears to have a clear division of roles and responsibilities. At the core, the main operator and developer, zeta88 (most likely hastalamuerte), runs the infrastructure and builds and maintains the custom ransomware locker, the RaaS panel and builder (Linux with containers and a TOR front), as well as the GPO‑based spread mechanism and the locker’s “spread” module. This operator also curates toolsets in the TOOLS channel, including EDR kill kits and kiljalki collections, selects targets, and assigns them to specific teams, often talking about “targets”, “подбор” (selection) channels, and distributing corporate victims to groups of 2–3 people. In addition, they manage payouts and negotiations, including multi‑million ransom discussions (“переговоры на 10кк”).
Figure 11 — Image shared in the chats, zeta88 – Admin.
Considering our previous assessment that the RaaS administrator also runs campaigns himself (based on TOX IDs), the leaked chats reinforce this view: they show him personally deploying the locker and encrypting at least one victim’s environment.
Figure 12 — zeta88 locking message.
Often, messages sent by zeta88 appear to be copied or adapted from earlier messages made by hastalamuerte, and affiliates frequently mention hastalamuerte by name. Taken together with previous findings and earlier RaaS posts linked to zeta88, these patterns strongly suggest that hastalamuerte and zeta88 are very likely the same person.
Figure 13 — zeta88 – hastalamuerte message.
Below this core role, key operators or affiliates such as qbit and quant handle more hands‑on operational work. qbit is a practical operator on many cases, responsible for scanning and filtering Fortinet VPNs and other edge devices, performing reconnaissance and persistence (including “крепиться клаудом” (English: “to establish persistence via the cloud”) through Cloudflare tunnels or Zero Trust solutions), and using tools such as NetExec (NXC), RelayKing, PrivHound, and NTLM relay scanning. qbit frequently requests clear EDR killer sets, manuals, and guidance for locking ESXi environments, and also brings in new bot or access suppliers (“поставщик ботов”) (English: “supplier of bots”). quant focuses on log‑based access (“логи ЛБ”, i.e. spilled credentials for OWA/O365 and similar services) and maintains a custom log parser and proprietary credential/data collector, referred to as buildx641, which is run from a domain‑joined machine, uses vssadmin, shadow copies, ntds.dit, and SYSTEM copies, and collects and compresses data from multiple hosts. quant is oriented toward OW/OVA spam and higher‑value (“тир1”) (English: “tier‑1”) victims and has set up a powerful “brute server” (Threadripper PRO, 128 GB RAM, RTX 5090) for large‑scale brute forcing.
Around these core and key operators, there are several other accounts, including Wick, mAst3r, Protagor, Bl0ck, JeLLy, Kunder, and Mamba who take on various roles such as red‑teamers, advertising partners, access brokers, or case‑specific collaborators; for example, Protagor is mentioned in connection with OV (online vault/OWA‑type) spam, while Mamba acts as an access broker for Fortinet VPNs sourced from ramp.
Through this specific leak, we identified 9 unique accounts actively communicating with each other: Kunder, qbit, JeLLy, Protagor, zeta88, Bl0ck, Wick, quant, and mAst3r. This internal interaction pattern supports the view that these accounts form a coordinated operational network within The Gentlemen RaaS ecosystem. This number aligns with our earlier assessment based on the unique TOX IDs extracted from the ransomware lockers.
Group members collaborate on various infections and share the profits as well. As a result, the 90% share allocated to the affiliate is often split among multiple affiliates who worked together to achieve a successful intrusion.
Figure 14 — Collaboration and profit sharing.
Based on the analyzed chat messages, the organization’s structure appears to match the model shown in the following image. It is likely that additional members exist who do not appear in this specific leak, but the roles and relationships we observe here are consistent across the available data. There are also indications of an internal separation between trusted members and newcomers—for example, one message notes that “that Rocket is still alive – there are rookies there”—suggesting a tiered or layered structure within the group.
Figure 15 — Organization diagram.
Operational workflow
The conversations from the leak show a fairly standard but well‑organized operational workflow. The group claims to usually gain initial access through exposed edge devices such as VPN appliances, firewalls, and other internet-facing systems, with a particular focus on platforms like Fortinet FortiGate and Cisco. They combine different methods to achieve this, including credential brute‑forcing against web or VPN panels, exploiting known vulnerabilities, and buying access from third‑party “bot” or access brokers. Screenshots shared in the chats also show them searching for accounts and credentials in data‑breach search engines. Once they obtain a foothold, they treat these systems as pivots to move deeper into the internal network.
Figure 16 — Searching credentials & accounts.
After gaining access, the operators perform internal reconnaissance and privilege escalation to understand the environment and obtain higher-level permissions, often aiming for domain administrator access. They rely on a mixture of Active Directory discovery, certificate abuse, and various local privilege escalation techniques. At the same time, they invest significant effort into disabling or bypassing security tools such as EDR and antivirus solutions, using a combination of misconfigurations, registry abuse, logging mechanisms, and bring-your-own-vulnerable-driver–style (BYOD) techniques to tamper with or overwrite security binaries.
With elevated access and reduced defensive visibility, the group focuses on expanding across the network and preparing for the final stages of the attack. This includes lateral movement, establishing additional tunnels or proxies for reliable connectivity, and relaxing security settings to make further operations easier. They also harvest credentials and browser-based sessions to reuse existing access to corporate services. Data exfiltration is then carried out using automated tools and tuned configurations to move large volumes of data efficiently, often targeting NAS devices, backup systems, and virtualization infrastructure. Finally, once the environment is prepared and critical data is in their control, they deploy their custom ransomware “locker,” which is designed to spread quickly across the network, leverage existing administrator sessions, and encrypt systems in a coordinated manner.
Tools & Infra
The leaked conversations show that The Gentlemen RaaS operators use a repeatable and fairly mature toolset to support their operations. For remote access and C2, they rely on frameworks like ZeroPulse and Velociraptor, combined with Cloudflare-based tunnels and custom VPN setups to keep stable access into compromised networks. For offensive operations, they use a range of red‑team utilities such as NetExec, RelayKing, TaskHound, PrivHound, CertiHound, and others to perform Active Directory discovery, certificate abuse, privilege escalation, and file share discovery. A separate group of tools is dedicated to EDR and AV evasion, including EDRStartupHinder, gfreeze, glinker, and DumpBrowserSecrets, as well as techniques inspired by public research on abusing Windows logging and Event Tracing for Windows (ETW). Finally, they support these activities with infrastructure and helper tools like port scanners (gogo.exe), usage guides, OSINT extensions, and password‑cracking services, which together give them a reusable framework for running repeated intrusions and ransomware deployments.
Category
Tool / Resource
Purpose / Usage
Reference / Notes
C2 / Remote Access
ZeroPulse
Remote access / C2 framework for controlling compromised hosts.
https://github.com/jxroot/ZeroPulse
C2 / Remote Access
Velociraptor
Used as a covert C2 platform, including memory and LSASS dumping.
Often used with signed builds to reduce detection.
C2 / Remote Access
Cloudflare Zero Trust / Tunnels
Provides stealthy tunnels into victim networks over HTTPS.
The leaked chats show that the group pays close attention to other ransomware operations, including the leaked Black Basta negotiations. In particular, they discuss Black Basta’s approach to code signing and note how that group allegedly used VirusTotal to search for legitimate code‑signing certificates, which were then targeted for brute‑force attacks on their private keys. The Gentlemen actors refer to this technique as a model they can reuse or adapt, highlighting their interest in abusing trusted certificates to make their binaries look legitimate and harder to detect.
Figure 17 — Code signing conversations.
AI mentions
The Gentlemen mention AI usage in multiple channels and for various purposes. While it is clear that they have already used AI for code‑assisted development, including experiments with Chinese models, more advanced use cases—such as locally deploying models to analyze large volumes of exfiltrated victim data—are only discussed at a conceptual level. These ideas are suggested in the chats but do not appear to be fully implemented.
zeta88 states that he built the GLOCKER admin panel in three days using AI‑assisted coding. He is candid about the limitations of this approach, noting that while AI can speed up development, you still need to understand what you are doing and be able to guide and correct the code it produces.
Figure 18 — zeta88 “vibe-coded” the Panel.
Members share their AI preferences across different chats. zeta88 states that he finds DeepSeek, Qwen, Kimi, and Emi the most effective models for his purposes, particularly for coding assistance and technical queries.
Figure 19 — AI preferences.
He also suggests adding more Chinese LLMs to their toolkit, in addition to those they are already considering or using, such as DeepSeek and Qwen.
Figure 20 — Chinese LLMs suggestions.
A couple of months later, qbit shares in the INFO channel their recommendation for “the most radical neural network, which creates any content without censorship. Runs on Qwen 3.5 with all barriers removed… Zero refusals. Absolutely no restrictions.”
Figure 21 — Qwen 3.5 post.
zeta88 directs affiliates to use AI as a quick reference—for example, to look up FortiGate internals—rather than asking in the channel.
Figure 22 — Usage of AI as quick reference.
For more challenging tasks such as operational data analysis, identifying high‑value access points, and offloading much of the manual data‑triage work to an AI model, the operators explicitly discuss using an uncensored, self‑hosted LLM. However these suggestions appear to remain theoretical, as Protagor admits, “I have no idea how to do that, but I think it’s possible.”
Figure 23 — Local, self-hosted LLM.
Screenshot shared in the chats shows an LLM response on how to send an email to all users via the Jira admin interface, in Russian. It describes two methods, mainly using Jira Automation and user groups.
Figure 24 — Screenshot shared in the chats.
The group appears to be experimenting with well‑known Chinese LLMs and has considered using locally hosted models to assist with data triage on stolen information.
CVEs and Exploits
While the group discusses these vulnerabilities, shares related links, and occasionally attempts to exploit specific systems using particular CVEs, we cannot confirm whether the targeted machines were actually vulnerable to the exact vulnerabilities they referenced.
CVE-2024-55591 – FortiOS management interface
This vulnerability affects the FortiOS management interface and fits directly into their broader focus on Fortinet appliances as high‑value initial access points. While the chats do not show detailed exploitation steps, the presence of this CVE alongside their FortiGate targeting suggests it is part of the set of vulnerabilities they track for potential use against exposed management interfaces.
In the logs, qbit shares a proof-of-concept (PoC) for CVE-2025-32433, and zeta88 comments on its quality and applicability. This shows that the group is not simply aware of the CVE but is actively evaluating whether it can be used in real operations, specifically in environments where Cisco or Erlang-based SSH services are exposed. Even if they are cautious about PoC reliability, the discussion confirms that this vulnerability is part of their potential exploit toolkit.
Figure 26 — qbit & zeta88 related posts.
CVE-2025-33073 – NTLM reflection / NTLM relay
qbit references RelayKing and shares output showing domains being scanned for NTLM relay issues, including checks that explicitly cover CVE-2025-33073. This is strong evidence that they are not just reading about the vulnerability but have integrated RelayKing into their standard reconnaissance process to generate target lists for tools like ntlmrelayx. In other words, CVE-2025-33073 is a vulnerability they actively scan for and intend to exploit as part of broader NTLM relay workflows.
Figure 27 — Mention of CVE-2025-33073.
Other Exploit Paths (Without Explicit CVE IDs)
The operators also make heavy use of technique-based exploits where no specific CVE number is mentioned in the chats. These include:
MSI service abuse via RegPwn, used for privilege escalation.
Veeam to domain admin paths, based on public write‑ups about misconfigured backup infrastructure.
iDRAC to domain admin paths, leveraging Dell iDRAC weaknesses.
WPR, AutoLogger, and ETW manipulation techniques documented by zerosalarium and others to overwrite or disable security binaries.
Payments & Negotiations
Zeta88 acts as the organizer/administrator, distributing cryptocurrency payouts to team members (including those who are “AFK”) and advising on how to cash out proceeds via Bitcoin wallets (Guarda, Trust Wallet, Exodus). The group discusses AML (Anti-Money Laundering) evasion strategies. Zeta88 sends a BTC transaction to Kunder as a payout, which Kunder confirms receiving.
Figure 28 — Transaction link shared.
The specific mentions of how they handle Bitcoin laundering/cash out:
Exchange Chains (“связки обмена”) Zeta88 mentions running ~800 transactions through “buy desks” (скупов) via exchange chains, or sometimes sending directly, suggesting chain-hopping to obscure transaction origins.
AML Checking They discuss whether their BTC is “clean” and reference a buyer who actively checks AML scores before transacting. They’re uncertain how the scoring works but are aware their coins could be traced.
Tinkoff QR Code Cash-Out A specific method mentioned: a buyer converts BTC to cash via Tinkoff bank QR codes, with minimums of 400k rubles (previously 250k). This converts crypto directly to Russian banking infrastructure.
Physical Cash Delivery Kunder mentions “locking in the rate” and a guy physically bringing cash at the end of the month, a classic peer-to-peer OTC (over-the-counter) arrangement that bypasses exchanges entirely.
Wallet Infrastructure They recommend non-custodial wallets (Guarda, Trust Wallet, Exodus) specifically to avoid KYC/AML controls that centralized exchanges enforce.
Blurry screenshots from the leak also shed light on the financial side of the operation. Although not fully legible, they appear to show a negotiation where the group secured approximately 190,000 USD after a discount of about 60,000 USD from the initial ransom demand.
Figure 29 — Agreement to pay 190,000 USD.
zeta88 is very aware of the importance of maximizing pressure on extorted victims to increase the chances of payment. In his private channel, he drafts a generic follow‑up letter that can be adapted to any company, emphasizing the costs of not paying the ransom, including regulatory exposure, reputational damage, and operational impact, and citing assessments from previous attacks. This is not the standard ransom note deployed alongside the encryption, but an additional, more tailored communication intended to reinforce the pressure on the victim.
Figure 30 — Negotiation playbook.
Interesting Negotiation Case
In a high‑profile attack in April 2026, a software consultancy company from United Kingdom publicly reported a breach. The company’s leadership stated in an open letter that only “typical business data, including business contact information, contracts, and NDAs related to client work” had been accessed.
From what appears to be a personal channel used by zeta88, he drafts a ransom demand letter addressed to the UK company, detailing what The Gentlemen claim to have exfiltrated, including customer infrastructure data, secrets, OAuth credentials, and more. The letter explicitly emphasizes potential GDPR violations as leverage to pressure the victim into paying.
Figure 31 — Ransom note.
Two weeks later, the group published the consultancy’s identity and breach details on their data leak site (DLS). According to the internal chats, data exfiltrated from the consultancy was then reused both before and during attacks against a company in Turkey, where The Gentlemen gained initial access via a vulnerable VPN appliance.
Figure 32 — Forti access to company in Turkey.
zeta88 ran this operation alongside Protagor, creating a backdoor Okta service account himself—typical of his intensive, hands‑on involvement in many of the intrusions documented in the leaked discussions. During the same campaign, zeta88 explicitly references data from the UK consultancy breach to cross‑reference and enrich information about the Turkish company, illustrating how prior compromises are used to enrich and support new attacks.
Figure 33 — UK company containing information for Turkish company.
One example mentioned was an internal “Transfer/Migration Document” (in the local language), an internal project document the consultancy maintained in its own collaboration platform describing work they did for the company in Turkey. This document, stolen in the first breach, was then used in the second.
The group discussed how best to use this access for extortion. In their internal chats, they talked about publishing the company from Turkey on their DLS together with a statement that, The access to the company in Turkey was obtained through the compromised consultancy from United Kingdom.
Figure 34 — DLS statement discussions.
This served a dual purpose:
Punishing the consultancy (UK), which the actors described as “a very bad company.”
Increasing pressure on the company in Turkey, by promising to show exactly how they gained access so that, the Turkish would be encouraged to legally pursue the consultancy in UK.
Figure 35 — Initial access proof.
Eventually, the Turkish company was published on the group’s DLS, and the attackers “credited” the consultancy in UK as their “access broker”.
Their View of Other RaaS Programs and Actors
The actors consistently frame the RaaS ecosystem through the lenses of brand strength, payout reliability, and affiliate leverage (percentage splits and control over negotiations). Among the programs mentioned, they clearly distinguish a small “top tier” from a broader landscape of lesser or untrusted players.
Program / Group
Things Discussed
Subjective Sentiment (Their View)
HelloKitty
Name/brand as something they’d like to use; jokes about linking to the real Hello Kitty site and putting (R) everywhere; described explicitly as a “мощный бренд”.
Very positive on brand strength and recognition; sees it as a powerful marketing asset.
Kraken
Mention that “товарищи кракен” wrote to qbit; qbit later says their team might “move” over to zeta88’s side.
Neutral‑pragmatic; current or past orbit, but clearly willing to switch away for better options.
Dragon Force
One of only two programs zeta88 would choose from “all presented”; explicitly says they pay both operators and adverts; only negative comments heard were about their software/panel.
Strongly positive overall; trusted, in the top tier of programs they respect.
Gunra
Listed among candidate PPs for a supplier; zeta88 says “че эт ваще такое…”, and lumps it with Hyflock; calls the operator “этот мудень”.
Negative; unserious / low‑relevance; clear disdain for the operator.
Hyflock
Same context as Gunra; zeta88 dismisses it in the same breath as Gunra, with the same derogatory comment about the person behind it.
Negative; grouped with Gunra as not to be taken seriously.
ShadowByt3$ RAAS
Appears in the candidate list; zeta88 simply comments “хз” (doesn’t know).
Neutral; no formed opinion, neither trust nor distrust expressed.
Anubis
Appears in the candidate list; zeta88 asks “% видел он?”, focusing on what percentage they take.
Cautious / skeptical; interest hinges on profit split; no clear positive trust.
CHAOS
Appears in the candidate list; zeta88 asks whether they will still take that supplier (“возьмут ли они его еще”).
Uncertain; doubts about acceptance / relationship continuity; not a clearly preferred option.
LockBit (tooling)
quant asks what a локбит тулза actually is (builder or decryptor), notes he has not opened it; no explicit evaluation of the group itself.
Curious but cautious; tooling is not trusted or fully understood yet; no explicit sentiment on LockBit group.
Black Basta / Devman
quant asks if “блек баста это девман”; zeta88 speaks harshly about “David” and his link to Devman, calls him “мудак” and “чепуха”, wishes them невыплат (non‑payment).
Strongly negative but personalized; animosity toward David/Devman rather than a structured view of the RaaS.
“Red team” / Mr Beng cluster
Mentions Редтим=красный лотос=арсен=баламут=студент and “мистер БЕНГ”; mocks offer of 15k for “source code” of a C2 built on top of white tools (Velociraptor, etc.); ridicules this as overpriced and based on legitimate software.
Negative; sees them as overpriced grifters repackaging white tools with heavy marketing.
Conclusion
The Gentlemen RaaS program has quickly evolved into a highly active and structured ransomware ecosystem. With over 320 public victims in 2026 and hundreds more systems visible through related infrastructure, it stands among the most productive RaaS operations that maintain a public data‑leak presence. The leaked Rocket backend and internal chats show that this scale is driven not by a loose crowd, but by a small, tightly coordinated core of about 9 named operators and at least 8 distinct affiliate TOX IDs, all organized around the administrator zeta88 / hastalamuerte, who both runs the platform and participates directly in operations.
The leak reveals a repeatable, human‑operated ransomware playbook: initial access through exposed edge infrastructure (such as VPNs and management interfaces), rapid expansion and privilege escalation, heavy investment in EDR/AV evasion and ETW/logging tampering, and systematic use of shared tools for discovery, lateral movement, credential theft, and data exfiltration. The group actively tracks and evaluates modern vulnerabilities, including CVE-2024-55591, CVE-2025-32433, and CVE-2025-33073and combines them with technique‑driven paths like backup and management‑controller abuse and NTLM relay workflows, giving them a flexible exploitation pipeline.
Overall, The Gentlemen exemplifies how contemporary RaaS programs blend productized ransomware with professional intrusion teams. A small, well‑organized set of operators, supported by curated tooling, structured communication channels, and up‑to‑date exploit knowledge, can generate substantial impact in a short time. For defenders, this underscores the need to harden internet‑facing services, close known misconfigurations and relay paths, and monitor for the specific tools, workflows, and TOX‑based communication patterns tied to this group.
Navigating the Threat Landscape of the 2026 FIFA World Cup
In this blog, we break down emerging threat activity, protest movements, cyber risks, and operational challenges shaping the security environment for the 2026 FIFA World Cup.
The 2026 FIFA World Cup will be unlike any tournament before it.
Set to run starting next month from June 11th to July 19th across the United States, Canada, and Mexico, this will be the first World Cup co-hosted by three nations and expanded to 48 teams across 16 host cities. More than five million fans are expected to attend matches in person, with billions more engaging globally.
That scale introduces a different class of risk. The World Cup is a distributed, high-visibility global operation spanning stadiums, transit systems, hotels, fan festivals, and digital infrastructure.
At the time of writing, Flashpoint analysts have not identified any specific, credible threats targeting the tournament. However, recent extremist propaganda and geopolitical tensions continue to reinforce the need for heightened vigilance across host nations.
A Converging Threat Environment
The risks surrounding the 2026 World Cup intersect across multiple domains.
Physical security, cyber activity, geopolitical tensions, and social movements all operate against the same infrastructure and audiences. Activity in one area can quickly affect another.
Flashpoint assesses that the most persistent risks across all host nations include:
Crimes of opportunity targeting visitors unfamiliar with local environments
Lone-actor attacks, including those driven by extremist ideologies
Overcrowding, fan conflicts, and unmanaged gatherings
These risks are amplified by the tournament’s scale and geographic distribution.
Civil Unrest and Protest Activity
World Cup tournaments routinely become platforms for protest.
For 2026, multiple movements are already organizing around the event:
“Boycott USA 2026” campaigns and groups like CODEPINK are calling for relocation of matches
The “50501 Movement” has signaled intent to leverage the tournament’s visibility for national demonstrations
Coalitions of civil society organizations have raised concerns around immigration enforcement, surveillance, and civil rights
Recent organizing activity has expanded beyond traditional anti-FIFA campaigns. Civil rights organizations, labor groups, anti-ICE coalitions, and community organizations in multiple host cities have announced or promoted demonstrations tied to immigration enforcement, displacement concerns, labor issues, and the broader social impacts of the tournament.
In the United States, Flashpoint analysts assess with high confidence that protests will occur across all host cities, with messaging tied to immigration policy, labor issues, and geopolitical tensions.
In Canada and Mexico, protests tied to environmental concerns, infrastructure impact, and global conflicts are also expected.
At this stage, most campaigns remain organizational rather than operational. But the scale of the event means even localized demonstrations can escalate quickly, especially around stadiums, transit hubs, and fan zones.
Physical Security and Crowd Risk
No specific terrorist plots have been identified. But that does not reduce the risk.
Large gatherings remain attractive targets for:
Lone actors seeking high visibility
Opportunistic criminals
Disruptive fan groups
Online chatter continues to reference potential attacks, including decentralized calls for violence from extremist-linked media outlets. Recently, a pro-ISIS media outlet released World Cup-themed propaganda that appeared designed to portray major football venues and international sporting events as symbolic targets, underscoring the continued threat posed by lone actors and extremist-inspired violence.
Beyond intentional threats, crowd dynamics pose a persistent risk. Past sporting events have shown how quickly panic, overcrowding, or pyrotechnics can trigger dangerous conditions, including crowd crush incidents.
Fan culture adds another layer. Organized groups such as Ultras and hooligan firms increasingly operate with coordination, using encrypted messaging, reconnaissance (“spotting”), and off-site meetups to avoid security controls.
Security concerns extend beyond traditional supporter culture. Some organized fan groups have evolved increasingly sophisticated tactics, including coordinated reconnaissance, plain-clothes scouting, encrypted communications, and deliberate efforts to move confrontations away from stadium security zones and into “soft zones” like bars, transit hubs, and other gathering locations.
Geopolitical Tensions and High-Risk Matches
Geopolitics will shape the security environment throughout the tournament.
The ongoing tensions involving the United States, Israel, and Iran are expected to influence both protest activity and threat perceptions. Iran’s participation—particularly matches held in U.S. cities—has already sparked debate, travel concerns, and increased security planning.
The issue extends beyond match security. Visa policies, travel restrictions, diaspora activism, and ongoing debate surrounding Iranian participation have already generated significant discussion among supporters, advocacy groups, and government stakeholders.
Certain matches carry elevated risk due to:
Historical rivalries
National identity tensions
Known fan group activity
These matches require heightened monitoring not just inside stadiums, but across surrounding areas where supporters gather.
The Expanding Cyber Threat Surface
The World Cup is also a large-scale digital event.
Even without identified active campaigns, Flashpoint analysts expect the tournament to function as a stress test for global infrastructure.
Key cyber risks include:
Ticketing fraud: Fake domains impersonating official FIFA platforms
Phishing and social engineering: Targeting fans, vendors, and staff
Ransomware and DDoS attacks: Disrupting transit systems, stadium operations, and hospitality networks
Infrastructure targeting: Exploiting vulnerabilities in public-facing systems
Researchers have already identified thousands of fraudulent domains impersonating FIFA-related services, alongside phishing campaigns designed to harvest credentials, hijack accounts, and resell legitimate tickets purchased by victims.
Threat actors are also expected to monetize the event through:
Fraudulent housing and rental listings
Rideshare and transportation scams
Sports betting manipulation and extortion
Even minor disruptions to digital infrastructure can have cascading effects on physical operations that cause delayed transportation, overwhelming venues, or other safety concerns.
Operational Security Gaps
Some of the most overlooked risks are also the simplest.
Attendees, staff, and media frequently post images of credentials like press passes, security badges, and access tokens on public social media. These images can be used to replicate credentials and bypass controls.
Similarly, fans often attempt to:
Access team hotels
Enter restricted areas
Interact directly with players
These behaviors create additional pressure on venue and hospitality security teams, particularly in high-profile locations.
Beyond the Stadium: Distributed Risk
The World Cup extends far beyond match venues. Security teams must account for:
Team base camps and training facilities
Fan festivals and unofficial gatherings
Hotels, tourist destinations, and transit systems
Cross-border travel between host nations
Increased human trafficking and exploitation risks associated with large-scale international travel and temporary workforces
Unauthorized fan festivals and spontaneous gatherings remain a persistent concern, often drawing large crowds without coordinated security planning.
At the same time, environmental factors including extreme heat, severe storms, flooding, air quality concerns from wildfires, and other weather-related disruptions may affect operations, travel, and crowd safety across host regions.
Getting Ready for the Tournament
The absence of identified threats should not be misinterpreted as low risk.
Events of this scale require continuous monitoring across physical, cyber, and social domains. Threat indicators often emerge early in:
Online forums and messaging platforms
Local protest planning
Fraudulent domain registrations
Changes in adversary behavior
Effective preparation depends on:
Broad, multilingual monitoring across open and closed sources
Correlation between physical and cyber indicators
Visibility into both high-profile targets and “soft zones”
Close coordination between public and private sector partners
Flashpoint recommends monitoring key terms such as “World Cup,” “FIFA,” “Fan Festival,” and related hashtags across intelligence platforms to maintain situational awareness.
Preparing for the Whistle
Building a robust threat monitoring architecture is a continuous process. Host cities and law enforcement often use smaller-scale international competitions as test runs to prepare for the scale and complexity of events like the FIFA World Cup.
By leveraging Flashpoint’s advanced search capabilities—including broad keyword coverage, wildcard operators, and visibility into deep and dark web communities—organizations can maintain awareness of emerging risks tied to large-scale events. From stadium infrastructure to digital ticketing platforms, actionable intelligence supports more informed, timely decisions.
To see how Flashpoint enables this level of visibility and monitoring in practice, request a demo.
Inside the 2026 Cyber Threat Landscape: Data-Driven Security Priorities
In Flashpoint’s recent webinar, we examine the defining shifts shaping the 2026 threat landscape, from AI-driven attack automation to the growing role of identity in initial access. We analyze how infostealers, vulnerabilities, and ransomware activity are evolving, and where security teams should focus now.
In 2026, the threat landscape operates as a single, connected system. Identity, malware, and infrastructure are now part of the same attack chain, executed at a speed that compresses the time between access and impact.
What once required multiple stages and specialized tooling is now streamlined and automated.
Flashpoint recently hosted an on-demand webinar, “Inside the 2026 Cyber Threat Landscape: Data-Driven Security Priorities,” where our intelligence team broke down the trends driving this shift. Drawing from primary source intelligence across forums, marketplaces, and closed communities, the session examined how modern attack chains are forming and evolving, as well as where defenders still have opportunities to intervene.
Here are the key takeaways you need to know to prioritize threats and protect your organization.
AI Is Being Operationalized Across the Attack Lifecycle
Flashpoint tracked more than 1.5 billion mentions of AI in illicit communities in 2025, with activity accelerating sharply toward the end of the year. These discussions center on how AI can be applied to real operations, including phishing, malware development, and fraud.
As Ian Gray, Vice President of Intelligence at Flashpoint, noted during the session, “Adversaries are extremely adept, and they’re constantly looking at how they can use the newest state-of-the-art tools—whether that’s commercial models or their own implementations—and how they can jailbreak them or adapt them to their workflows.”
One of the most notable developments is the use of agentic AI systems to automate tasks that were previously manual. These systems are being used to:
Test stolen credentials across VPNs, SaaS platforms, and cloud environments
Rotate infrastructure during active operations
Generate and refine attack inputs based on previous outcomes
Alongside this, threat actors are actively exploring ways to bypass safeguards in commercial AI tools, including:
Jailbreaking model restrictions
Embedding hidden instructions through prompt injection
Manipulating AI-powered features within enterprise applications
This activity reflects a sustained effort to integrate AI directly into attack execution rather than treating it as a standalone capability.
Identity Is Driving Initial Access
The fundamental mechanics of cybercrime have shifted from breaking in to logging in, as attackers leverage stolen session cookies to behave like legitimate users.
As Gray explained, “Threat actors are finding a variety of ways to get into enterprise networks, and typically it’s through the human element. While humans can be trained or educated, it’s not something that can be patched in the traditional sense.”
This dynamic is already visible at scale.
Flashpoint observed 11.1 million infected devices and 3.3 billion stolen credentials in 2025. These credentials are extracted through infostealers and circulated across marketplaces, enabling direct access into enterprise environments.
In many cases, attackers are using:
Session cookies and tokens to bypass authentication flows
Browser fingerprints and system metadata to replicate legitimate user behavior
Valid credentials to access SaaS platforms, VPNs, and internal systems
Once access is established, activity often blends into normal user behavior, making detection more difficult. Compromised identities are also reused across multiple services, expanding the scope of potential exposure.
This pattern continues to appear in intrusion activity tied to SaaS platforms and third-party integrations, where access to one system can provide visibility into multiple environments.
Infostealers Are Enabling Scalable Access
Infostealers remain a primary driver of credential exposure.
Logs containing credentials, cookies, and system data are continuously harvested and made available through criminal marketplaces and subscription-based services. These logs are used directly or integrated into automated workflows that test and validate access at scale.
Gray pointed to how this plays out in practice: “Infostealers have really commoditized access. They harvest credentials, identify which ones are useful, and then test them at scale across VPNs, SaaS platforms, and cloud environments.”
The ecosystem continues to shift as law enforcement activity disrupts established players and new variants gain traction. Families such as Vidar, Lumma, and others maintain a strong presence due to accessibility and ongoing development.
In parallel, credential harvesting is feeding downstream activity, including:
Account takeover
Fraud operations
Data exfiltration and extortion
This linkage between initial access and follow-on activity is consistent across multiple reporting streams.
Vulnerability Exploitation Is Moving Faster
Vulnerability volume continues to increase alongside exploitation speed.
Flashpoint recorded more than 44,000 disclosed vulnerabilities in 2025, with over 14,000 tied to publicly available exploits. In several cases, exploitation activity followed disclosure within a day.
As Gray put it, “With vulnerabilities, it can feel like you’re trying to boil the ocean. There’s such a high volume of disclosures, but in reality, there’s a smaller set—those that are remotely exploitable, have proof-of-concept code, and are being actively used—that you need to focus on.”
Attacker focus is concentrated in areas that provide broad access or downstream impact, including:
Software supply chains and CI/CD environments
Open-source dependencies
Widely used enterprise platforms
Given the volume of disclosures, prioritization remains critical. Vulnerabilities that are remotely exploitable and paired with public exploit code present immediate risk, particularly when active discussion or exploitation is observed.
Ransomware Activity Continues to Shift
Ransomware activity increased by 53%, with continued changes in how operations are carried out.
Gray framed the shift this way: “Why even bother to develop ransomware? That takes time, resources, and overhead—when you can gain access through a compromised account or third-party platform and immediately move to extortion.”
In addition to traditional ransomware deployment, there is sustained activity centered on:
Data exfiltration followed by extortion
Use of compromised credentials for direct access
Targeting of third-party providers and SaaS platforms
Intrusions tied to help desks, identity workflows, and federated applications continue to appear in reporting, often involving social engineering or unauthorized access provisioning.
There is also ongoing activity related to insider recruitment, with threat actors seeking individuals who can provide direct access or privileged information.
Industries with higher operational dependencies, including manufacturing, technology, and healthcare, continue to be targeted due to the potential impact of disruption.
Translating Intelligence Into Action
The trends shaping 2026 are grounded in how attackers are currently operating across multiple domains.
As Gray emphasized, “You have to take into account vulnerabilities, exposures, infostealers, and identity compromise all at the same time. These aren’t separate problems anymore—they’re all part of the same attack chain.”
Security teams should focus on:
Identifying exposures with a high likelihood of exploitation
Monitoring for compromised credentials tied to organizational domains
Reviewing identity access and third-party integrations
Prioritizing vulnerabilities with active exploit availability
Tracking attacker activity across forums, marketplaces, and communication channels
These actions align with observed attacker behavior and provide a clearer path to prioritization.
Watch the Full Webinar and Explore the Data
The trends shaping 2026 are grounded in how attackers are already operating.
Flashpoint’s full webinar provides a deeper look at the data, along with practical guidance on how to translate intelligence into action.
Flashpoint MCP Server: Operationalizing Cyber Threat Data for Agentic AI Security Workflows
In this post, we outline how cyber threat intelligence is evolving to support agentic AI-driven security operations, why MCP is emerging as a foundational standard, and how Flashpoint is operationalizing data for this new model.
Security teams are under more pressure than ever to move faster, see more, and act with confidence.
At the same time, the way cybersecurity investigations happen is evolving. The “human-in-the-loop” model is expanding: analysts increasingly direct AI agents that gather context, correlate signals across sources, and handle repetitive triage.
While AI is rapidly becoming a staple of modern security operations, a significant gap remains: most intelligence sources were originally designed for human consumption, not AI agents. Historically, threat intelligence platforms were built for analysts to log in and piece together disparate insights. While that model remains the gold standard for deep research, it can become a bottleneck in a high-velocity, agent-led workflow where AI assistants and automation pipelines are the primary investigators.
At Flashpoint, our Ignite threat intelligence platform was built to support deep investigative workflows, enabling analysts to search and connect intelligence across primary-source datasets and build a complete picture of emerging threats. That foundation remains critical.
But as workflows evolve, customers are increasingly looking to extend that same intelligence beyond the platform—into AI assistants, automation pipelines, and other environments where work is actively happening.
That raises an important question: How do you make high-value intelligence as usable for an AI agent as it is for a human analyst?
Today, we are outlining our approach to building the Flashpoint Model Context Protocol (MCP) Server, a strategic initiative that makes Flashpoint’s best-in-class intelligence accessible not only via our award-winning platform but also natively “AI-callable” within the agentic workflows of today and tomorrow.
What Is an MCP Server and Why Does It Matter in Cyber Threat Intelligence?
Model Context Protocol (MCP) is the standard for connecting AI systems to external data sources and tools.
In practical terms, an MCP server provides a structured way for AI systems, like agents, assistants, copilots, and automation frameworks, to access and interact with data in real time.
For cyber threat intelligence, this represents a fundamental shift in how teams operate:
Faster investigations: AI agents can query and correlate data across disparate datasets in seconds.
Comprehensive coverage: By searching across all primary sources in parallel, teams eliminate the risk of missing critical intelligence.
More seamless workflows: Analysts can stay within their agentic workflow without constant context switching.
Reduced integration overhead: Less need for custom engineering to connect intelligence into new environments.
Flashpoint MCP Server: A Foundation for AI-Native Threat Intelligence
Flashpoint has always differentiated itself on the quality and depth of our data, sourced directly from where threats emerge. Our goal is to ensure this intelligence is available wherever your analysts are working.
Currently, teams experimenting with AI assistants face significant friction: copying and pasting, relying on third-party bridges, or maintaining custom integrations.
We are building the Flashpoint MCP Server as a foundational access layer, the architectural connector that will power both external integrations and future AI experiences within the Flashpoint platform.
With this new layer, teams can:
Query intelligence in one workflow: Access intelligence reports, ransomware, vulnerabilities, communities, and Deep Dark Web, and technical indicators in a single research task rather than hopping tool-to-tool.
Ground AI agents in truth: Provide a direct, authenticated bridge to real-time, verified Flashpoint intelligence, ensuring AI responses are based on evidence rather than static training data or hallucinations.
Scale expert analysis: Use guided prompts and workflow templates to teach the AI exactly how to use our tools to conduct expert-level investigations across our datasets.
The threat intelligence industry is adopting MCP as the standard for how AI systems connect to data.
We’re building the Flashpoint MCP Server to ensure our intelligence is a foundational component of that ecosystem and usable wherever AI-driven workflows occur.
What to Expect from Flashpoint MCP Server
The initial release of the Flashpoint MCP Server in Spring 2026 is intentionally read-only and query-focused. This creates the production-grade foundation required to bring intelligence into the workflows customers are already building. It aligns with customer guidance about using agentic AI to solve the most pressing challenges they face today.
What Comes Next
Later this year, we will move from information retrieval to Action-Oriented Intelligence. This expansion will allow users not only to access data but also to act on it directly within their AI-driven workflows. As this ecosystem evolves, we plan to deliver:
Natural Language Orchestration: We are empowering analysts to interact with our data more intuitively. Through the MCP server, complex actions such as updating an investigation or identifying new threat sources are handled via natural-language orchestration. This ensures that the speed of an investigation is limited only by an analyst’s questions, not their mastery of a specific query syntax.
Flashpoint-Native Agents and Skills: We are developing specialized Flashpoint Agents and “skills” built on top of this server. These will be purpose-built to address specific workflows, such as ransomware monitoring or vulnerability triage, allowing teams to deploy out-of-the-box expertise without building their own agentic logic
Fusion of External and Internal Data: A critical advantage of the MCP framework is the ability to combine Flashpoint’s external threat intelligence with a customer’s internal environment data (SIEM, Cloud, IAM, Endpoint, etc.). This allows an agent to correlate global threat signals with your specific footprint to provide instant, individualized risk context.
Embedded AI within Flashpoint Ignite: This same MCP infrastructure will serve as the shared engine for new, embedded AI experiences within Flashpoint Ignite. This ensures that the same natural-language power and automated data correlation fueling external agents are also natively available within our platform UI, creating a seamless investigative experience regardless of where an analyst chooses to work.
Built and Validated in Real Workflows
We believe in the power of this new architecture because we are already using it. The MCP Server is currently embedded in our own Flashpoint Intelligence Team’s workflow, helping our analysts research and respond to complex client RFIs.
By applying this capability to our own high-stakes research first, we ensure that what we bring to market is grounded in real investigative needs, not just technical potential.
Operationalizing the Best Data
The future of security operations won’t be defined solely by who has access to the most data or even the most AI agents; it will be defined by who can operationalize the best data directly within the workflows where decisions are made.
The Flashpoint MCP Server is our strategic commitment to that future—making the world’s best intelligence natively accessible, usable, and aligned with the way modern security teams work.
The Flashpoint MCP Server is currently in active development, with customer availability planned for late Spring 2026.
Subscribe to the Flashpoint blog for more updates on Flashpoint MCP Server and the latest insights from the front lines of threat intelligence.
Frequently Asked Questions
What is the Flashpoint MCP Server?
The Flashpoint MCP Server enables Flashpoint’s threat intelligence to be directly callable by AI agents. It implements the Model Context Protocol (MCP), an open standard for connecting AI systems to external data, so any MCP-compatible agent, including Claude, Gemini, and Cursor, can query our datasets without bespoke API integration work.
Who is the MCP Server designed for?
The MCP Server is designed for technical, forward-leaning security teams and AI-native organizations. This includes SOC analysts, CTI practitioners, and security engineers who are already building or experimenting with AI agent workflows using tools like Gemini, Claude Code, or custom LLM-based assistants.
Which Flashpoint datasets are accessible via MCP?
The initial rollout (Spring 2026) provides access to Flashpoint’s core intelligence collections, including:
Intelligence Reports
Communities (Online forums, messaging platforms, closed digital communities)
Technical Indicators (IOCs)
Vulnerability Intelligence (CVEs)
Ransomware
Compromised Credentials and Infected Hosts
Strategic Entity Data
How does this differ from Flashpoint’s standard APIs?
While our standard APIs are designed for direct programmatic consumption, the MCP Server is optimized specifically for AI agents. It exposes intelligence as composable tools and guided prompts that AI agents can understand and use to perform complex, multi-step research tasks.
How does this differ from the Flashpoint Ignite platform?
The Flashpoint MCP Server is not a replacement for Flashpoint’s award-winning Ignite platform; rather, it is a complementary access layer designed for a different type of user and workflow. While Ignite is a destination for deep research, the MCP server provides the infrastructure that enables that same intelligence to live in AI-native environments.
To learn more about Flashpoint’s MCP Server, schedule a demo today.
We are proud to share that Flashpoint has been named a Challenger in the inaugural 2026 Gartner® Magic Quadrant for Cyber Threat Intelligence Technologies.
“We see this recognition as a testament to Flashpoint’s ability to execute at the highest levels for the world’s most discerning threat intelligence customers, with our unique combination of primary source collection and human analysis at the core,” — Josh Lefkowitz, CEO at Flashpoint.
The Gartner Magic Quadrant provides organizations with a wide-angle view of vendors in the cyber threat intelligence market. By applying a graphical treatment and a uniform set of evaluation criteria, the Magic Quadrant helps organizations assess how well technology providers are executing their stated visions and performing against Gartner’s market view. Vendors are evaluated based on their Ability to Execute and Completeness of Vision:
Ability to Execute reflects the Gartner assessment of the vendor’s product and/or service, overall viability, sales execution and pricing, market responsiveness and record, marketing execution, customer experience, as well as operations.
Completeness of Vision comprises the Gartner view of the vendor’s overall market understanding, marketing strategy, sales strategy, offering (product) strategy, business model, vertical/industry strategy, innovation, and geographic strategy.
“We believe, and our customers consistently validate, that the future of threat intelligence lies at the critical intersection of intelligence depth and application,” says Lefkowitz. “That’s why Flashpoint pairs unmatched access to primary-source environments with the ability to operationalize that intelligence across security workflows, enabling organizations to make faster, more informed decisions.”
A complimentary copy of the Gartner® Magic Quadrant for Cyber Threat Intelligence Technologies is available to download here.
Market Dynamics and Growth of the Threat Intelligence Market
The threat intelligence market has expanded in both scope and strategic importance as organizations contend with a broader and more complex threat environment. What was once a supporting function within security operations is now expected to inform decisions across vulnerability management, fraud prevention, and enterprise risk. This shift has raised the bar for how intelligence is collected, analyzed, and applied.
Gartner describes this evolution as a move toward unified cyber risk intelligence (UCRI) — an approach that brings together diverse internal and external data sources with advanced analytical capabilities to improve decision-making. As noted in The Evolution of Threat Intelligence Is Unified Cyber Risk Intelligence, “the future of threat intelligence is unified cyber risk intelligence (UCRI)… defined by the convergence of multisignal collection and advanced analytical capabilities.” In our opinion, this model reflects the reality that no single source provides sufficient visibility, and that intelligence must be corroborated across environments to be actionable.
At the same time, the scale of available data continues to increase, introducing new challenges around prioritization and context. Gartner notes that organizations “receive vast amounts of threat data, and filtering out false positives, redundant information and irrelevant alerts to extract actionable intelligence remains a significant challenge. This “noise” can overwhelm security teams and lead to important threats being missed.” This is where AI plays a growing role. Techniques such as machine learning and natural language processing are increasingly used to correlate signals, identify patterns, and surface relevant risks faster. As intelligence becomes more integrated across the enterprise, the ability to combine multisource collection with AI-driven analysis is shaping how organizations evaluate platforms and build modern threat intelligence programs.
How Security Teams Are Evaluating Threat Intelligence
From Flashpoint’s experience working with the most discerning security and intelligence teams, the value of a threat intelligence platform is measured in how it performs in practice — how quickly it surfaces relevant activity, how much context it provides, and how easily it supports decision-making across workflows.
We see three areas consistently shape how intelligence is evaluated, supported by a combination of human expertise and AI-driven analysis:
Access to high-signal environments: Intelligence is most useful when it reflects activity at its source. Access to closed forums, encrypted messaging platforms, and illicit marketplaces provides the context needed to understand how threats develop and move.
Context that supports prioritization: Vulnerability and threat data require context to be actionable. Understanding how activity is discussed and operationalized in real environments allows teams to focus on what requires attention.
Integration into operational workflows: Intelligence must fit into the systems and processes teams already rely on. Integration across SIEM, SOAR, and internal workflows allows intelligence to be applied consistently at scale.
These areas are closely tied to how Flashpoint has built its platform and how it supports organizations operating in complex threat environments.
Where Intelligence Comes From Matters
A large part of how intelligence performs in practice comes back to the source of the data itself.
We believe, and our customers continue to validate, that Flashpoint’s approach is centered on primary-source collection. That means accessing environments where threat activity is actively discussed, coordinated, and developed, including closed forums, encrypted messaging platforms, and illicit marketplaces. These environments require sustained access and ongoing validation, but they provide a level of visibility that is difficult to achieve through surface-level collection alone.
From our experience, working from these sources changes how intelligence is used. Activity can be observed earlier and understood with more context, with discussions, relationships, and intent preserved.
In practice, this allows teams to:
Identify emerging activity before it becomes widely visible
Maintain context across conversations, actors, and environments
Reduce time spent investigating low-value or unverified signals
Intelligence Has to Fit Into How Teams Actually Operate
Collection alone doesn’t determine whether intelligence is useful. We believe it also has to be delivered in a way that aligns with how teams work.
In our experience, most security teams already have established workflows tied to SIEMs, SOAR platforms, and internal processes. Intelligence that integrates into those workflows can be applied consistently across investigation and response.
In practice, we see this support:
Delivery of intelligence directly into existing systems
Consistent application across automated and analyst-driven workflows
Reduced friction between intelligence, investigation, and response
Over time, this consistency allows teams to build repeatable processes around intelligence rather than treating it as a separate function.
Context Drives Prioritization
The same dynamics apply to vulnerability intelligence.
From our experience, understanding which vulnerabilities exist is only one part of the problem. Determining which ones require attention in a given environment depends on context — how those vulnerabilities are being discussed, shared, or used in active threat activity.
We have seen first-hand that when vulnerability data is connected to real-world activity, teams can:
Prioritize remediation based on active threat relevance
Align vulnerability management with observed adversary behavior
Reduce reliance on static scoring as the sole decision driver
Applying This in Practice
For organizations evaluating providers, challenge intelligence sources, challenge collection agility, challenge exploit prioritization and above all ask yourself is this a partner with a long-term track record of navigating the world’s most complex threat environments?
To see how Flashpoint, the world’s largest private provider of threat intelligence can help you make better decisions, faster and with confidence, schedule a demo.
Gartner Disclaimer
Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.
This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Gartner document is available upon request from Flashpoint.
Gartner, Magic Quadrant for Cyber Threat Intelligence Technologies, Jonathan Nunez, Carlos De Sola Caraballo, Jaime Anderson, May 4, 2026.
Gartner, The Evolution of Threat Intelligence Is Unified Cyber Risk Intelligence, By Jonathan Nunez, 15 September 2025.
Gartner and Magic Quadrant are trademarks of Gartner, Inc., and/or its affiliates.
How to Build and Operationalize Priority Intelligence Requirements
In this post, we break down how to define, structure, and operationalize Priority Intelligence Requirements (PIRs) to improve focus, reduce noise, and drive more effective intelligence outcomes, with a companion starter kit to help apply these concepts in practice.
Security teams are inundated with data. Alerts, feeds, reports, and signals continue to grow in volume, but without clear direction, much of that information fails to translate into meaningful action.
Flashpoint recently hosted a webinar, “How to Build and Operationalize Priority Intelligence Requirements,” where our intelligence team walked through how organizations can bring structure to their intelligence programs. The session focused on how to define Priority Intelligence Requirements (PIRs), align them to business needs, and operationalize them across workflows. If you missed it, you can catch the on-demand recording here.
In this blog, we’ll recap the key takeaways from the webinar that you need to know to build, structure, and operationalize Priority Intelligence Requirements within your organization.
Priority Intelligence Requirements Create Focus
Priority Intelligence Requirements (PIRs) define what matters most to an organization’s intelligence function.
They serve as a framework for identifying the threats, risks, and questions that intelligence teams are responsible for answering. Without that structure, teams often default to reactive workflows—chasing alerts and producing reporting without clear alignment to business priorities.
PIRs establish that alignment by grounding intelligence work in specific, decision-driven questions.
These questions are typically tied to areas such as:
Threat actor activity targeting the organization or its sector
Exposure of sensitive data, credentials, or infrastructure
Risks tied to third-party vendors or supply chain dependencies
Emerging trends that may impact operations or security posture
When defined correctly, PIRs act as a filter that helps teams determine what to collect, analyze, and escalate.
Effective PIRs Start With the Business
One of the most common challenges highlighted in the webinar is that PIRs are often defined in isolation.
When intelligence requirements are not tied to business priorities, they tend to drift toward generic threat monitoring. This leads to reporting that is technically accurate, but operationally disconnected.
Effective PIR development starts with first understanding:
What decisions need to be made
Who is responsible for making them
What information is required to support those decisions
This requires direct engagement with stakeholders across security, risk, and business teams. In practice, that often includes leadership, legal, fraud, and operational teams.
The goal is to translate business concerns into intelligence questions that can be consistently answered over time.
Structuring PIRs for Actionability
Clear structure is essential to making PIRs usable.
Well-defined PIRs are specific enough to guide collection and analysis, but flexible enough to evolve as threats change. They are typically framed as direct questions that intelligence teams can answer with available data.
Examples of structured PIRs include:
Are threat actors actively targeting our organization or industry?
Has our data appeared in criminal marketplaces or forums?
Are our third-party vendors experiencing security incidents that could impact us?
This approach ensures that intelligence outputs remain focused on answering defined questions rather than producing general reporting.
It also enables consistency across teams, making it easier to track trends and measure changes over time.
Operationalizing PIRs Across Workflows
Defining PIRs is only the starting point. Their value comes from how they are integrated into day-to-day operations.
In the webinar, Flashpoint emphasized the importance of embedding PIRs across the intelligence lifecycle, including:
Collection: Prioritizing sources and datasets that align with defined requirements
Analysis: Structuring outputs around PIR-driven questions
Dissemination: Delivering intelligence to the stakeholders tied to each requirement
Feedback: Continuously refining PIRs based on evolving needs
This integration ensures that intelligence efforts remain consistent and aligned, even as threat conditions change.
It also reduces duplication of effort and helps teams avoid producing intelligence that does not support decision-making.
Measuring the Impact of Intelligence
PIRs provide a foundation for evaluating whether intelligence efforts are effective.
Without defined requirements, it is difficult to determine whether outputs are relevant or useful. PIRs create a benchmark against which teams can assess:
Whether key questions are being answered
Whether intelligence is reaching the right stakeholders
Whether outputs are informing real decisions
This shifts intelligence from a reporting function to a decision-support capability.
Over time, this approach helps organizations refine both their requirements and their workflows, improving efficiency and impact.
Dive Deeper | Watch the Full Webinar
Building and operationalizing Priority Intelligence Requirements is a foundational step toward a more focused and effective intelligence program.
Flashpoint’s on-demand webinar walks through this process in detail, including practical examples and guidance for implementation.
For teams looking to move from theory to implementation, the Priority Intelligence Requirements (PIR) Starter Kit provides a practical extension of this approach. The resource includes a structured framework for defining requirements, a catalog of adaptable PIR examples across key intelligence drivers, and a template to support documentation and governance.
In the past few years, Fox-IT and NCC Group have conducted multiple incident response cases involving a Lazarus subgroup that specifically targets organizations in the financial and cryptocurrency sector. This Lazarus subgroup overlaps with activity linked to AppleJeus1, Citrine Sleet2, UNC47363, and Gleaming Pisces4. This actor uses different remote access trojans (RATs) in their operations, known as PondRAT5, ThemeForestRAT and RemotePE. In this article, we analyse and discuss these three.
First, we describe an incident response case from 2024, where we observed the three RATs. This gives insights into the tactics, techniques, and procedures (TTPs) of this actor. Then, we discuss PondRAT, ThemeForestRAT and RemotePE, respectively.
PondRAT received quite some attention last year, we give a brief overview of the malware and document other similarities between PondRAT and POOLRAT (also known as SimpleTea) that have not yet been publicly documented. Secondly, we discuss ThemeForestRAT, a RAT that has been in use for at least six years now, but has not yet been discussed publicly. These two malware families were used in conjunction, where PondRAT was on disk and ThemeForestRAT seemed to only run in memory.
Lastly, we briefly describe RemotePE, a more advanced RAT of this group. We found evidence that the actor cleaned up PondRAT and ThemeForestRAT artifacts and subsequently installed RemotePE, potentially signifying a next stage in the attack. We cannot directly link RemotePE to any public malware family at the time of this writing.
In all cases, the actor used social engineering as an initial access vector. In one case, we suspect a zero-day might have been used to achieve code execution on one of the victim’s machines. We think this highlights their advanced capabilities, and with their history of activity, also shows their determination.
A Telegram from Pyongyang
In 2024, Fox-IT investigated an incident at an organisation in decentralized finance (DeFi). There, an employee’s machine was compromised through social engineering. From there, the actor performed discovery from inside the network using different RATs in combination with other tools, for example, to harvest credentials or proxy connections. Afterwards, the actor moved to a stealthier RAT, likely signifying a next stage in the attack.
In Figure 1, we provide an overview of the attack chain, where we highlight four phases of the attack:
Social engineering: the actor impersonates an existing employee of a trading company on Telegram and sets up a meeting with the victim, using fake meeting websites.
Exploitation: the victim machine gets compromised and shortly afterwards PondRAT is deployed. We are uncertain how the compromise was achieved, though we suspect a Chrome zero-day vulnerability was used.
Discovery: the actor uses various tooling to explore the victim network and observe daily activities.
Next phase: after three months, the actor removes PerfhLoader, PondRAT and ThemeForestRAT and deploys a more advanced RAT, which we named RemotePE.
Figure 1: Overview of the attack chain from a 2024 incident response case involving a Lazarus subgroup
Social Engineering
We found traces matching a social engineering technique previously described by SlowMist6. This social engineering campaign targets employees of companies active in the cryptocurrency sector by posing as employees of investment institutions on Telegram.
This Lazarus subgroup uses fake Calendly and Picktime websites, including fake websites of the organisations they impersonate. We found traces of two impersonated employees of two different companies. We did not observe any domains linked to the “Access Restricted” trick as described by SlowMist. In Figure 2, you can see a Telegram message from the actor, impersonating an existing employee of a trading company. Looking up the impersonated person, showed that the person indeed worked at the trading company.
Figure 2: Lazarus subgroup impersonating an employee at a trading company interested in the cryptocurrency sector
From the forensic data, we could not establish a clear initial access vector. We suspect a Chrome zero-day exploit was used. Although, we have no actual forensic data to back up this claim, we did notice changes in endpoint logging behaviour. Around the time of compromise, we noted a sudden decrease in the logging of the endpoint detection agent that was running on the machine. Later, Microsoft published a blogpost7, describing Citrine Sleet using a zero-day Chrome exploit to launch an evasive rootkit called FudModule8, which could explain this behaviour.
Persistence with PerfhLoader
The actor leveraged the SessionEnv service for persistence. This existing Windows service is vulnerable to phantom DLL loading9. A custom TSVIPSrv.dll can be placed inside the %SystemRoot%\System32\ directory, which SessionEnv will load upon startup. The actor placed its own loader in this directory, which we refer to as PerfhLoader. Persistence was ensured by making the service start automatically at reboot using the following command:
sc config sessionenv start=auto
The actor also modified the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SessionEnv\RequiredPrivileges registry key by adding SeDebugPrivilege and SeLoadDriverPrivilege privileges. These elevated privileges enable loading kernel drivers, which can bypass or disable Endpoint Detection and Response (EDR) tools on the compromised system.
Figure 3: PerfhLoader loaded through SessionEnv service via Phantom DLL Loading which in turn loads PondRAT or POOLRAT
In a case from 202010, this actor used the IKEEXT service for phantom DLL loading, writing PerfhLoader to the path %SystemRoot%\System32\wlbsctrl.dll. The vulnerable VIAGLT64.SYS kernel driver (CVE-2017-16237) was also used to gain SYSTEM privileges.
PerfhLoader is a simple loader that reads a file with a hardcoded filename (perfh011.dat) from its current directory, decrypts its contents, loads it into memory and executes it. In all observed cases, both PerfhLoader and the encrypted DLL were in the %SystemRoot%\System32\ folder. Normally, perfhXXX.dat files located in this folder contain Windows Performance Monitor data, which makes it blend in with normal Windows file names.
The cipher used to encrypt and decrypt the payload uses a rolling XOR key, we denote the implementation in Python code in Listing 1.
def crypt_buf(data: bytes) -> bytes:
xor_key = bytearray(range(0x10))
buf = bytearray(data)
for idx in range(len(buf)):
a = xor_key[(idx + 5) & 0xF]
b = xor_key[(idx - 3) & 0xF]
c = xor_key[(idx - 7) & 0xF]
xor_byte = a ^ b ^ c
buf[idx] ^= xor_byte
xor_key[idx & 0xF] = xor_byte
return bytes(buf)
Listing 1: Python implementation of the XOR cipher used by PerfhLoader
The decrypted content contains a DLL that PerfhLoader loads into memory using the Manual-DLL-Loader project11. Interestingly, PondRAT uses this same project for DLL loading.
Discovery
After establishing a foothold, the actor deployed various tools in combination with the RATs described earlier. These included both custom tooling and publicly available tools. Table 1 lists some of the tools we recovered that the actor used.
Tool
Tool Origin
Description
Screenshotter
Actor
A tool that takes periodic screenshots and stores them locally
Keylogger
Actor
A Windows keylogger that writes user keystrokes to a file
Chromium browser dumper
Actor
A browser dump tool that dumps Chromium-based browser cookies and credentials
Table 1: Tools observed during incident response case (public and actor-developed)
Interestingly, the Fast Reverse Proxy client we found was the same client found in the 3CX compromise by Mandiant15. This client is version 0.32.116 and is from 2020, which is remarkable. We also found traces of a Themida-packed version of Quasar17, a malware family we did not see this Lazarus subgroup use before.
The actor used PondRAT in combination with ThemeForestRAT for roughly three months, to afterwards clean up and install the more sophisticated RAT called RemotePE. We will now discuss these three RATs.
PondRAT
PondRAT is a simple RAT, which its authors seem to refer to as “firstloader”, based on the compilation metadata string objc_firstloader that is present in the macOS samples.
In our case, PondRAT was the initial access payload used to deploy other types of malware, including ThemeForestRAT. Judging from network data, apart from ThemeForestRAT activity, we observed significant activity to the PondRAT C2 server, indicating it was not just used for its loader functionality. In the incident response case from 2020 we encountered POOLRAT in combination with ThemeForestRAT. This could indicate that PondRAT is a successor of POOLRAT.
Overview
PondRAT is a straightforward RAT that allows an operator to read and write files, start processes and run shellcode. It has already been described by some vendors. As far as we know, the earliest sample is from 2021, referenced in a CISA article18. Based on PondRAT’s user-agent, we also noticed that PondRAT was used in an AppleJeus campaign Volexity wrote about19 (MSI file with hash 435c7b4fd5e1eaafcb5826a7e7c16a83). 360 Threat Intelligence Center wrote about PondRAT as well20, linking it to Lazarus and later writing about it being distributed through Python Package Index (PyPI) packages21. Vipyr Security wrote22 about malware that was dropped through malicious Python packages distributed through PyPI, which turned out to be PondRAT. Unit42 published an analysis23 of the RAT, referring to it as PondRAT and showing similarities between PondRAT and another RAT used by Lazarus: POOLRAT.
As described by Unit42, there are similarities between POOLRAT and PondRAT. There is overlap in function and class naming and both families check for successful responses in a similar way.
POOLRAT has more functionality than PondRAT. For example, POOLRAT has a configuration file for C2 servers, can timestomp24 files, can move files around, functionalities that PondRAT lacks. We think this is because there is no need for more functionality if its main function is to load other malware, allowing for a smaller code base and less maintenance.
Command and Control
PondRAT communicates over HTTP(S) with a hardcoded C2 server. Messages sent between the malware and the server are XOR-ed first and then Base64-encoded. For XORing it uses the hex-encoded key 774C71664D5D25775478607E74555462773E525E18237947355228337F433A3B.
Figure 4: PondRAT check-in request
Figure 4 contains an example check-in request to the C2 server. The tuid parameter contains the bot ID, control indicates the request type, and the payload parameter contains the encrypted check-in information. In this case, control is set to fconn, indicating it is a bot check-in, matching with the corresponding function name FConnectProxy(). When receiving a server reply starting with OK, PondRAT fetches a command from the server. For at least one Linux and macOS variant, the parameter names and string values consisted of scrambled letters, e.g. lkjyhnmiop instead of tuid and odlsjdfhw instead of fconn.
Commands
PondRAT has basic commands, such as reading and writing files and executing programs. Table 2 lists all commands and their names from the symbol data. When a bot command is executed, the response includes both the original command ID and a status code indicating either success (0x89A) or failure (0x89B).
Command ID / Status code
Symbol name
Description
0x892
csleep
Sleep
0x893
MsgDown
Read file
0x894
MsgUp
Write file
0x895
Ping
0x896
Load PE from C2 in memory
0x897
MsgRun
Launch process
0x898
MsgCmd
Execute command through the shell
0x899
Exit
0x89a
Status code indicating command succeeded
0x89b
Status code indicating command failed
0x89c
Run shellcode in process
Table 2: PondRAT command IDs and their descriptions
Windows
Only the Windows samples we analysed had support for commands 0x896 and 0x89C. The DLL loading functionality seems to be based on the open-source project “Manual-DLL-Loader”25. As a sidenote, we analysed another POOLRAT Windows sample that used the “SimplePELoader” project26.
POOLRAT’s Little Brother
As mentioned by Palo Alto’s Unit42, PondRAT has similarities with POOLRAT. There is overlap in XOR keys, function naming and class naming. However, there are more similarities. Firstly, the Windows versions of PondRAT and POOLRAT use the format string %sd.e%sc "%s > %s 2>&1" for launching a shell command. Format strings have been discussed in the past27 and this specific format string was linked to Operation Blockbuster Sequel. Furthermore, PondRAT has a peculiar way of generating its bot ID, see the decompiled code below.
Figure 5: Bot ID generation for PondRAT (left) and POOLRAT (right)
Figure 5 shows how PondRAT and POOLRAT compute their bot ID. For PondRAT, tuid is the bot ID. It computes two parts of a 32-bit integer, that are split in two based on the bit_shift variable. Some of the POOLRAT samples compute the bot ID in a similar manner. The sample 6f2f61783a4a59449db4ba37211fa331 has symbol information available and contains a function named GenerateSessionId() that has this same logic.
More similarities can be found as part of the C2 protocol. PondRAT provides feedback to commands issued by the C2 server by returning the command ID concatenated with the status code. POOLRAT uses the same concept, see Figure 6.
Figure 6: Command status concatenation for PondRAT (left) and POOLRAT (right)
Another similarity can be found when comparing the Windows versions of POOLRAT and PondRAT. When running a Shell command (command ID 0x898) with PondRAT, the Windows version creates a temporary file with the prefix TLT in which it saves the command output. Then, it reads the file and sends the contents back to the C2 server and subsequently removes it. However, the way it removes the temporary file is remarkable.
It generates a buffer with random bytes and overwrites the file contents with it. Then, it renames the file 27 times, replacing all letters with only A’s, then B’s, etc. and with the last iteration renames all letters with random uppercase letters. For instance, when the file C:\Windows\Temp\tlt1bd8.tmp is deleted, it would first be renamed to C:\Windows\Temp\AAAAAAA.AAA, then to C:\Windows\Temp\BBBBBBB.BBB, and lastly to something like VYLDVAP.XQA. POOLRAT’s Windows version has the same functionality, see Figure 7.
Figure 7: Windows file name generation for PondRAT (left) and POOLRAT (right)
These similarities show that apart from variable data and symbol names, PondRAT is similar to POOLRAT in coding concepts as well. This further strengthens the connection between the two.
Summary
PondRAT is a simple RAT. Judging from the symbol data of macOS samples, its authors seem to refer to the malware as firstloader, a RAT that targets all three major operating systems. In our case, we observed it in combination with social engineering campaigns, whereas others have seen PondRAT being dropped through malicious software packages. Despite being simple in nature, it seems to do the job, given the frequency in which it is used. Judging from past incidents we investigated, PondRAT is a successor of POOLRAT.
Run, ThemeForest, Run!
In two incident response cases we found traces of a different RAT being used in conjunction with POOLRAT or PondRAT. We named it ThemeForestRAT, based on the substring ThemeForest which it uses in its C2 protocol. It is written in C++ and contains class names such as CServer, CJobManager, CSocketEx, CZipper and CUsbMan. ThemeForestRAT has more functionalities compared to PondRAT and POOLRAT.
In an earlier incident response case in 2020, we observed ThemeForestRAT in combination with POOLRAT. In the case from 2024, we observed it together with PondRAT. Its continued activity over at least five years demonstrates that ThemeForestRAT remains a relevant and capable tool for this actor. Besides Windows, we have observed Linux and macOS versions of the malware.
We believe that on Windows, this RAT is injected and executed in memory only, for example via PondRAT, or a dedicated loader, and is used as stealthier second-stage RAT with more functionality. The fact there are no direct samples of ThemeForestRAT on VirusTotal indicates it is quite successful in staying under the radar.
Overview
On startup, ThemeForestRAT attempts to read the configuration file from disk. When absent, it generates a unique bot ID and uses the hardcoded C2 configuration settings in the binary to create the configuration file.
Interestingly, the Windows variant creates two Windows events and accompanying threads that are used for signalling purposes (see Figure 8). However, the first thread related to the class CUsbMan only creates the temporary directory Z802056 and returns, this turned out to be legacy code as we will describe later.
The second thread monitors for new Remote Desktop (RDP) sessions and notifies the main thread when one is detected. Additionally, the thread checks for new physical console sessions and can optionally spawn extra commands under this session if this is enabled in the configuration.
Figure 8: ThemeForestRAT startup code creating two Windows events and threads for signalling
After creating these two threads it hibernates before connecting to the C2 server. The default hibernation period is three minutes but when it runs for the first time it checks in immediately. There are two cases where ThemeForestRAT wakes up from hibernation, either the hibernation period has passed, or one of the two events is signalled.
When it wakes up from hibernation it randomly selects a C2 server from its list and attempts to establish a connection. Upon receiving a response:OK acknowledgment, it downloads a 4-byte file that must decrypt to the 32-bit constant 0x20191127 to establish a valid C2 session. If this fails it will retry a different C2 and start over again, when the list of servers is exhausted it will go back into hibernation and try again later.
If it succeeds in establishing a C2 session, ThemeForestRAT sends basic system information including its wake-up reason to the C2 server, and the operator can now interact with the RAT as it keeps polling for new commands. When the operator sends an OnTerminate or OnSleep command (see Table 4), the C2 session ends, and the RAT goes back to hibernation.
Listing 2: ThemeForestRAT system information structure that is sent after establishing a C2 session
Listing 2 shows the structure definitions that ThemeForestRAT uses for sending system information when establishing a C2 session. The job_id field indicates the OS type, 0x10005 for Windows, and 0x20005 for both Linux and macOS as they share the same structure.
Configuration
The configuration file of ThemeForestRAT is encrypted with RC4 using the hex-encoded key 201A192D838F4853E300 and contains the following settings:
64-bit unique bot ID
List of ten C2 server URLs
Command interpreter, for example cmd.exe (not used)
List of optional commands to execute under the user of the active console session (Windows only, empty by default)
Matching array to enable the optional console command
Last check-in timestamp
Hibernation time between C2 sessions in minutes, default value is 3
C2 callback settings, for example to immediately check in on a new active RDP connection
The configuration can be parsed using the C structure definition from Listing 3.
Listing 3: ThemeForestRAT configuration structure definition for Windows
The configuration path that the RAT reads from disk is hardcoded. On macOS and Linux, this is an absolute path, while on Windows it looks in the current working directory where the RAT is launched. In Table 3 we list the observed configuration paths and hardcoded configuration file sizes for ThemeForestRAT.
Operating system
ThemeForestRAT configuration file on disk
File size
Windows
netraid.inf
43048 bytes
Linux
/var/crash/cups
43044 bytes
macOS
/private/etc/imap
43044 bytes
Table 3: Observed ThemeForestRAT configuration paths and their file sizes on Windows, Linux and macOS
Command and Control
ThemeForestRAT communicates over HTTP(S). The filenames it uses for retrieving commands from the C2 server are prefixed with ThemeForest_. The response data is sent back to the operator as a file prefixed with Thumb_, see Figure 6. On Windows it uses the Ryeol Http Client28 library for HTTP communications, and on macOS and Linux it uses libcurl. ThemeForestRAT has a single hardcoded C2 in the binary, but its configuration can be updated by sending the SetInfo command.
Figure 9: ThemeForestRAT sending encrypted system information to C2 server on initial check-in
Commands
In terms of command functionality, ThemeForestRAT supports over twenty commands, at least twice as much as PondRAT. The Linux and macOS versions contain debug symbols, which allows us to map the command IDs to function names where available.
Symbol name
Command ID
Description
ListDrives
0x10001000
Get list of drives
CServer::OnFileBrowse
0x10001001
Get directory listing
CServer::OnFileCopy
0x10001002
Copy file from source to destination on victim machine
CServer::OnFileDelete
0x10001003
Delete a file
FileDeleteSecure
0x10001004
Delete a file securely
CServer::OnFileUpload
0x10001005
Open a file for writing on victim machine
CServer::FileDownload
0x10001006
Download file from victim machine
Run
0x10001007
Execute a command and return the exit code
CServer::OnChfTime
0x10001008
Timestomp file based on another file on disk
–
0x10001009
–
CServer::OnTestConn
0x1000100a
Test TCP connection to host and port
CServer::OnCmdRun
0x1000100b
Run command in background and return output
CServer::OnSleep
0x1000100c
Hibernate for X seconds, this will also be saved in the configuration file
CServer::OnViewProcess
0x1000100d
Get process listing
CServer::OnKillProcess
0x1000100e
Kill process by process ID
–
0x1000100f
–
CServer::OnFileProperty
0x10001010
Get file properties
CServer::OnGetInfo
0x10001011
Get current RAT configuration
CServer::OnSetInfo
0x10001012
Update and save RAT configuration file
CServer::OnZipDownload
0x10001013
Download a directory or file as a compressed Zip file
CServer::OnTerminate
0x10001014
Flush configuration to disk and hibernate until next wake up
(Data)
0x10001015
Data
(JobSuccess)
0x10001016
Job succeeded
(JobFailed)
0x10001017
Job failed
GetServiceName
0x10001018
Return current service name
CleanupAndExit
0x10001019
Remove persistence, configuration file, and terminate RAT
RecvMsg
0x1000101a
Force C2 check-in
RunAs
0x1000101b
Spawn a process under the user token of given Windows Terminal Services session
–
0x1000101c
–
WriteRandomData
0x1000101d
Write random data to file handle
CServer::OnInjectShellcode
0x1000101e
Inject shellcode into process ID
Table 4: ThemeForestRAT command IDs and their descriptions
Note that the symbol names in Table 4 that start with CServer:: are from the debug symbols and the other names are deduced based on analysis of the command.
Shellcode Injection
On Windows, the CServer::OnInjectShellcode command injects shellcode into a given process ID using NtOpenProcess, NtAllocateVirtualMemory, NtWriteVirtualMemory and RtlCreateUserThread Windows API calls. The shellcode is encrypted using the same algorithm used in PerfhLoader (see Listing 1). In the macOS and Linux samples we have analysed, this command is defined as an empty stub.
RomeoGolf’s Little Brother
In 2016, Novetta released a detailed report called Operation Blockbuster29, in which a Novetta-led coalition of security companies analysed malware samples from multiple cybersecurity incidents. The investigation linked the 2014 Sony Pictures attack to the Lazarus Group and revealed that the same actor had been behind numerous other attacks against government, military, and commercial targets using related malware since 2009.
Operation Blockbuster’s malware report describes RomeoGolf, a RAT that resembles ThemeForestRAT in several ways:
Uses the temporary folder Z802056, although not used in ThemeForestRAT, is still created
Overlapping command IDs and functionality
Same unique identifier generation using 4 calls to rand()
Configuration file with extension *.inf on Windows
Timestomping of the configuration file based on mspaint.exe
Two signalling threads for USB and RDP events
Figure 10 shows the RomeoGolf startup logic for generating its bot ID and two signalling threads that is identical to ThemeForestRAT (see Figure 5).
Figure 10: RomeoGolf startup creates two signalling threads, comparable to ThemeForestRAT (see Figure 5).
As can be seen in Table 5, the functionality to detect and copy data from newly attached logical drives has been removed in ThemeForestRAT, while leaving the temporary directory creation intact. Also, the thread to check for new RDP sessions has been extended in ThemeForestRAT to optionally spawn up to ten extra configured commands under the user of the active physical console session.
RomeoGolf
ThemeForestRAT
Compilation date
Fri Oct 11 01:20:48 2013
Thu Sep 07 06:40:40 2023
Known configuration file
crkdf32.inf
netraid.inf
Configuration file timestomped to
mspaint.exe
mspaint.exe
USB thread logic
1. Creates %TEMP%\Z802056 2. Checks for newly attached drives and copies data to above folder 3. Signal on newly attached drives
1. Creates %TEMP%\Z802056
RDP thread logic
1. Signal on new active RDP sessions
1. Start configured commands under the user of the new active console session 2. Signal on new active RDP session if configured
C2 communication
Fake TLS
HTTP(S)
Highest known command id
0x10001013
0x1000101e
Table 5: Differences and similarities between RomeoGolf and ThemeForestRAT
While RomeoGolf used Fake TLS30 and its own custom server for its C2 communications, ThemeForestRAT uses the HTTP protocol and shared hosting for its C2 servers.
Onto the next stage with RemotePE
In the 2024 incident response case, we observed the actor cleaning up PondRAT and ThemeForestRAT, to deploy a more advanced RAT, which we named RemotePE. RemotePE is retrieved from a C2 server by RemotePELoader. RemotePELoader is encrypted on disk using Window’s Data Protection API (DPAPI) and is loaded by DPAPILoader. Using DPAPI enables environmental keying and makes it difficult to recover the original payload without access to the machine. DPAPILoader was made persistent through a created Windows service.
Figure 10: RemotePELoader check-in request to retrieve RemotePE payload
In Figure 10, we show a RemotePELoader check-in request used to retrieve RemotePE from the C2 server. RemotePE is written in C++ and is more advanced and elegant. We think that the actor uses this more sophisticated RAT for interesting or high-value targets that require a higher degree of operational security. Interestingly, it too uses the file renaming strategy PondRAT and POOLRAT Windows samples implement, except it skips the last random iteration.
We will publish a more thorough analysis of RemotePE in a future blogpost.
Summary
This blog is about a Lazarus subgroup that we have encountered multiple times during incident response engagements. This is a capable, patient, financially motivated actor who remains a legitimate threat.
We first discussed an incident response case from 2024, where this actor impersonated employees of trading companies to establish contact with potential victims. Though the method of achieving initial access remains unknown, we suspect a Chrome zero-day was used.
After initial access, two RATs were used in combination: PondRAT and ThemeForestRAT. Though PondRAT has already been discussed, there are no public analyses of ThemeForestRAT at the time of writing. For persistence, phantom DLL loading was used in conjunction with a custom loader called PerfhLoader.
PondRAT is a primitive RAT that provides little flexibility, however, as an initial payload it achieves its purpose. It has similarities with POOLRAT/SimpleTea. For more complex tasks, the actor uses ThemeForestRAT, which has more functionality and stays under the radar as it is loaded into memory only.
Lastly, we found the actor replaced ThemeForestRAT and PondRAT with the more advanced RemotePE. A detailed analysis of RemotePE will be published in the near future. So, stay tuned!
In Table 6 and 7, we list indicators of compromise related to the incident response cases we investigated and other artifacts we link to this actor.
Incident Response Support
If you have any questions or need assistance based on these findings, please contact Fox-IT CERT at cert@fox-it.com. For urgent matters, call 0800-FOXCERT (0800-3692378) within the Netherlands, or +31152847999 internationally to reach one of our incident responders.
Indicators of Compromise
Type
Indicator
Comment
net.domain
calendly[.]live
Fake calendly.com
net.domain
picktime[.]live
Fake picktime.com
net.domain
oncehub[.]co
Fake oncehub.com
net.domain
go.oncehub[.]co
Fake oncehub.com
net.domain
dpkgrepo[.]com
Potentially related to Chrome exploitation
net.domain
pypilibrary[.]com
Unknown, visited by msiexec.exe shortly after dpkgrepo[.]com
net.domain
pypistorage[.]com
Unknown, connection seen under SessionEnv service
net.domain
keondigital[.]com
LPEClient server, connection seen under SessionEnv service
Login
Table Of Contents
︎
for Cyber Threat Intelligence: Key Takeaways for Security Leaders
