Investigative methodology: Tracing the initial access vector in FortiGate appliances

Identifying the Initial Access Vector (IAV) is a cornerstone of any incident response engagement. However, when the source of compromise is not immediately obvious, particularly when edge device exploitation is involved, responders often need to take a broader investigative approach. Rather than starting with a clear point of entry, investigators must analyze the available telemetry, reconstruct attacker activity, and work backwards to determine how access was first obtained.

This process often involves multiple investigative workstreams running in parallel, each designed to answer different questions about the intrusion. As many IR responders and enthusiasts know, the first suspicious event observed during an investigation is rarely the first action taken by the attacker. Instead, it typically represents a point somewhere in the middle of a larger attack chain.

A key step in incident response investigations is reconstructing the attacker timeline. Responders often take an “inside out” approach where they move outward from the initial alert to the full scope of the malicious activity (IAV), correlating multiple data sources to map the unfolding of the event. This process involves examining authentication logs, endpoint telemetry, firewall events, and records of system changes, rather than depending on just one log source. It also typically requires frequent pivoting between artifacts as investigations rarely ever unfold in a linear fashion. By aligning these findings and events chronologically, investigators often identify activity that predates the initial alert.

CVE-2025-59718: Technical analysis and observed attacker behavior

The first activity that drew attention was enumeration and credential discovery within the internal environment. This basic enumeration included gathering information about users, systems, and accessible resources within common user directories. This activity eventually expanded to SMB-based file scraping and network share access, allowing attackers to review files stored across the environment. While this behavior resembled routine administration, the chronological sequence of file scraping and network share access painted a clear picture of an attacker’s initial discovery phase.

Digging deeper into the credential discovery activity, the popular tool Mimikatz was utilized to harvest credentials from various sources within the impacted environment. The attacker’s objective was to obtain valid credentials to an elevated admin account with the goal to blend in.

With credentials in hand and mimicking admin activity to disguise their actions, the attacker was then enabled to move laterally throughout the environment using common administrative tools and access methods. PsExec and Microsoft Remote Desktop (RDP) were two tools utilized for lateral movement while standard web browsers facilitated application access.

Attackers appeared particularly interested in systems that could provide broader access to the environment, including virtualization platforms, domain controllers, and servers supporting backup infrastructure. These systems often represent high-value targets for attackers seeking to escalate privileges, access sensitive data, or disrupt recovery capabilities.

Responders were working simultaneously to contain the attacker while building the narrative to cut them off at the source. With the current understanding of the narrative, the IAV puzzle began to unravel as more information came to light. Strangely, the first authentication into the Windows environment originated from an internal IP address that did not align with the known internal IP address ranges. It turns out, this internal IP address fell within the DHCP lease range of the FortiGate device. At first glance, this could be written off as legitimate VPN activity. However, to create even more questions, it was revealed that the FortiGate SSL VPN was never turned on within this environment. This revelation made the FortiGate device a prime suspect for IAV.

Taking a closer look at the FortiGate device, specifically system logs and configuration data, revealed early indications that the device had been modified to support continued access. The SSL VPN component had been enabled, and multiple configuration changes were identified, including edits to VPN settings, the creation of new firewall policies, and adjustments to configuration parameters. These changes appeared in FortiGate system logs as configuration updates similar to the following:

logid="0100044546" type="event" subtype="system" level="information"
vd="root" logdesc="Attribute configured" user="admins"
ui="GUI(45.32.216[.]250)" action="Edit" cfgpath="vpn.ssl.settings"
msg="Edit vpn.ssl.settings"

⠀

logid="0100044547" type="event" subtype="system" level="information" 
vd="root" logdesc="Object attribute configured" user="admins" 
ui="GUI(45.32.216[.]250)" action="Add" cfgpath="firewall.policy" 
cfgobj="XX" msg="Add firewall.policy <redacted>"

⠀

While these types of changes may seem routine in isolation, it is the combination and timing of these actions that raises concerns from a responder's perspective. The investigation's next key clue was identified when the source of these changes was traced back to a newly created account.

Following this thread further, investigators identified that multiple accounts had been created on the device, including SSO administrator, system administrator, and local accounts. Several of these accounts were associated with email domains attributed to Namecheap-hosted infrastructure, including domains such as openmail[.]pro. Notably, some of the newly created SSO administrator accounts were linked to forticloud.com domains as reflected in log entries such as:

Object attribute configured(Add system.sso-forticloud-admin <attacker account>@forticloud.com-1)

⠀

For responders, the creation of multiple new administrative accounts is often a strong indicator of persistence being established. Continuing to work backwards through the timeline, investigators identified that prior to these account creation events, the device’s configuration file was downloaded through the FortiGate UI. From an investigative perspective, configuration exports are highly valuable to attackers because they effectively serve as a blueprint of the environment, exposing network architecture, authentication mechanisms/settings, device relationships, and occasionally, sensitive credentials.

logid="0100032095" type="event" subtype="system" level="warning" 
vd="root" logdesc="Admin performed an action from GUI" user="admin" 
ui="GUI(104.28.227[.]105)" action="download" status="success" 
msg="System config file has been downloaded by user admin via GUI(104.28.227[.]105)"

⠀

The session associated with the configuration download was established from an external IP address flagged as “malicious” by security vendors with a local account already present on the device. All of these new findings from the attacker’s actions can now be utilized as IOCs to scope available FortiGate logs to determine any other leads.

By correlating activity with the known malicious IP addresses, investigators identified the true entry point: administrative SSO logins to the FortiGate appliance with valid accounts. Another important detail was that there was no evidence of brute-forcing activity for these local accounts. The initial access was established approximately two weeks before any subsequent malicious activity, indicating the attacker used this time to secure consistent access to the environment via the FortiGate device.

Actions such as changing configurations, creating accounts, and downloading configurations might seem harmless individually. However, when viewed together, these activities established a clear pattern consistent with the exploitation of CVE-2025-59718 that facilitated authentication bypass.

Once this groundwork was established through persistence mechanisms and discovery, attackers began authenticating into the environment with their newly created accounts via the SSL VPN connections that led us to investigate the FortiGate device in the first place. These sessions effectively transformed the firewall into an ingress point into the internal network, allowing attackers to move beyond the edge device.

This investigation highlights a common reality in incident response where the first indicator of suspicious activity is rarely the beginning of the story. Instead, responders are often working from a point somewhere in the middle, tasked with reconstructing attacker behavior and peeling back layers of activity to uncover how access was first obtained. 

By following the digital breadcrumbs left behind within available evidence sources, investigators were able to trace the intrusion back to its origin. This process emphasizes the importance of working backward through artifacts and telemetry, recognizing that each piece of data may lead to an earlier stage of attacker activity.

Network edge devices such as firewalls and VPN appliances are often the main vectors of initial access. Despite being critical infrastructure in modern environments, full visibility is rarely achieved in comparison to monitored endpoints. These edge devices can provide valuable evidence during investigations and reveal how initial access went unnoticed.

Conclusion: Key takeaways for defenders

The human element of investigation is crucial. Effective investigations demand a mindset of curiosity; on one side the willingness to dig deeper, and on the other, the ability to look at the big picture. At face value these can seem contradictory, but each facilitates a specific role within an incident response investigation.

Curiosity is what drives responders to grapple with the initial evidence, question assumptions, and identify which threads are worth pulling. It allows responders to move beyond surface-level observations and begin forming hypotheses about what may have occurred. The willingness to dive deeper is what turns those hypotheses into answers. Rather than stopping at the first suspicious event, responders must continue pivoting across logs, correlating activity, and tracing actions further back in time. At the same time, maintaining a big-picture perspective is critical. Individual artifacts or events may appear benign in isolation but when viewed chronologically the attacker behavior emerges.

Looking past any specific incident response methodology, visibility into the environment is essential. Even the strongest investigative approach is limited without access to the right telemetry, thus preventing responders from fully reconstructing an intrusion. In particular, as seen within this investigation, visibility into edge device activity can play a crucial role in unraveling IAV. The network edge is a hostile environment yet is frequently less monitored.

As is often the case with externally facing services and devices, the network edge is constantly targeted. Due to the sheer volume of persistent targeting, this environment can prove difficult to monitor for successful malicious intrusions. Implementing centralized syslog monitoring across these edge devices can close these visibility gaps. It can provide a real-time audit trail of connection attempts, configuration changes, and potential exploit signatures that occur before a threat reaches the internal network.

By effectively pulling on each investigative thread and ensuring visibility across both internal systems and edge devices, defenders can uncover compromises that might otherwise remain hidden. Often, the path to the beginning of the intrusion is already present; it simply requires knowing where, and how, to look.

Detection coverage for Rapid7 customers

Rapid7 actively monitors for emerging threats and leverages evidence from incident response engagements to develop new detection capabilities. Detections have been created and implemented by Rapid7 to pinpoint both exploitation attempts and post-exploitation activities related to FortiGate CVE-2025-59718. For InsightIDR and MDR customers, these detections alert on attacker activity consistent with the techniques described in this blog, enabling earlier identification and response before an intrusion can escalate further.

Detections:

• Potential Exploitation - FortiGate Admin SSO Login and Config Download via External IP

• Exfiltration - FortiGate Config Downloaded Using GUI via External IP

• Suspicious Authentication - FortiGate SSO Login via External IP

Mitigation guidance

Please refer to our initial blog from December, 2025.

MITRE ATT&CK Techniques

Indicators of compromise (IOCs)

Taking place May 12–13, this year’s summit brings together a mix of security leaders, practitioners, analysts, and industry voices to explore how organizations are moving from reactive defense to preemptive security operations. The focus is practical. What is changing, what is not working, and what teams need to do differently.

Voices from across the industry

This year’s lineup reflects that shift. Alongside Rapid7 experts and customer speakers, the summit will feature well-known voices from across the security community.

Rachel Tobac, CEO of SocialProof Security, joins the keynote panel The Reality of Running a SOC in 2026, bringing a perspective grounded in how modern attacks actually begin and how attackers adapt in real time. She is joined by cybersecurity speaker and “Smashing Security” podcast host Graham Cluley, whose work has long focused on translating complex threats into practical understanding for security teams.

From an analyst perspective, Craig Robinson of IDC and Dave Gruber of Omdia add an external view on how the market is evolving, where organizations are investing, and how security programs are being measured. Their contributions help ground the discussion in broader industry trends, not just individual experiences.

Customer voices also play a central role. Leaders from organizations such as Netscout Systems, Target RWE, and Miltenyi Biotecwill share how they are navigating complexity, validating decisions around MDR and platform consolidation, and focusing on outcomes rather than activity.

What to expect during the show

Across two days, the summit is structured to reflect how security teams actually operate.

Day one focuses on shared context with sessions like Defense Starts Earlier Than You Think and The Reality of Running a SOC in 2026 examining how the threat landscape has shifted and why traditional approaches are struggling to keep pace. From there, sessions such as Inside the Modern SOC and Using Red Teaming to Power Preemptive MDR move into how detection, response, and validation work in practice.

The goal is to connect the full picture: how attacks begin, how they progress, and how teams respond when it matters.

Day two is more focused on the unique needs of particular security roles. The two dedicated tracks allow attendees to go deeper into the implications of modern security evolution based on their daily realities.

For security leaders, sessions such as The CISO’s Role in Enterprise Transformation and A CISO’s Guide to MDR Accountability and Outcomes explore governance, accountability, and ways to measure effectiveness that reflect real business risk.

For practitioners, sessions like Hunt or Be Hunted and IR in Practice focus on the mechanics of investigation, detection and response. These sessions look closely at how analysts triage signals, how decisions are made under pressure, and how response workflows hold up in real environments.

Across both days, the agenda is designed to move beyond theory with each session connecting back to the same core concept. Security teams need to act earlier, reduce uncertainty, and make decisions with greater confidence.

Secure your spot

If you are looking to understand how security operations are evolving, and how teams are putting that into practice, this is where those conversations come together.

Join us May 12–13 and see how organizations are building more resilient, preemptive security operations.

Register now.

This week, we added a whole new bunch of HTTP/HTTPS-based CMD payloads for X64 and X86 versions of Windows. The additional breadth of selectable payloads and delivery techniques allows users new options to tailor the attack workflow for their environment. This was contributed by bwatters-r7. Adding new architectures for adapted payloads is surprisingly easy and something a first-time contributor might want to look into!

New modules added to Metasploit Framework also allow for targeting FreeScout and Grav CMS, both of which result in remote code execution. These modules were contributed by Chocapikk and x1o3 respectively. Thanks!

Thanks to g0tmi1k, Metasploit Framework now also includes an exploit module, multi/http/os_cmd_exec, which allows for targeting generic HTTP command execution vulnerabilities where user-supplied input is directly passed to system execution functions via an HTTP request. This can result in a Meterpreter shell on the remote target.

To round this week off, we have a new persistence technique on Windows, thanks to Nayeraneru, which abuses the HKCU\Environment\UserInitMprLogonScript registry value to execute a payload at user logon.

New module content (5)

FreeScout Unauthenticated RCE via ZWSP .htaccess Bypass

Authors: Moses Bhardwaj (MosesOX) , Nir Zadok (nirzadokox) , Valentin Lobstein chocapikk@leakix.net, and offensiveee

Type: Exploit

Pull request: #21069 contributed by Chocapikk

Path: multi/http/freescout_htaccess_rce

AttackerKB reference: CVE-2026-27636

Description: This adds an exploit module for CVE-2026-28289, an unauthenticated remote code execution vulnerability in FreeScout versions prior or equal to 1.8.206.

Grav CMS Admin Direct Install Authenticated Plugin Upload RCE

Authors: binneko and x1o3

Type: Exploit

Pull request: #21029 contributed by x1o3

Path: multi/http/grav_admin_direct_install_rce_cve_2025_50286

AttackerKB reference: CVE-2025-50286

Description: This adds a new exploit module for CVE-2025-50286, an authenticated RCE vulnerability in Grav CMS 1.1.x–1.7.x with Admin Plugin 1.2.x–1.10.x. The module exploits the Direct Install feature to upload a malicious plugin ZIP and execute an arbitrary PHP payload as the web server user.

Generic HTTP Command Execution

Authors: egypt egypt@metasploit.com and g0tmi1k

Type: Exploit

Pull request: #21023 contributed by g0tmi1k

Path: multi/http/os_cmd_exec

Description: Adds a new exploits/multi/http/os_cmd_exec module that targets generic HTTP command execution vulnerabilities where user-supplied input is directly passed to system execution functions via an HTTP request.

Windows Persistence via UserInitMprLogonScript

Author: Nayera

Type: Exploit

Pull request: #21032 contributed by Nayeraneru

Path: windows/persistence/userinit_mpr_logon_script

Description: This adds a new Windows persistence module that abuses the HKCU\Environment\UserInitMprLogonScript registry value to execute a payload at user logon.

HTTP and HTTPS Fetch

Authors: Brendan Watters, Chris John Riley, hdm x@hdm.io, sf stephen_fewer@harmonysecurity.com, and vlad902 vlad902@gmail.com

Type: Payload (Adapter)

Pull request: #21172 contributed by bwatters-r7

Description: This adds HTTP and HTTPS fetch payloads for 32-bit Windows targets.

Enhancements and features (8)

• #20999 from Aaditya1273 - Removes the legacy windows/local/persistence module, which has been superseded by the modernized windows/persistence/registry module. A moved_from alias ensures that existing scripts and workflows referencing the old module path are automatically redirected to the new one with a deprecation warning.
• #21090 from g0tmi1k - Updates multiple modules to make use of report_service().
• #21097 from g0tmi1k - Updates auxiliary/scanner/ftp/anonymous.rb to report the FTP service regardless of anonymous being enabled.
• #21144 from Nayeraneru - Improves YARD documentation for lib/msf/core/auxiliary/web/http.rb by documenting the Request and Response helpers, the public HTTP request APIs, and the internal custom-404/request-handling flow.
• #21145 from Nayeraneru - Adds YARD docs to lib/msf/core/auxiliary/auth_brute.rb, focusing on the AuthBrute mixin’s credential-building, brute-force state, logging, and cleanup helpers.
• #21150 from Nayeraneru - Adds YARD documentation to lib/msf/core/payload/adapter/fetch.rb to improve consistency and clarify how the fetch adapter generates URIs, builds fetch commands, and resolves platform-specific execution behavior.
• #21194 from bcoles - This updates the post/linux/gather/enum_protections module by adding documentation and additional checks for modern protections and applications.
• #21214 from adfoster-r7 - Adds additional validation to db_import before attempting to import values.
• #21048 from zeroSteiner - Not written - add release notes directly to the pull request, then regenerate. Do not edit manually without ensuring the pull request has the release note present.

Bugs fixed (6)

• #21004 from EclipseAditya - This fixes a bug in the #normalize_key method provided by the Windows Registry mixin. The result is correct behavior when using shell sessions to check for keys with trailing \ characters.
• #21138 from g0tmi1k - Fixes a bug that stopped the auxiliary/server/dhcp module from running as a background job when RHOSTS had been set.
• #21188 from adfoster-r7 - Fixes a crash on older Ruby versions when scanning binary files.
• #21199 from Hemang360 - Fixes crash in auxiliary/scanner/http/wp_perfect_survey_sqli when run against invalid or unreachable targets.
• #21207 from zeroSteiner - Fixes warning when running the linux/gather/enum_protections module.
• #21208 from adfoster-r7 - Fixes multiple warnings in modules that reported notes incorrectly.
• #21073 from Hemang360 - Fixes a bug where running exploit/multi/handler with a reverse HTTP/HTTPS payload multiple times on the same port caused cleanup issues.

Documentation added (6)

• #21149 from Adithyadspawar - Adds documentation to the following login scanners: ftp/bison_ftp_traversal, http/apache_activemq_traversal, http/coldfusion_version, http/drupal_views_user_enum and http/elasticsearch_traversal.
• #21186 from Devansh7006 - Adds documentation for the wordpress_pingback_access module.
• #21187 from Devansh7006 - Updates documentation for auxiliary/scanner/http/http_put.
• #21200 from dineshg0pal - Updates the example code snippet for writing Metasploit Go modules.
• #21201 from aryan9190 - Adds YARD documentation for Rex::Post::IO class.
• #21217 from dineshg0pal - Fixes minor errors in documentation files.

You can always find more documentation on our docsite at docs.metasploit.com.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:

• Pull Requests 6.4.124...6.4.125
• Full diff 6.4.124...6.4.125

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest. To install fresh without using git, you can use the open-source-only Nightly Installers or the commercial edition Metasploit Pro

This article explains why many breaches are driven by gaps in visibility rather than advanced exploits, how attackers move through modern environments, and what changes when organizations start connecting assets, identities, and attack paths into a single view.

What is a visibility problem in cybersecurity?

A visibility problem exists when security teams cannot clearly answer three basic questions: what assets exist, who or what can access them, and how those elements connect. When those answers are incomplete, decisions are made based on assumptions – and that creates conditions where risk can grow, unnoticed.

As environments expand across cloud, SaaS, and hybrid infrastructure, the number of systems and identities grows quickly. What often falls behind is a clear understanding of how they relate to each other, and that gap is where attackers tend to operate.

How visibility gaps turn into breaches

A large medical technology organization experienced a breach driven by a series of compounding gaps rather than a single exploit. Internet-exposed assets created the initial entry point, while inconsistencies in device posture and identity enforcement, including gaps in platforms like Intune, weakened the security boundary. Attackers leveraged exposed or reused credentials and over-permissioned access to move laterally across systems. Without unified visibility across assets, identities, and managed devices, the attack path remained invisible until critical systems were reached.

Each of these conditions is common on its own, but what makes them dangerous is how they connect.

Why most attacks are not about flashy exploits

This breach did not rely on a zero-day vulnerability or an advanced technique. It depended on an exposed asset, valid credentials, and inconsistent enforcement across identity and devices. Those elements exist in most environments, but without visibility into how they overlap, they can be combined into a viable attack path.

Security teams often evaluate vulnerabilities individually, while attackers focus on how those weaknesses can be chained together. The risk is not just in what is vulnerable, but in how exposure allows movement.

What a visibility-first approach looks like

Improving outcomes depends on understanding how exposure exists across the environment and how different elements relate to each other.

Asset visibility is the starting point. Many organizations cannot confidently identify everything that is externally accessible, and attackers often find assets that were never intended to be exposed. Continuously mapping assets across cloud and on-prem environments reduces that uncertainty and limits entry points.

Identity is just as critical. Once access is established, movement depends on credentials and permissions. Stolen credentials, over-permissioned accounts, and weak authentication paths allow attackers to move beyond initial entry. Treating identity exposure as part of the attack surface helps identify these risks earlier, especially when leaked credentials can be tied to active accounts and privileges.

Attack path visibility connects these elements. Instead of evaluating findings in isolation, it shows how exposures can be combined into realistic attack scenarios. Through adversarial simulation, organizations can observe how an attacker could move from an exposed system to internal resources, which shifts focus toward removing viable paths rather than addressing isolated issues.

External signals, such as credential leaks, only become meaningful when tied back to internal systems. Monitoring for exposed credentials is useful, but correlating those credentials with active accounts and access levels is what turns that signal into something actionable.

Controls such as least privilege and multi-factor authentication remain essential, but they are only effective when applied consistently. Without visibility into where access exists, enforcement gaps are difficult to detect.

Why visibility changes the security outcome

The difference in a scenario like this is not simply better tooling. It is a shift in how exposure is understood and prioritized.

Attackers look for the easiest path through an environment. A visibility-first approach identifies those paths earlier, reduces them, and then examines why they existed. That changes how teams prioritize work, moving from reacting to individual findings toward removing viable attack paths.

How this works in practice

This is where platforms like Rapid7 support a more complete view of exposure. Surface Command aggregates telemetry from over 190 sources, helping organizations unify fragmented views of assets and identities. InsightCloudSec extends that visibility into cloud environments by enforcing best practices and least privilege without relying on manual processes. Vector Command focuses on how attackers move, using continuous testing and simulation to show how attacks would unfold across an environment.

On the intelligence side, integrating threat data with identity systems allows external signals, such as credential leaks, to be mapped to active accounts and validated in real time. That makes it possible to act before those credentials are used.

Together, these capabilities provide a clearer understanding of how exposure translates into risk.

Putting visibility at the center of security

Zero trust depends on more than policy. It requires visibility, identity, validation, and enforcement to work together continuously.

Without visibility, zero trust becomes difficult to apply in practice. With it, security decisions can be based on how systems actually behave rather than how they are expected to behave, which shifts organizations away from reacting to incidents and toward preventing them from forming.

Advanced persistent threats (APTs) are constantly and consistently changing tactics as network defenders plug holes in defenses. Static indicators of compromise (IoCs) for the BPFDoor have been widely deployed, forcing threat actors to get creative in their use of this particular strain of malware. What they came up with is ingenious.

New research from Rapid7 Labs has uncovered undocumented features leading to the discovery of 7 new BPFDoor variants: a stealthy kernel-level backdoor that uses Berkeley Packet Filters (BPFs) to inspect traffic from right inside the operating system kernel. This essentially creates a silent trapdoor that can be activated by a threat actor once a “magic packet” is tunneled via stateless protocols. The malware is then able to perfectly blend into the target environment, establishing nearly undetectable persistence in global telecom infrastructure.

Our latest research continues the narrative established in our blog BPFdoor in Telecom Networks: Sleeper Cells in the Backbone. It involves the analysis of nearly 300 samples and  identifies two primary new variants: httpShell and icmpShell. These variants represent a significant leap in operational security, utilizing stateless C2 routing and ICMP relay to bypass multi-million dollar security stacks.

Rapid7 detection and response strategy:

Rapid7 is actively tracking these variants to ensure our customers remain protected against this evolving threat through the following:

• Intelligence Hub: Customers with access to Rapid7’s Intelligence Hub are receiving continuous updates, including the latest intelligence, YARA rules, and Suricata detection rulesets.

• Actionable guidance: We have released a specialized triage script (rapid7_bpfdoor_check.sh) designed to identify both legacy and modern BPFDoor variants by inspecting active BPF filters and validating masqueraded processes.

• Detection engineering: Our detection strategy focuses on structural header anomalies, such as hardcoded ICMP sequence numbers and invalid protocol codes, rather than transient payload content.

The strategic shift: Beyond legacy stealth

While BPFDoor has been active for years, its codebase has evolved significantly. The threat actor continues to incorporate minor features into the original codebase leaked in 2022, resulting in a "messy" but effective toolkit designed to hinder threat hunting. Given the significant code overlap among BPFDoor variants, we focused on the minor, easily overlooked details the TA (threat actor) added to the leaked codebase.

From memory to disk

Historically, BPFDoor was known for appearing "fileless" by executing from /dev/shm and deleting itself. However, modern endpoint detection and response (EDR) tools now flag processes running from deleted inodes in temporary filesystems. Recognizing this, the developers of the httpShell variant have eliminated the /dev/shm drop. The malware now resides on disk, using a single, hard-coded process name to blend in as a normal system daemon.

Technical analysis: httpShell vs. icmpShell

Our research unraveled several undocumented features (some of them were not documented for nearly 5 years), leading to the discovery of two primary variants: httpShell and icmpShell.

httpShell: The "Magic Ruler" of encapsulated traffic

The httpShell variant leverages kernel-level packet filters to perform validation across both IPv4 and IPv6 traffic. It uses HTTP-tunneling to extract hidden commands and features a newly discovered "Hidden IP" (HIP) field for dynamic routing.

• Kernel-level decapsulation: By binding to all interfaces simultaneously, the malware forces the target’s own kernel to decapsulate complex carrier-grade tunnels like GRE or GTP. This allows the BPF filter to easily catch magic bytes hidden inside the inner packets.

• The offset evasion: To survive enterprise proxies and WAFs that shift data positions, attackers use a mathematical padding scheme. They ensure their "9999" marker always lands exactly at the 26th byte offset of the inspected data, allowing the trigger to survive proxy headers.

• IPv6 limitations: The filter assumes the UDP/TCP header starts exactly at byte 40 (standard empty IPv6 header). If an attacker includes IPv6 "Extension Headers," the payload is pushed further down, and the malware fails to wake up.

icmpShell: The dynamic PTY tunnel

Designed for heavily restricted environments, icmpShell tunnels interactive sessions entirely over ICMP.

• PID-bound mutation: This variant injects a dynamic BPF filter into the kernel that binds specifically to the malware's runtime Process ID (PID). Because the PID changes with every execution, the required "magic knock" signature mutates dynamically, rendering static firewall rules useless.

• Multi-mode execution: Beyond basic shells, it implements bidirectional ICMP tunnels, UDP and ICMP “hole-punching”, and RC4 encryption.

Both variants support relay over ICMP.

Stateless C2 and the "Hidden IP"

⠀

The discovery of the magic_packet_v2 struct featuring the HIP (hidden ip field) used for relay purposes highlights the malware's operational maturity.

Dynamic C2 routing

One of the most elegant features is the use of a -1 flag (255.255.255.255) in the IP field of the magic packet structure.

• Mechanism: If the flag is set, the malware ignores hardcoded IPs and sends its reverse shell back to the source IP found in the headers of the packet that woke it up.

• Strategic purpose: This makes the attacker's controller completely stateless. Attackers can deploy from behind NAT or VPNs without needing to discover or hardcode their current external IP into the magic payload.

ICMP lateral movement (the relay)

if (auth(mpacket->pass) || mpacket->hip == -1 || !mpacket->hip)

When the above "Gatekeeper Condition" (authentication) is false, the malware transforms the infected machine into an invisible network router.

⠀

• The process: It extracts an internal target IP from the HIP field, rewrites the trigger flag to ICMP magic bytes (0x5572), and fires a crafted ICMP Echo Request at the internal target.

• Loop prevention: The malware wipes the hop IP to -1 to stop the next BPFDoor instance from forwarding the packet again.

⠀

Rapid7 set up a playground lab to test icmpShell. For this scenario, two docker containers simulating an nginx edge proxy and a victim HSS infected with icmpShell have been used, while the attacker executes the trigger sending the magic packet via the newly discovered Rapid7 BPFDoor controller. To interact with the shell we developed the python script icmpshell.py to ensure RC4 state is consistent across echo requests received on the attacker’s side, filtering out also heartbeat echo requests featuring an invalid ICMP code 1.

In the bottom-right pane of the video below, we see the icmpShell variant being run with strace to debug its behavior. The top-left shows the controller triggering the backdoor after entering the new “icmp” password and crafting a magic packet over HTTPS (we will break down HTTPS tunneling and the new Rapid7 controller in a future blog) using magic bytes 0x5293. On the bottom-left pane the icmpshell.py runs to perform the ICMP handshake and handle shell traffic.  The connection over ICMP established between the attacker machine (REMnux) and the victim HSS leverages a second BPF filter (13-BPF instructions), installed by the backdoor that uses the reverse shell PID as a fixed ICMP ID, ensuring the capture of shell-related packets. On the upper-right pane, an ICMP tcpdump capture is run.

⠀

⠀

The video ends showing that the backdoor exits after 12s of attacker inactivity, killing the connection. The tcpdump capture shows attacker traffic being sent in cleartext prepending ‘X:’ to commands while the victim response is RC4 encrypted with the key “icmp”.

Below, we can observe the tcpdump screens highlighting ICMP handshake, shell’s data encryption, attacker’s command and the usage of 1234 ICMP sequence number hardcoded in the backdoor.

⠀

⠀

⠀

Figure 7 below shows the heartbeat payload ignored by icmpshell.py acting as an ICMP “hole-punching” to keep the firewall state table active.

Rapid7 variants

The research of new variants is still ongoing. At the time of writing, Rapid7 identified seven new variants featuring new magic bytes and active C2 beaconing summarized below.

Samples 2cc90edd9bc085f54851bed101f95ce2bace7c9a963380cfd11ea0bc60e71e0c and de472ed37e33b79e1aa37e67a680ee3a9d74628438c209543a06e916a0a86fba, which we classify as R7 variant ‘F’, increase stealthiness by hiding under /var/run/user/0. By avoiding the usual chmod command, the attacker ensures that no "change mode" event is logged by the kernel's audit system (auditd). Since /run is rarely mounted with the noexec flag (unlike /tmp), the malware bypasses the most common local hardening measure.

⠀

⠀

Most samples simply redirect output to /dev/null. This variant goes further by performing a total FD (File Descriptor) wipe. Note the recurring timestomping routine following the old known anti-forensics technique.

⠀

R7 variant ‘F’ exhibits a 26-BPF instruction filter featuring new magic bytes. Rapid7 developed a tool to extract BPF bytecode logic and identify variant-specific features. Three samples employed previously unknown magic bytes. Below is the output summarizing the filtering logic (Figure 10: 2cc90edd9bc085f54851bed101f95ce2bace7c9a963380cfd11ea0bc60e71e0c

De472ed37e33b79e1aa37e67a680ee3a9d74628438c209543a06e916a0a86fba; Figure 11: 757e911edaf45cc135f2498c38d4db8acec39cb6aeb3a1dcc38305ab2d326fa9).

⠀

The BPF filtering can be expressed using libcap syntax:

udp[8:2] == 0x3182 or (icmp[8:2] == 0x1051 and icmp[icmptype] == icmp-echo) or tcp[((tcp[12]&0xf0)>>2):2] == 0x3321

⠀

⠀

udp[8:2] == 0x2048 or (icmp[8:2] == 0x1155 and icmp[icmptype] == icmp-echo) or tcp[((tcp[12]&0xf0)>>2):2] == 0x5433

Earlier versions used SOCK_RAW when creating the AF_PACKET socket. When using SOCK_RAW, the kernel delivers the entire packet, including the link-layer header, while with SOCK_DGRAM the Ethernet header is discarded. This change directly impacts the way packets are parsed.

Multi-protocol parallel sniffing

One new variant sample, which we named variant ‘G’, utilizes a multi-threaded architecture to ensure triple-redundant capture of "wake-up" packets. The malware spawns three independent threads, each responsible for monitoring a specific transport protocol at the raw IP layer.

This is achieved by invoking the socket() system call with protocol-specific parameters for TCP, UDP, and ICMP:

• TCP: socket(AF_INET, SOCK_RAW, IPPROTO_TCP)

• UDP: socket(AF_INET, SOCK_RAW, IPPROTO_UDP)

• ICMP: socket(AF_INET, SOCK_RAW, IPPROTO_ICMP)

The implant achieves simultaneous trigger detection across three protocols by deploying identical BPF filters on protocol-specific raw sockets. This functionality is implemented using three separate threads for protocol capture. This design is crucial: By dedicating a thread to each protocol, the malware prevents high-volume traffic in one protocol from overloading the sniffer and causing it to miss a "magic" trigger arriving via a less-trafficked protocol.

Beyond preventing packet loss, this parallel architecture provides C2 resiliency via built-in fallback channels. Because the BPF filters concurrently sniff TCP, UDP, and ICMP, the threat actor becomes highly resilient to sudden perimeter security changes. If a network defender updates an egress firewall to aggressively block anomalous ICMP or UDP traffic, the attacker can seamlessly switch to sending magic triggers over TCP.

Some samples (Figure 12: ed768dd922742a597257ad684820d7562bb6be215710ec614bd041a22f3d6863) exhibit the usage of threads and a new mutex/process name being spoofed like “hpasmlited”:

⠀

Then start_routine, sub_4089BB, sub_4084F7 proceeds with the old codebase installing the same BPF filter shared among TM variant D samples; this variant supports ICMP relay.

Below is shown the creation of three different kinds of sockets filtering traffic by TCP, UDP, and ICMP:

⠀

Note that a0t is an array containing three BPF filters, each of them containing the same 229 instructions found in TM variant D. 

HPE ProLiant-tuned variant: Living off the land

One variant  (Figure 14: 9ee77ed38e5bc69f841bdaba7c5e6c3bf30fd9ae94cd2e69f39834e9cec76e82) was specifically tailored for HPE ProLiant servers, demonstrating a "living off the land" approach through binary masquerading.

⠀

The process name is set to cmathreshd, with realistic flags like -p 5 -s OK, directly impersonating the HPE Insight Management Agents. The malware checks for /var/run/cma.lock. If found, it kills the legitimate HP agent and takes its place. This displacement prevents resource conflicts that would otherwise alert system administrators. The call to unsetenv("LD_PRELOAD") is designed to disable user-mode security hooks (such as local EDRs or rootkit hunters) that monitor system calls.
This specific masquerading tactic demonstrates deep environmental awareness. The threat actors recognize they are operating on physical, bare-metal HPE hardware commonly deployed in 4G and 5G core and edge systems (such as Ericsson-style architectures). 

The active beacon: Guaranteed persistence

Rapid7 variant ‘H’ contrasts with the classic, stealthy BPFDoor sniffer (which generates no outbound traffic). The beacon is proactive and provides guaranteed access by bypassing stateful firewalls that only permit outbound connections. It achieves this via a continuous heartbeat mechanism that resolves dynamic DNS domains, such as ntpussl.instanthq.com and ntpupdate.ddnsgeek.com. By masquerading as Network Time Protocol (NTP) over SSL, the threat actors seamlessly encapsulate their encrypted C2 sessions within what appears to be routine time synchronization or IoT telemetry. This 'hide in plain sight' tactic allows the active beacon to blend into the baseline network noise and establish a direct, unauthenticated connection on port 443 using the old-fashioned statically linked OpenSSL library and RC4-MD5 ciphersuite.

• Heartbeat mechanism: The function actively attempts to resolve the hardcoded C2 domain ntpussl.instanthq.com using the gethostbyname() function. It runs in an infinite loop, attempting to connect if the domain resolves. If the connection fails, it sleeps for a random interval (1 to 2.5 minutes) before trying again — this acts as the Heartbeat.

• Masquerading: The domain ntpussl.instanthq.com mimics NTP (Network Time Protocol) over SSL, blending into standard time-sync or certificate update traffic.

• Activation kill switch: A "Kill Switch" or "Activation" check verifies the IP returned by the DNS query: if ( !strstr(v1, "127.0.0.1") ).

• Direct connection: The malware connects to the resolved IP on port 443 (0x1BB) without requiring authentication.

⠀

Stack strings were employed to bypass basic static signature detection:

⠀

By encapsulating encrypted shell sessions within what appears to be routine time synchronization or IoT telemetry, the threat actors effectively bypass standard firewall rules. Below is the list of domains observed being used by Chinese TAs during espionage campaigns:

"Encrypted" Masquerade

• Domain: ntpussl[.]instanthq.com

• Function & analysis: Encrypted Shell/Tunneling. "ntpussl" recalls an ssl connection with an NTP server. (195b98211d1ce968669a0740ca08d0ddcf03a2df03a47e2e70550f6c002b49e8; 9ee77ed38e5bc69f841bdaba7c5e6c3bf30fd9ae94cd2e69f39834e9cec76e82).

"System Update" Disguise

• Domain: ntpupdate.ddnsgeek[.]com
• Function & analysis: Standard Utility Mimicry. This domain mimics the common ntpdate utility. The use of terms like "geek" or "update" is a social engineering tactic, as security analysts often overlook such domains, assuming they belong to benign OS background processes (ca56622773c1b6f648b1578978b57aa668df25a11e0c782be008384a6af6c2c4).

"Persistence" Disguise

• Domain: ntpupdate.ygto[.]com
• Function & analysis: Rapid IP Rotation. This domain is employed for dynamic DNS updates, enabling rapid IP rotation. If the primary C2 IP address is blocked, the attackers update the DDNS record at ygto.com to maintain command-and-control access.

"IoT/Camera" Disguise

• Domain: ntpd.casacam[.]net
• Function & analysis: Blending with residential traffic. Masquerades as a time check service for IP cameras. Since casacam.net is a legitimate DDNS provider for DVRs, traffic to this domain easily blends into the millions of devices monitored by telecom networks, especially in residential broadband environments.

Note: The domains ntpupdate.ygto[.]com and ntpd.casacam[.]net are involved in generic trojan/spam campaigns.

Rapid7 variants I,J,K and L

Rapid7 variant “I” uses an 11-instruction BPF filter targeting TCP port 9999, enforcing a two-step handshake, requiring firstly new magic bytes (0xA9F205C3) in the tcp payload, secondly the presence of a hardcoded magic password (dP7sRa3XwLm29E). Finally, it extracts the attacker’s IP and port to spawn an unencrypted reverse shell.

Rapid7 assigned icmpShell and httpShell variants the letters J,K respectively while the letter L is reserved for samples exhibiting only the ICMP relay feature. To summarize:

• Variant J: ICMP relay + HTTP tunneling + icmpShell

• Variant K: ICMP relay + HTTP tunneling

• Variant L: ICMP relay

MITRE ATT&CK Matrix Mapping

Tactic: Execution

T1059.004: Unix Shell

• Implementation details: Hijacks a pseudo-terminal (PTY) utilizing fork() and dup2().
• Variation: Both

Tactic: Defense Evasion

T1036.004: Masquerading

• Implementation details: Alters process arguments to mimic benign daemons like qmgr.
• Variation: Both

T1070.003: Clear History

• Implementation details: Injects HISTFILE=/dev/null into environment variables.
• Variation: Both

T1027: Obfuscated Files Information

• Implementation details: Stack strings for passwords and paths prevent static extraction.
• Variation: Both

T1564: Hide Artifacts

• Implementation details: Uses AF_PACKET sniffing to remain invisible to local netstat/ss.
• Variation: Both

Tactic: Persistence

T1205: Traffic Signaling

• Implementation details: Employs magic bytes and flags like 0xFFFFFFFF as wake-up triggers.
• Variation: Both

Tactic: Command & Control

T1573.001: Symmetric Cryptography

• Implementation details: e.g. Enforces the X: plaintext tag and encrypts the underlying PTY output via an RC4 cipher (using the hardcoded ICMP key).
• Variation: Both

T1071.001: Application Layer Protocol

• Implementation details: Blends in by utilizing formatted HTTP POST requests with hardcoded URIs up to 100-byte hexadecimal bodies.
• Variation: httpShell

T1095: Non-App Protocol

• Implementation details: Transmits exfiltration via crafted ICMP Echo Requests.
• Variation: Both

T1090: Proxy

• Implementation details: Uses ICMP relay to bounce traffic through internal segments.
• Variation: Both

T1001: Data Obfuscation

• Implementation details: icmpShell hides its tracking mechanisms directly inside the network layer headers. By truncating the Linux Process ID (PID) and injecting it into the 16-bit ICMP Identifier field, and hardcoding the ICMP Sequence Number to 1234, it obfuscates its session tracking data as standard network metadata.
• Variation: icmpShell

T1572: Protocol Tunneling

• Implementation details: ICMP tunneling
• Variation: icmpShell

T1090: Proxy

• Implementation details: The BPF filter concurrently sniffs TCP, UDP, and ICMP. If one protocol is blocked by egress filtering, the attacker can seamlessly utilize an alternate protocol to trigger the shell without reconfiguring the implant.
• Variation: Both

Defensive depth and detection guidance

Detection must shift from looking for payload content to identifying structural anomalies and static protocol markers.

• Suricata/NIDS focus: Target the hardcoded 1234 sequence number used in custom functions and the technically invalid ICMP Code 1 injected by the heartbeat thread.

• Host monitoring: Monitor for processes whose executable path does not exist on disk and spoofed processes running as root (e.g., zabbix_agentd, dockerd).

• Auditd rules: Monitor the creation of AF_PACKET sockets (capturing SOCK_RAW and SOCK_DGRAM) and the setsockopt call used to attach BPF filters.

• Rapid7 triage script: Utilize the rapid7_bpfdoor_check.sh script to check for zero-byte mutex files and active BPF filters attached to packet sockets. Get the complete checklist at Rapid7’s github.

Final takeaways

• Kernel-level evasion: The shift to SOCK_DGRAM allows the malware to simplify magic packet parsing by letting the host kernel decapsulate tunnels.

• Layer 7 camouflage: Weaponized SSL termination and "magic ruler" padding ensure trigger bytes survive WAF/Proxy interference.

• Deep-network lateral movement: The "Hidden IP" field transforms infected machines into invisible network routers for bidirectional ICMP PTY tunnels.

• New Variants: the newly identified features in BPFDoor samples highlight how TAs are tailoring and reusing BPFDoor’s code to the target environment. The rapid7 variant H (active beacon) stands out as it tries to blend in with the network traffic contacting fake NTP update servers.

• Operational security: The malware can instruct the infected node to spawn a shell to the source of the magic packet using the signed -1, without embedding the C2 or proxy IP in the packet payload. Furthermore, unlike httpShell, the icmpShell is designed to run without requiring live interaction as it terminates itself after 12s of inactivity, demonstrating how surgical and precise the TA intervention is when accessing the core of the backbone, achieving maximum stealthiness.

For an exhaustive deep dive of the assembly code, BPF bytecode, and exact packet structures used by icmpShell and httpShell variants, please refer to our technical whitepaper here. You can also view our on-demand webinar here.

We also dig into what this means for Managed Detection and Response (MDR), and why the market is moving from “watch a subset of signals” toward monitoring the full environment, 24 x 7. The catch is that raw volume is not the goal. The goal is a comprehensive data set that enables decision making under pressure, with enough context to act early.

AI is only as good as the context behind it

One theme that kept coming up in our conversation is trust. Corey explains why earlier automation and SOAR efforts struggled. They followed strict rules, but security rarely behaves in strict patterns. When something looked similar but required a different response, teams hesitated to rely on automation. The dynamic rule making that newer AI models provide can help, but only if fueled with the right context.

Corey breaks “context” into practical components: understanding what technologies are deployed, how they are configured, what controls exist, what vulnerabilities are present, and what activity is actually happening across those systems. Without that full picture, teams spend time chasing the wrong risks. He compares it to buying earthquake insurance without knowing where you live. If you are in California, it might make sense. If you are in Florida, hurricane coverage is the real concern. Context tells you which risk actually matters.

Preemptive MDR is the shift CISOs should plan for now

Where the conversation gets especially relevant for 2026 is the move from reactive to preemptive security. To frame the change in plain terms: reactive posture waits for alerts, while leaders want partners who anticipate and identify risks earlier.

Corey describes preemptive MDR as an attack surface discipline. It starts with understanding the full attack surface, spotting where attacks are likely to occur, and identifying the most attractive exposures in the environment. The operational step is what matters: identifying those exposures quickly, prioritizing realistically, and having preset remediation and response plans ready before the moment hits. Corey is direct about constraints, too. No organization can remediate everything all the time, but better planning and efficiency are still possible, and business expectations of security leaders are rising. He also notes that government and regulators are pushing in the same direction, and that Gartner and other analysts are reinforcing the shift toward anticipation rather than after the fact response.

Cloud scale forces MDR to evolve, especially around identity

We also spent time on the cloud, because it continues to reshape how security programs operate.  Most organizations are building more, faster, across more cloud technologies and identities, and AI only accelerates that pace. Corey’s view is that MDR has to mirror that technology reality. At a baseline, teams need to monitor what their cloud providers already offer. He calls out identity as the harder requirement: understanding identity traffic across the environment, separating legitimate from malicious behavior, and tracking roles and responsibilities so investigations do not happen in a vacuum. If an MDR program is not looking across the cloud landscape, it cannot confidently say it is monitoring the right things, especially in the areas where new bugs and misconfigurations show up first.

Transparency becomes a differentiator when AI enters the loop

As AI becomes more present in triage and investigation, Corey argues that transparency will matter even more. He shares that Rapid7 built MDR with the assumption that customers should be able to log in at any time and audit what is happening in their environment. That level of visibility can be uncomfortable, but it becomes more important as AI plays a larger role in how decisions are made. The presence of AI in MDR programs does not reduce the need for trust, but increases it. And that trust is built through transparency and auditability, not assumption.

That also means being able to show where AI is actually making a difference. It is not enough to say it is working. Teams need to see the impact in real terms.

Corey contrasts that with what he sees as the market default: black box approaches that ask customers to trust the output until something goes wrong. His prediction is blunt and practical. As buyers mature, RFPs will demand the ability to inspect how alerts are processed and how investigations are run, because that is what trust looks like at scale.

Watch the full episode below to hear Corey’s take on what is changing, what is still missing, and why the strongest MDR programs in 2026 will be the ones that plan for preemptive action, not just faster reaction.

⠀

Key findings

Our detailed analysis of six months of data from Exploit, XSS, BreachForums, DarkForums, and RAMP reveals the following key findings:

• Access prices and target organization size increased dramatically: The average alleged victim revenue and offering base price have increased significantly compared to the previous year, indicating that IABs are targeting larger, higher-value enterprises and charging premium prices for quality access.

• Primary access vectors haven’t changed: RDP, VPN, and RDWeb remain the top access vectors being offered for sale, which means that remote access infrastructure is still the primary attack surface for initial access sales. 

• High-privilege access is increasingly prioritized: Most common privilege levels being offered by IABs are Domain User (42.9%), Domain Admin (32.1%), and Local Admin (12.5%), with a visible decline in lower-privilege offerings, such as Local User privileges. It seems the market is shifting from volume to high-impact access that enables faster and more efficient malicious operations, such as ransomware and extortion attacks.  

• Certain underground marketplaces have become favored over others: DarkForums (221 threads) and RAMP (208 threads) were the most active forums for initial access sales in H2 2025, accounting together for 81% of the observed threads. At the same time, older, historically dominant forums such as XSS and Exploit saw significant declines in IAB activity. 

• IABs target specific industries: IAB activity is primarily concentrated on sectors offering the highest potential for financial gain or intelligence acquisition: Government, Retail, and Information Technology (IT).

• Focus on government access: The Government sector is the most frequently targeted industry vertical, at 14.2% (Retail and Information Technology follow with 13.1% and 10.8%, respectively). 'Admin panel' access is the most commonly observed type offered for this sector, with DarkForums serving as the principal platform for its sale.

IAB and cybercrime forum landscape in 2026

Just as in 2025, cybercriminal forums continue to serve as the primary marketplaces for the promotion and sale of pirated network access. Platforms such as Exploit, BreachForums, XSS, DarkForums, and RAMP have remained central pillars of the cybercriminal underground through 2025 and into 2026, despite sustained law-enforcement pressure, infrastructure seizures, and repeated cycles of disruption and rebirth. In response to the continued relevance, Rapid7 threat intelligence researchers expanded their monitoring to include all five forums, tracking activity from January through December 2025. The primary objective was to benchmark Initial Access Broker (IAB) activity and adjacent services, including an in-depth analysis of tactics, techniques, and procedures (TTPs), initial access vectors, credential and session pricing, victim geographies, and evolving monetization strategies.

Why cybercrime forums matter in 2026

We selected these five forums for their continued relevance, the concentration of experienced actors, and their distinct functional roles within the cybercriminal ecosystem. Collectively, they represent the full lifecycle of modern cybercrime from initial compromise and access brokerage to data monetization, extortion, and ransomware enablement. Despite repeated takedowns and administrator arrests, the past two years have demonstrated that forum resilience, brand persistence, and rapid reconstitution remain defining characteristics of the underground economy. Monitoring activity across these platforms, particularly from reputable, high-volume IABs and repeat sellers, provides critical insight into shifting attacker priorities, preferred access vectors, and pricing dynamics.

Exploit, XSS, DarkForums, BreachForums, and RAMP: Combined data analysis 

Last year, in The Rapid7 2025 Access Brokers Report, we analyzed the data of three main cybercrime forums, Exploit, XSS, and BreachForums. This year, we have expanded this list to include two additional (and very popular) forums, DarkForums and RAMP.

In fact, the newly analyzed forums were the most active in the past six months in terms of initial access and privileges offered for sale: DarkForums with 221 sale threads, followed by RAMP with 208, then Exploit with 53, Breached with 30, and XSS with 18. This might indicate a certain change in shifts in terms of popularity between the newer forums and the older ones.

⠀

The average alleged revenue of the organizations whose access is being sold in these forums was $3.242 billion, and the average base price for the offerings was $113,275. However, it is important to keep in mind that victim revenue numbers are broker-provided based on their own online research, and as such, they may not necessarily be accurate.

Both numbers manifest a substantial rise compared to last year (average revenue - $2.232 billion, average base price - $2,726), with the average base price of the offerings increasing by approximately 4055% compared to last year. Notably, these numbers are especially affected by DarkForums, with tremendously high values in both counts. They show that IABs have become more resourceful, finding weak spots in larger organizations, and also much greedier in terms of the price of their offerings.

Initial access vectors and privilege types

Analysis of the access types offered for sale revealed 29 distinct types of access. The most frequently advertised access types were RDP (21.2%, 91 offers), VPN (12.8%, 55 offers), and RDWeb (11.2%, 48 offers).

⠀

The most common privilege types were Domain User with 144 instances (42.9%), followed by Domain Admin with 108 (32.1%) and Local Admin with 42 (12.5%).

In many observed cases, VPN and RDWeb access are sold with the Domain User privilege, while RDP is sold with either Domain User or Domain Admin.

If we compare the numbers of the top 5 access types offered for sale to last year’s data, we can see that RDP access has become more prevalent than VPN, although both access types remain the leading two categories. In addition, it seems that RDweb is much more popular among the sellers.

⠀

As for the privilege types, the clear dominance of the Domain User privilege offered for sale has declined, though it remains the most common privilege type sold by IABs. In addition, the newer dataset lacks any mentions of the Local User privilege. The data indicates a decline in the previously dominant Domain User access offering. Despite this decrease, Domain User access remains the most frequently sold privilege level among Initial Access Brokers (IABs). Notably, the updated dataset contains no instances of Local User privilege sales.

This shift likely reflects evolving IAB monetization strategies and changing buyer demand. While Domain User access remains valuable for its broad network reach, its reduced dominance may signal heightened market competition, stronger defensive controls, or strategic diversification into alternative access types. The complete absence of Local User privileges suggests diminishing operational relevance and limited resale value, as threat actors increasingly prioritize access that facilitates lateral movement, privilege escalation, and rapid operational impact.

⠀

Additionally, in RAMP, we observed an exploit targeting a vulnerability in the Oracle E-Business Suite (CVE-2025-61882) being offered for sale.

⠀

⠀

CVE-2025-61882 is a critical vulnerability in Oracle E-Business Suite (versions 12.2.3–12.2.14). This flaw allows unauthenticated attackers to execute arbitrary code via HTTP, resulting in complete system compromise.

The vulnerability has been exploited as a zero-day by the Cl0p criminal organization to exfiltrate financial and human resources data for subsequent extortion attempts, as documented in the Rapid7 blog.

Demographic information

A comprehensive analysis of the underground market for illicit network access points reveals that most available listings concern networks in the United States, totaling 155 unique listings. 

This substantial figure constitutes a significant 30.9% of the total global data on illicit network access available for purchase. The dominance of the U.S. in this domain suggests a confluence of factors, including the sheer size and connectivity of its network infrastructure, the high value associated with compromised U.S. enterprise and government networks, and the relative wealth of potential buyers seeking access to these environments. The visibility of U.S.-based access points on darknet marketplaces underscores a considerable vulnerability and highlights the attractiveness of U.S. targets to cybercriminal syndicates seeking initial access for subsequent malicious activities such as data exfiltration, ransomware deployment, or espionage.

⠀

The top 10 targeted countries list is very similar to the one from last year, which also placed the United States at the top, with a large margin from the following countries (the United Kingdom, India, and Brazil).

In addition, an analysis of the offerings indicates a pronounced concentration on particular sectors. The government sector is the most frequently targeted category, accounting for 14.2% of the observed offerings, likely due to the substantial value of sensitive data held. The retail industry closely follows at 13.1%, attracting IABs due to the presence of payment card information (PCI) and personally identifiable information (PII). The Information Technology (IT) sector is the third most frequent target, at 10.8%, valued for its potential as a supply chain vector to compromise a wide range of clients.

This strategic focus on Government, Retail, and IT underscores the IAB community's prioritization of targets that promise the greatest financial return, intelligence acquisition, or potential for systemic disruption.

⠀

Unlike the top 10 countries list, the top 10 targeted sectors list is very different from last year’s, which was dominated by the Financial Services and IT sectors, with few network access offerings from organizations in the Government and Retail sectors. This is likely due to the inclusion of DarkForums in this year’s analysis, which usually contain many sellers offering access to government networks.

Individual analysis of Exploit, XSS, DarkForums, BreachForums, and RAMP

The following is a detailed, individual analysis of the five forums, covering their history, operations, and key trends from the latter half of 2025. This includes an examination of common illicit listings, typical base price ranges, and frequently targeted regions.

Exploit

Exploit has continued to function as one of the most technically rigorous Russian-language cybercrime forums. Historically focused on exploits, malware development, and high-end IAB offerings, Exploit has maintained a comparatively stable operational posture over the past two years. While selectively restricting access and tightening vetting following multiple international law enforcement takedowns of peer forums, Exploit has benefited from its long-standing reputation system and senior moderator structure. Between 2024 and 2026, it increasingly served as a venue for enterprise network access, VPN, and EDR-bypassed footholds, and post-exploitation tooling, rather than commodity credential sales.

Unlike last year’s offerings that focused on RDP access, the H2 2025 data shows that Exploit’s IABs are more focused on RDweb. The shift from RDP access to RDWeb access in H2 2025 is likely due to improved defenses against direct exposure to the RDP protocol. Faced with reduced capabilities to secure or remove RDP access points exposed to the internet, attackers are adapting by targeting RDWeb portals, which are often vulnerable and sometimes less well-protected. RDWeb offers reliable access to enterprise environments, making it an attractive alternative for initial access brokers. The United States remains the most targeted country, accounting for approximately 40% of cases in which the organization’s location is specified.

⠀

Interestingly, while the average alleged revenue of the targeted organizations dropped from approximately $314 million to only $58 million, the base price of the offerings has gone 6 times higher than last year.

BreachForums (AKA Breached)

BreachForums has experienced the most visible volatility. Following multiple seizures and arrests in 2023–2024, the forum underwent several reboots under new administrators, each attempting to inherit the brand equity of the original platform. By 2025, BreachForums had largely reestablished itself as a data-leak-centric marketplace, with less emphasis on technical exploitation and a greater focus on breached databases, stealer logs, and extortion-related disclosure tactics. Trust erosion from repeated compromises, however, pushed higher-tier IABs and ransomware affiliates toward more closed or Russian-language platforms, reducing BreachForums’ role in elite access brokerage by 2026.

The precarious status of the Breached forum, as it is now called, is reflected by the number of IAB threads found this year (around 52% less than in 2024). This is likely due to the disappearance of very dominant players in the IAB community, such as IntelBroker (real name: Kai West), who was apprehended by law enforcement and charged in the U.S. with his crimes. Accordingly, the variety of access types was much more limited, dominated by remote code execution (RCE) and Shell access. However, unlike last year, which included only Domain Admin, this year we noticed additional privilege types offered: Domain User and Local Admin.   

⠀

Just like in the other examined forums, the United States is the most targeted country (17.4%) in Breached, but by a substantially smaller percentage compared to last year.

As for the pricing, we see an opposite trend compared to Exploit - while the average alleged revenue of the targeted organizations has slightly increased in 2025, the base price of the offerings in Breached was cut in half.

XSS (formerly DaMaGeLaB)

XSS has retained its status as a premier Russian-language forum for initial access sales, ransomware partnerships, and credentialed access to corporate environments. Following intermittent downtime and administrator turnover in 2024, XSS emerged in 2025 with reinforced operational security practices and stricter membership controls. Over the past two years, XSS has increasingly served as a coordination hub for post-access collaboration, including handoffs between IABs, ransomware operators, and data theft specialists. Pricing trends observed on XSS indicate a shift toward higher-value, lower-volume access, particularly in Western enterprise environments.

Compared to last year's assessment, this forum showed the most significant shift. It went from being the most dominant forum for IAB threads to the lowest among the five forums we examined. In H2 of 2025, we only located around 20 threads (compared to almost 200 in 2024). This small number of threads makes XSS stats so statistically negligible as to be unanalyzable. This decline is likely due to many IABs shifting to newer, “shinier” cybercrime forums, such as DarkForums and RAMP. 

DarkForums

DarkForums rose to prominence as an English-language alternative following repeated disruptions to BreachForums. Between 2024 and 2026, DarkForums positioned itself as a hybrid marketplace, blending breach data sales, low- to mid-tier IAB offerings, and fraud services. While it lacks the technical depth of Exploit or XSS, DarkForums has become a key on-ramp for emerging actors, especially those operating stealer malware or reselling access obtained using phishing and MFA fatigue attacks. Its relatively open registration model has resulted in higher signal-to-noise ratios, but it remains valuable for tracking early-stage monetization trends.

DarkForums is one of the two new forums that were included in this year’s analysis, and the most dominant in terms of IAB threads. It had a somewhat unique access type, leading the board, Fortinet, followed by SSH, RDP, and Root access. The Fortinet access points were predominantly sold by a very active DarkForums user, BigBro. Interestingly, we also found another user, Big-Bro, active on RAMP, who is likely the same user, although selling different types of access points.

⠀

Similar to the other forums, the most targeted country on DarkForums was the United States (25.8%); however, unlike the others, many of the network access offerings were from organizations in the Government and Retail sectors. 

As for the pricing, DarkForums had the highest average of alleged targeted organization revenue and offering base price by a very large margin compared to the rest. 

RAMP (Russian Anonymous Marketplace)

RAMP has continued to operate as a high-trust, invite-only ecosystem following its resurgence after earlier disruptions by law enforcement. By 2025–2026, RAMP solidified its role as a convergence point for ransomware affiliates, IABs, and cash-out services, rather than a general discussion forum. RAMP listings observed during this period emphasized full domain access, long-term persistence, and revenue-sharing models, reflecting a mature, partnership-driven cybercrime economy. Its closed nature limits visibility, but the activity that does surface suggests alignment with the most operationally sophisticated threat actors.

RAMP was another newly examined forum and the second-highest in terms of IAB threads. The most dominant type of access being sold by RAMP’s IABs was RDP, followed by VPN and Citrix by a large margin. The most common privilege types for sale were Domain User (56.4%) and Domain Admin (33.9%). Notably, most of the threads that were analyzed for this forum (78.8%) belonged to only two users, Big-Bro (mentioned earlier) and an allegedly Albanian user, lacrim.   

⠀

In RAMP, the United States continued to lead the list of targeted countries (36.5%). The average alleged targeted organization revenue was approximately $440 million, and the average base price was almost $6400. 

Threat actors active across multiple forums

This research revealed that a subset of threat actors maintains an active presence across multiple forums, with the greatest overlap observed between Breached and DarkForums. This overlap is understandable, since DarkForums was intentionally designed as a "spiritual successor" and a like-for-like replacement for Breached following the latter's frequent law-enforcement disruptions. Consequently, the two platforms share a nearly identical visual and structural layout, both utilizing the MyBB forum software to create a familiar environment for users.

Recommendations

No security strategy can remain static. Policy frameworks and compliance controls alone are insufficient. Continuous monitoring of real-world access behavior is essential. Anomalous logins, unexpected privilege escalations, access outside normal business hours, or activity from unfamiliar locations should be treated as early indicators of compromise.

Proactive threat intelligence further enables defenders to anticipate which access methods are most likely to be targeted. An effective defense requires making stolen access difficult to exploit. Enforcing least-privilege principles, tightly controlling administrative rights, hardening remote access services with MFA, and accelerating intrusion detection all materially limit an attacker’s ability to escalate and persist. While breaches may still occur, rapid identification and containment can prevent them from becoming full-scale incidents. Organizations that evolve their defenses in step with access brokers can erode the attackers’ advantage, increasing the cost and reducing the effectiveness of cybercrime.

Conclusion

The comparison between 2024 and 2025 highlights how initial access brokers continue to adapt to increasingly robust defensive measures. As organizations strengthen their security postures, attackers refine the types of access they steal and monetize to maintain effectiveness. In 2025, high-privilege credentials, such as domain or local administrator accounts, will command greater value because they enable rapid lateral movement and immediate operational impact, leaving defenders little time to detect and respond. Lower-privilege access is steadily losing value, signaling a clear shift from volume-driven access sales to a focus on quality and impact. Access vectors are evolving in parallel. As VPN infrastructure becomes more hardened and closely monitored, attackers are pivoting to RDP, RDWeb, and SSH services that are operationally critical, widely exposed, and often subject to less rigorous scrutiny. This shift reflects a pragmatic path-of-least-resistance strategy rather than any decline in attacker sophistication.

That shift sits at the center of this year’s Rapid7 Global Cybersecurity Summit, taking place on May 12-13. As part of the Continuous Threat Defense pillar, the summit will explore red teaming not as a standalone exercise, but as a core input into how modern security operations function day to day.

From validation to continuous feedback

In sessions like Using Red Teaming to Power Preemptive MDR, the focus moves away from point-in-time testing and toward becoming part of a continuous feedback loop. Detection logic is tested against real attacker techniques and gaps are exposed before they become incidents. Response workflows are refined in conditions that reflect how attacks actually unfold, rather than how they are expected to behave.

This represents a clear shift from traditional engagements. Instead of producing a static report, red teaming feeds directly into detection engineering and MDR operations. Many teams still rely on assumptions about coverage, but those assumptions often break down under pressure. Continuous validation helps close that gap.

Aligning red teaming with how attacks really happen

Modern attacks rarely follow a clean path. They move across identity, cloud, and endpoint, taking advantage of timing, visibility gaps, and delayed decisions. Red teaming has to reflect that reality.

At the summit, the conversation connects adversary behavior with how detection and response teams operate in practice. This includes how signals are correlated across environments, how escalation decisions are made, and where teams lose time during an investigation. The goal is not to simulate attacks for the sake of it, but to understand how those attacks would be detected, prioritized, and contained in a real environment.

Why red teaming matters now

The move toward preemptive security operations depends on confidence. Teams need to know that what they have built will hold up when it matters. Red teaming supports that by grounding security programs in evidence. It shows what works, highlights what does not, and gives teams an opportunity to improve before a live incident forces change.

This becomes even more important as organizations adopt MDR models, integrate AI into workflows, and operate across increasingly complex environments. Without continuous validation, complexity creates blind spots that are difficult to see until it is too late.

Rapid7's Cybersecurity Summit: A preview of what’s to come

Red teaming is one part of a broader shift happening across the summit. Sessions across detection, response, AI, and exposure management all point in the same direction: Security operations must move earlier in the attack lifecycle, reduce noise, improve prioritization, and support faster decisions with better context.

More sessions and speakers will be announced in the coming weeks, building out how this shift is being applied in practice. If you are responsible for detection, response, or validation of your security program, this is a conversation worth being part of.

Join us May 12–13 and see how teams are using red teaming to strengthen modern security operations.

Register now.

Better NTLM Relaying Functionality

This week’s release brings an improvement to the SMB NTLM relay server. In the past, it’s support has been expanded with modules for relaying to HTTP (ESC8), MSSQL and LDAP while still receiving connections over the humble SMB service. Prior to this release, clients required a key behavior in how they handled SMB’s STATUS_NETWORK_SESSION_EXPIRED error code, in order to relay a single authentication attempt to multiple targets. Most clients other than Window’s “net use” do not handle these errors and were thus incompatible with Metasploit SMB NTLM relaying capabilities. Now, when a single target is specified, Metasploit alters its relaying strategy to forward the Net-NTLM messages immediately, making it compatible with a broader range of clients including Linux’s smbclient. In addition, the client in RubySMB was updated to mimic the behaviour of “net use” allowing authentication attempts from RubySMB to be relayed to multiple targets successfully.

New module content (3)

ESC/POS Printer Command Injector

Author: FutileSkills

Type: Auxiliary

Pull request: #20478 contributed by futileskills

Path: admin/printer/escpos_tcp_command_injector

Description: Adds a new auxiliary module that exploits CVE-2026-23767, an unauthenticated ESC/POS command vulnerability in networked Epson-compatible printers. The vulnerability allows an attacker to send crafted commands over the network to inject custom ESC/POS print commands, which are used in various receipt printers.

Eclipse Che machine-exec Unauthenticated RCE

Authors: Greg Durys gregdurys.security@proton.me and Richard Leach

Type: Exploit

Pull request: #20835 contributed by GregDurys

Path: linux/http/eclipse_che_machine_exec_rce

AttackerKB reference: CVE-2025-12548

Description: This adds a module for CVE-2025-12548, an unauthenticated RCE in the Eclipse Che machine-exec service. The vulnerability allows attackers to connect over WebSocket on port 3333 and execute commands via JSON-RPC without authentication. This affects Red Hat OpenShift DevSpaces environments.

Barracuda ESG TAR Filename Command Injection

Authors: Curt Hyvarinen, Mandiant, and cfielding-r7

Type: Exploit

Pull request: #21033 contributed by Alpenlol

Path: linux/smtp/barracuda_esg_tarfile_rce AttackerKB reference: CVE-2023-2868

Description: Adds exploit module for CVE-2023-2868, a command injection vulnerability in Barracuda Email Security Gateway (ESG) appliances. Filenames in TAR attachments are passed to shell commands without sanitization, allowing RCE via backtick injection.

Enhancements and features (1)

• #21049 from h00die - This updates post modules to use an API that will expand multiple environment variables when set within the WritableDir option.

Bugs fixed (5)

• #20967 from jheysel-r7 - This fix an issue that prevents successful authentication relay from Ruby SMB Client and smbclient. These clients are now compatible with Msf::Exploit::Remote::SMB::RelayServer.
• #21148 from adfoster-r7 - Fixes a bug where setting VERBOSE logging as false globally would still cause verbose logging to occur.
• #21169 from SaiSakthidar - This fixes a bug that was preventing Mach-O binaries from being identified due to a Ruby string encoding compatibility problem.
• #21173 from msutovsky-r7 - Fixes a crash when attempting to generate a vbs payload with msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.1.1 LPORT=44 -f vbs.
• #21174 from adfoster-r7 - Fixes a bug when parsing msfconsole's -x flag when additional semicolons are present that are not meant to separate commands. i.e. msfconsole -x 'set option_name "a;b"'.

Documentation

You can find the latest Metasploit documentation on our docsite at docs.metasploit.com.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:

• Pull Requests 6.4.123...6.4.124
• Full diff 6.4.123...6.4.124

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest. To install fresh without using git, you can use the open-source-only Nightly Installers or the commercial edition Metasploit Pro

In a recent report, Gartner® highlighted a projection: 

"By 2028, organizations that prioritize exposures using threat intelligence, asset context, exploitability modeling and security control validation will reduce breach likelihood by at least 70% compared to peers relying primarily on CVSS-based vulnerability prioritization." [1]

This affirms what many seasoned practitioners have suspected for years: there’s an abundance of vulnerability findings, but a lack of actionable context.

Static scores. Reactive security.

Most vulnerability management programs evolved during a time when the attack surface was relatively static, adversary tooling was rudimentary, and remediation capacity generally exceeded the volume of new disclosures. Today, enterprises are confronted with vulnerabilities scattered across complex cloud architectures, SaaS applications, and intricate supply chains.

In this modern threat landscape, CVSS alone is insufficient because it measures theoretical severity, does not factor in whether an attacker is actually using the vulnerability in the wild, or consider the business value of any affected assets. According to Gartner®, fewer than 10% of vulnerabilities are exploited, yet most are treated as urgent [1]. This all leads to prioritization paralysis, where security teams spend countless hours patching vulnerabilities that pose low material risk to the business. The legacy approach rewards what is auditable rather than what is genuinely impactful.

The path toward smarter prioritization

To break free from endless patching and ineffective risk reduction practices, security professionals are shifting toward a context-driven model. As Gartner notes, strong exposure prioritization requires integrating four critical elements: threat intelligence, asset context, data science, and security control validation. Organizations are approaching these elements in a few practical ways:

Threat intelligence to establish relevance

Instead of just asking how severe a vulnerability is, modern exposure management asks whether an exposure is relevant to a threat actor who is capable of exploiting it right now. By embedding threat intelligence into each vulnerability finding, teams shift the focus from theoretical to risk active exploitation. It introduces the adversary's perspective by identifying known exploited vulnerabilities, public or private exploit availability, and targeted campaigns. By filtering out exposures with no evidence of attacker interest, organizations can instantly collapse large vulnerability backlogs and focus only on relevant threats.

Asset context and business criticality to define impact

Not all assets are created equal. A critical vulnerability on an isolated, internal test server is vastly different from the same vulnerability on a public-facing cloud workload processing customer sensitive data. Asset context enriches exposure data with crucial business information: what the asset is, its external accessibility, and its relationship to core business functions. Without this context, security teams waste disproportionate effort on low-impact systems, treating every critical alert as an equal emergency.

Exploitability modeling for predicting breach likelihood

Security analysts often struggle to assess exploitability given the overwhelming volume of vulnerabilities. By using predictive models like the Exploit Prediction Scoring System (EPSS), organizations can analyze large datasets of historical exploitation to identify latent risks. Exposure assessment platforms should display this data alongside each exposure finding to make it easier to predict the vulnerabilities most likely to become attacks.

Security control validation

An exposure that appears highly exploitable in theory might be neutralized by existing defenses. By integrating security and policy controls, you can evaluate exposures in the context of endpoint protection and identity management. This passive validation confirms whether an attacker can realistically exploit the exposure in your specific environment.

Unified exposure management

Individually, each element highlighted above provides incremental value, but when integrated, they fundamentally transform how prioritization decisions are made. This integrated model ensures that remediation efforts are mobilized only after priorities have been validated in the context of the business and the current threat landscape. It transitions vulnerability management from a purely technical, tool-centric exercise into a strategic, process-driven risk decision.

Security leaders must measure success not by the sheer number of vulnerabilities closed, but by the demonstrable reduction of exploitable exposures and the alignment of remediation efforts with actual attacker behavior. Operationalizing these four elements requires a unified platform that eliminates the silos between vulnerability management, cloud security, and threat intelligence. You cannot manually stitch together disconnected spreadsheets and hope to outpace modern adversaries. This is where forward-thinking organizations are leaning on comprehensive, end-to-end solutions like Rapid7 Exposure Command that seamlessly aggregate visibility across on-premises and dynamic cloud environments. With deep, native integration of Rapid7 Cloud Security capabilities, teams can instantly map asset criticality and external accessibility within complex, ephemeral cloud architectures. Furthermore, by infusing world-class threat intelligence and active exploit data directly into exposure findings, Rapid7 enables security teams to cut through the noise, validate security controls, and pinpoint the exact exposures that matter most—all with minimal friction.

[1] Gartner, Prioritize What Attackers Will Exploit: 4 Elements of Strong Exposure Prioritization, Jonathan Nunez, 5 March 2026.

The strategic positioning of covert access within the world’s telecommunication networks

A months-long investigation by Rapid7 Labs has uncovered evidence of an advanced China-nexus threat actor, Red Menshen, placing some of the stealthiest digital sleeper cells the team has ever seen in telecommunications networks. The goal of these campaigns is to carry out high-level espionage, including against government networks.

Telecommunications networks are the central nervous system of the digital world. They carry government communications, coordinate critical industries, and underpin the digital identities of billions of people. When these networks are compromised, the consequences extend far beyond a single provider or region. That level of access is, and should be, a national concern as it compromises not just one company or organization, but the communications of entire populations.

Over the past decade, telecom intrusions have been reported across multiple countries. In several cases, state-backed actors accessed call detail records, monitored sensitive communications, and exploited trusted interconnections between operators. While these incidents often appear isolated, a broader pattern is emerging.

Why telecom networks are strategic espionage targets

Telecommunications infrastructure provides a uniquely valuable strategic positioning.

Modern telecom networks are layered ecosystems composed of routing systems, subscriber management platforms, authentication services, billing systems, roaming databases, and lawful intercept capabilities. These systems rely on specialized signaling protocols such as SS7, Diameter, and SCTP to coordinate identity, mobility, and connectivity across national and international boundaries.

Persistent access within these environments enables far more than a conventional data breach. An adversary positioned inside the telecom core may gain visibility into subscriber identifiers, signaling flows, authentication exchanges, mobility events, and communications metadata. In the most concerning scenarios, this level of access could support long-term intelligence collection, large-scale subscriber tracking, and monitoring of sensitive communications involving high-value geopolitical targets.

Telecommunications networks sit at the intersection of identity, mobility, and global connectivity. Compromise at this layer carries national and international implications.

A structured campaign, not isolated incidents

What looks like discrete breaches increasingly resembles a repeatable campaign model designed to establish persistent access inside telecommunications infrastructure.

Our investigation uncovered a long-term and ongoing operation attributed to a China-nexus threat actor. Rather than conducting short-term intrusion activity, the operators appear focused on long-term positioning by embedding stealthy access mechanisms deep inside telecom and critical environments and maintaining them for extended periods.

In effect, attackers are placing sleeper cells inside the telecom backbone: dormant footholds positioned well in advance of operational use.

Across investigations and public reporting, we observe recurring elements: kernel-level implants, passive backdoors, credential-harvesting utilities, and cross-platform command frameworks. Together, these components form a persistent access layer designed not simply to breach networks, but to inhabit them.

How BPFdoor enables covert, deep-seated persistence

At the center of this activity is BPFdoor, a stealth Linux backdoor engineered to operate within the operating system kernel.

Unlike conventional malware, BPFdoor does not expose listening ports or maintain visible command-and-control channels. Instead, it abuses Berkeley Packet Filter (BPF) functionality to inspect network traffic directly inside the kernel, activating only when it receives a specifically- crafted trigger packet. There is no persistent listener or obvious beaconing. The result is a hidden trapdoor embedded within the operating system itself.

This approach represents a shift in stealth tradecraft. By positioning below many traditional visibility layers, the implant significantly complicates detection, even when defenders know what to look for.

Our research indicates BPFdoor is not an isolated tool, but part of a broader intrusion model targeting telecom environments at scale.

How attackers gain initial access to telecom environments

These findings reflect a broader evolution in adversary tradecraft. Attackers are embedding implants deeper into the computing stack — targeting operating system kernels and infrastructure platforms rather than relying solely on user-space malware.

Telecom environments — combining bare-metal systems, virtualization layers, high-performance appliances, and containerized 4G/5G core components — provide ideal terrain for low-noise, long-term persistence. By blending into legitimate hardware services and container runtimes, implants can evade traditional endpoint monitoring and remain undetected for extended periods.

For defenders, the implications are significant. Many organizations lack visibility into kernel-level operations, raw packet-filtering behavior, and anomalous high-port network activity on Linux systems. Addressing this threat requires expanding defensive visibility beyond the traditional perimeter to include deeper inspection of operating system behavior and infrastructure layers.

Sharing intelligence responsibly

Our investigation to identify potential victims is ongoing and, where potential compromise has been discovered, we have notified affected parties through relevant authorities or direct communication with our customers.

As part of our responsible research process, we have collaborated with government partners and national CERTs to share findings and indicators associated with this activity. When our analysis identified infrastructure that may have been impacted, we proactively notified the relevant organizations and provided detection guidance to assist with investigation and response while the research was still underway.

Rapid7 Intelligence Hub customers have access to the full technical details and indicators of compromise within the platform, including Surricata rules. Those rules are also available through AWS Marketplace, where we offer our curated AWS firewall rule sets. 

Technical analysis

The sections that follow examine how modern telecommunications networks are structured, how initial access is established, and how BPFdoor and related tooling enable infrastructure-level persistence inside the telecom backbone.

Modern telecom network structure

To understand why telecom environments are such attractive strategic targets, it helps to visualize their layered architecture (Figure 2). At the outer edge sit customer-facing services and access infrastructure: mobile base stations (RAN), fiber aggregation routers, broadband gateways, DNS services, SMS-controllers, roaming gateways, security appliances like firewalls, proxies, VPNs, and internet peering points. These edge systems connect into the operator’s IP core and transport backbone, where high-capacity routers and switches move massive volumes of voice, data, and signaling traffic across regions and international borders.

⠀

Deeper inside lies the control plane, the heart of the telecom network, built around subscriber management systems such as HLR/HSS or UDM, authentication platforms (AuC), policy control functions, billing systems, lawful intercept platforms, and roaming databases. These systems communicate using specialized telecom signaling protocols such as SS7, Diameter, and increasingly SCTP-based signaling for LTE and 5G core components. At the foundation, much of this infrastructure ultimately runs on hardened, but often standard, Linux or BSD-based bare-metal servers, virtualization stacks, and high-performance network appliances. When an adversary implants a persistent backdoor at the kernel level within these environments, they are not simply compromising a server, they are positioning themselves adjacent to subscriber data, signaling flows, and the mechanisms that authenticate and route national and international communications.

Initial access

Telecom intrusions rarely begin deep inside the core. Instead, attackers focus on exposed edge services and internet-facing infrastructure. Techniques such as exploitation of public-facing applications (T1190) and abuse of valid accounts (T1078) are repeatedly observed. Devices commonly targeted include: Ivanti Connect Secure VPN appliances, Cisco IOS and JunOS network devices, Fortinet firewalls, VMware ESXi hosts, Palo Alto appliances, and even web-facing platforms like Apache Struts. These systems sit at the boundary between external traffic and internal telecom environments, making them high-value entry points. Once compromised, they provide authenticated pathways into the provider’s network, often without triggering traditional endpoint detection mechanisms.

Let’s highlight some of the tools we observed during initial access and attempt to get more credentials for lateral movement.

CrossC2

Once initial access is secured, the operators frequently deploy Linux-compatible beacon frameworks such as CrossC2. This Cobalt Strike-derived loader enables beacon functionality on Linux hosts and has been repeatedly observed in PRC-aligned intrusion campaigns. It provides the same post-exploitation capabilities traditionally seen in Windows environments, command execution, pivoting, staging, but tailored for Linux-heavy telecom infrastructure. CrossC2 allows operators to blend into server environments that form the backbone of telecom operations, particularly edge devices and core routing systems. Just as with the Cross C2 configuration, investing reveals the C2 server. For example:

⠀

TinyShell

For long-term persistence, actors often rely on TinyShell, an open-source passive backdoor framework repurposed and customized by multiple APT groups. TinyShell is frequently observed on boundary devices such as firewalls, VPN appliances, and virtualization hosts. Compiled for Linux and FreeBSD, it is designed with stealth in mind: minimal network footprint, passive communication model, and reliable remote command execution capabilities. 

Keyloggers and bruteforcers

After foothold establishment, attackers focus on persistence and lateral movement. Tooling such as Sliver, CrossC2, and TinyShell are complemented by SSH brute forcers and custom ELF-based keyloggers. In some cases, operators deploy brute-force utilities containing pre-populated credential lists tailored for telecom environments, even including specific usernames like “imsi,” referencing subscriber identity systems. This level of contextual awareness indicates reconnaissance and targeting aligned with telecom operational terminology. The goal is clear: move laterally, harvest credentials, and reach control-plane systems where subscriber data and signaling infrastructure reside.

BPFdoor

BPFdoor first came to broader public attention around 2021, when researchers uncovered a stealthy Linux backdoor used in long-running espionage campaigns targeting telecommunications and government networks. The BPFDoor source code reportedly leaked online in 2022, making the previously specialized Linux backdoor more accessible to other threat actors. Normally, BPF is used by tools like tcpdump or libpcap to capture specific network traffic, such as filtering for TCP port 443. It operates partly in kernel space, meaning it processes packets before they reach user-space applications.

BPFdoor abuses this capability. Rather than binding to a visible listening port, the implant installs a custom BPF filter inside the kernel that inspects incoming packets for a specific pattern, a predefined sequence of bytes often referred to as a “magic packet” or “magic byte.” If the pattern does not match, nothing happens. The traffic continues as normal. No open port or obvious process-accepting connections. But when the correct sequence is delivered to the correct destination port, the behavior changes instantly.

⠀

Imagine retrieving a parcel from a secure pickup locker. The locker sits quietly in public view, no alarms, no obvious signs of activity. It only opens when the correct code is entered.

BPFdoor behaves the same way.

The implant remains dormant inside the Linux kernel, passively inspecting network traffic. It does not advertise itself. It does not respond to scans. But when an operator sends the correct “code”, the specific magic byte sequence embedded in a crafted packet, the BPF filter recognizes the pattern and triggers the next stage.

Instead of opening a physical door, it spawns a bind shell or reverse shell. Importantly, this activation can occur without a traditional listening service ever being visible in netstat or ss. To a defender, the system appears clean; there is no persistent open port to detect.

Before we showcase this, something important to note is that BPFdoor operations consist of two distinct components: the implant and the controller. 

The implant is the passive backdoor deployed on the compromised Linux system, where it installs a malicious BPF filter and silently inspects incoming traffic for a predefined “magic” packet. It does not continuously beacon or expose a listening port, making it extremely stealthy. 

The controller, on the other hand, is operated by the attacker and is responsible for crafting and sending the specially formatted packets that activate the backdoor and establish a remote shell. While it can be run from attacker-controlled infrastructure such as compromised routers or external systems, the controller is also designed to operate within the victim’s environment itself. In this mode it can masquerade as legitimate system processes and trigger additional implants across internal hosts by sending activation packets or by opening a local listener to receive shell connections, effectively enabling controlled lateral movement between compromised systems. In essence, the implant acts as the hidden lock embedded within the system, while the controller functions as the key that can activate it. A deeper technical analysis of the controller architecture and its role in lateral movement will be covered in a forthcoming technical blog.

To demonstrate how these first backdoors work, we created the video below, in which we are running a BPFdoor made visible. Next, we send the magic packet and instructions to the IP address and port we are listening on. Then the BPFdoor opens up the “safe” and creates the tunnel. In the final part of the demo, we see that on our Netcat listener, we have a remote shell and can query the system.

⠀

Next, we will highlight how we started to hunt for BPFdoor.

Hunting for BPFdoor variants

Since we were aware of several BPFdoor attacks and samples circulating, we started hunting for more samples and developed internal tools to extract, compare, and detect early indicators of new features. One threat hunting angle Rapid7 Labs really loves to focus on is code similarity of samples. Code similarity of malware samples can result in clusters of samples with similar activity, but most importantly, also demonstrate outliers that are potential candidates for research since they do not share commodity with the other samples.

The BPFdoor samples we collected and hunted for are all Executable and Linkable Format (ELF) files, but we are aware of samples compiled for running on Solaris. ELF is the standard binary file format for executables, object code, shared libraries, and core dumps on Linux and Unix-like operating systems. For the ELF files, we wrote a custom tool for clustering ELF/BPFdoor. By extracting .text section byte code blocks, generating MinHash signatures, and completing a few other steps, it will then compute exact Jaccard similarity and export the resulting similarity graph for visual cluster analysis.

⠀

In our visualization, we clearly observe certain clusters of BPFdoor, but also outliers and smaller clusters that were up for investigation. The thicker the line, the more similar the code is to the samples it is attached to. By creating a feature comparison/extraction tool, we started to discover interesting features in the samples, which led us to a new controller discovery and security bypass feature. For example, we discovered a variant we dubbed “F” that uses a 26 BPF instruction filter with new magic packets.

Although it was previously reported that some samples support the Stream Control Transmission Protocol (SCTP), there is a tendency to read over it and not put it into the right context of what the consequences are. SCTP is not typical enterprise traffic; it underpins Public Switch Telephone Network (PSTN) signaling and real-time communication between core 4G and 5G network elements. By configuring BPF filters to inspect SCTP traffic directly, operators are no longer just maintaining server access, they are embedding themselves into the signaling plane of the telecom network. This is a fundamentally different level of positioning. Instead of sitting at the IT perimeter, the implant resides adjacent to the mechanisms that route calls, authenticate devices, and manage subscriber mobility.

⠀

Access to SCTP traffic opens powerful intelligence collection opportunities. In legacy and transitional environments, improperly secured signaling can expose SMS message contents, IMSI identifiers, and source/destination metadata. By observing or manipulating traffic over SCTP commands such as ProvideSubscriberLocation or UpdateLocation, an adversary can track a device’s real-world movement. In 5G environments, traffic over SCTP carries registration requests and Subscription Concealed Identifiers (SUCI), allowing identity probing at scale. At this point, the compromise is no longer about server persistence; it becomes population-level visibility into subscriber behavior and location. Translated, you could track individuals of interest. 

Interesting observations

The bare-metal to telecom equipment link

During the code investigations, we discovered that some BPFdoor samples are using code to mimic the bare-metal infrastructure, particularly enterprise-grade hardware platforms commonly deployed in telecom environments. By masquerading as legitimate system services that run only on bare metal, the implant blends into operational noise. This is especially relevant in environments leveraging HPE ProLiant and similar high-performance compute systems used for 5G core and edge deployments. 

⠀

In the above screenshot of one of the BPFdoor samples, we observed the processname “hpaslimited”.

By mimicking legitimate service names and process behavior of HPE ProLiant servers, attackers ensure the implant appears native to the hardware environment, a tactic that significantly complicates detection. Several of these service names have been observed in BPFdoor samples, but this name stood out. The hpasmlited.pid creates process threads, and mimics daemon-style behavior consistent with hardware monitoring services. The real hpasmlited process belongs to HPE’s Agentless Management Service, which runs on bare-metal ProLiant servers to expose hardware telemetry and system health data.

By adopting this name and writing a corresponding PID file, the malware blends into expected operational noise on telecom-grade ProLiant infrastructure. Of course this is not accidental naming, it demonstrates environment awareness and targeting intent. The operators appear to know they are running on physical HPE hardware commonly deployed in 4G/5G core and edge systems. By impersonating a trusted hardware management daemon that administrators expect to see, the implant reduces suspicion during forensic review while embedding itself directly into the physical backbone layer of telecom infrastructure. This tactic reflects a broader strategy: hide not just in Linux, but in the hardware identity of the telecom environment itself.

Mimicking containers

A second strategy involves spoofing core containerization components. Critical 5G core components such as the Access and Mobility Management Function (AMF), Session Management Function (SMF), and User Data Management (UDM) run as cloud native network functions inside Kubernetes pods. The following code excerpt demonstrates that the implant is aware of it.

⠀

Docker Daemon (/usr/bin/dockerd) and containerd: The malware is executed with root privileges and adopts the exact command-line arguments of a legitimate Docker daemon (e.g., -H fd:// --containerd=/run/containerd/containerd.sock).

Recap for a moment

Up to this point, what we’ve described in our technical analysis has, more or less, been publicly available information; however, these pieces have not been assembled in a way that provides the context Rapid7 Labs has discovered through its in-depth investigation. Therefore, before we deep dive into some of the new technical findings that completes the picture of what is truly happening here, let’s pause for a moment to sync up on what we’ve just described. 

So far, our findings illustrate that BPFdoor is far more than a stealthy Linux backdoor. The kernel-level packet filtering, passive activation through magic packets, masquerading as legitimate hardware management services, awareness of container runtimes, and the ability to monitor telecom-native protocols such as SCTP, point to a tool designed for deep infrastructure positioning. Rather than targeting individual servers, the operators appear to focus on the underlying platforms that power modern telecommunications networks: bare-metal systems running telecom workloads, cloud-native Kubernetes environments hosting Containerized Network Functions, and the signaling protocols that coordinate subscriber identity, mobility, and communication flows. In this context, BPFdoor functions as an access layer embedded within the telecom backbone, providing long-term, low-noise visibility into critical network operations.

What Rapid7 found in newer BPFdoor variants

The following sections provide a high-level overview of several newly observed capabilities and behavioral patterns in recent BPFdoor samples. While these findings highlight important technical developments, this blog intentionally focuses on the architectural implications and operational context rather than a full reverse-engineering deep dive. Detailed technical analyses, including code-level breakdowns, will be published in upcoming research posts.

During our investigation, we identified a previously undocumented variant of BPFdoor that introduces several architectural changes designed to improve stealth and survivability in modern enterprise and telecom environments. We will highlight these features and illustrate how the malware continues to evolve beyond the earlier “magic packet” activation model.

Network-level invisibility: The BPF trapdoor

As we described before, the early BPFdoor installed a Berkeley Packet Filter inside the Linux kernel that inspected incoming network traffic. When a specially crafted “magic packet” containing a predefined byte sequence arrived at the correct port, the backdoor would activate and spawn a shell. Because the system never actually opened a port, tools such as netstat, ss, or nmap saw nothing unusual.

The newly observed variant evolves this concept. Instead of relying on a simple magic packet that could potentially be detected by intrusion detection signatures, the trigger is now embedded within seemingly legitimate HTTPS traffic. The attacker sends a carefully crafted request that travels through standard network infrastructure such as reverse proxies, load balancers, or web application firewalls. Once the traffic reaches the compromised host and is decrypted as part of normal SSL termination, the hidden command sequence can be extracted and used to activate the backdoor. In essence, in our previously mentioned analogy explaining the magic packet mechanism, the safe still requires a code, but now the code is concealed inside normal, encrypted web traffic, allowing it to pass through modern security controls before unlocking the trapdoor.

Layer 7 camouflage and the “magic ruler”

To remain reliable across proxy layers, the attackers introduced a clever parsing mechanism. HTTP proxies often modify headers by inserting additional fields such as client IP addresses, timestamps, or routing metadata. These changes can shift the position of data within the request and break traditional signature-based triggers. To solve this problem, the attackers designed a mathematical padding scheme that ensures a specific marker, in the observed samples the string “9999”, always appears at a fixed byte offset within the request.

This is where the 26-byte or 40-byte “magic ruler” comes into play. Rather than parsing the entire HTTP header, which can vary depending on proxy behavior, the malware treats the request body as a predictable coordinate space. By carefully padding the HTTP request with filler bytes, the attacker ensures that the marker always lands exactly at the 26th byte offset of the inspected data structure. The implant simply checks this fixed position; if the marker appears at that byte location, it interprets the surrounding data as the activation command.

Because the header itself can fluctuate while the padded payload remains predictable, the malware does not need to understand or parse the full HTTP structure. Instead, it relies on this fixed “measurement point”, effectively using the 26-byte offset as a ruler inside the packet. This technique allows the trigger to survive proxy rewriting and header injection while still remaining hidden inside otherwise normal HTTPS traffic. The 26-byte rule is used in case of a socket creation with the “SOCK_DGRAM” flags, but in case of a “SOCK_RAW” flag, it will use a 40-byte ruler.

In practice, this turns the messy, variable HTTP protocol into something the malware can treat like a fixed coordinate system, enabling what could be described as dynamic Layer-7 camouflage, a surprisingly simple but effective technique for hiding command triggers inside legitimate encrypted web traffic.

The RC4-MD5 paradox

Another interesting feature of the new controller is its continued use of the legacy RC4-MD5 encryption routine. While this combination is considered deprecated in modern cryptographic standards, it still appears in several malware samples. In this case, the RC4-MD5 implementation is not part of TLS, but rather a lightweight encryption layer applied to the interactive command-and-control channel after the backdoor is activated. RC4 provides extremely fast stream encryption suitable for interactive shells, introducing minimal latency during command execution. In addition, the use of older or non-standard encryption routines can sometimes confuse inspection systems, particularly when traffic does not follow typical protocol expectations. Finally, reuse of older cryptographic modules often reflects code lineage and operational efficiency, adversaries frequently recycle proven components across campaigns. In this case, code comparison revealed similarities with routines that have circulated in Chinese-nexus malware families such as RedXOR and PWNIX for several years.

ICMP control channel: “phone home”

While earlier BPFdoor variants focused primarily on covert activation, the new sample also introduces a lightweight communication mechanism built around Internet Control Message Protocol (ICMP). The code excerpt shows the malware preparing an ICMP payload and inserting a specific value  “0xFFFFFFFF”  into a field before transmitting the packet using a dedicated routine (send_ICMP_data). At first glance this appears trivial, but the logic reveals something more interesting: The ICMP packet is not just a signal back to the operator, it is also used as a control mechanism between compromised systems.

⠀

In this model, ICMP functions as a minimal command channel between infected hosts. One compromised server can forward specially crafted ICMP packets to another, effectively passing along execution instructions without requiring traditional command-and-control traffic. The key marker in this mechanism is the value 0xFFFFFFFF (signed as -1), which acts as a destination signal embedded inside the packet structure. When a receiving host detects this value, it interprets the packet as a terminal instruction rather than something to be forwarded further.

In practical terms, Server A is telling Server B: “You are the final destination.” Instead of relaying the signal onward, the receiving system executes the next stage, typically triggering the reverse shell or command handler. This simple signaling mechanism allows the operators to control how far a command propagates through compromised infrastructure without introducing additional protocol complexity.

What makes this mechanism notable is its simplicity. Rather than expanding the structure of the activation packet or introducing additional fields, the attackers reuse an existing value within the packet structure to signal the end of the chain. By setting this field to 0xFFFFFFFF, they effectively create a “do not forward” flag inside their communication channel. This allows them to manage hop behavior across compromised nodes while keeping the packet format compact and consistent. 

Key takeaways

Taken together, the newly observed capabilities demonstrate how BPFdoor has evolved beyond a stealth backdoor into a layered access framework. The updated variant combines encrypted HTTPS triggers, proxy-aware command delivery, application-layer camouflage techniques, ICMP-based control signals, and kernel-level packet filtering to bypass multiple layers of modern network defenses. Each technique targets a different security boundary, from TLS inspection at the edge, to IDS detection in transit, and endpoint monitoring on the host, illustrating a deliberate effort to operate across the full defensive stack.

Kernel-level backdoors are redefining stealth.
Tools like BPFdoor operate below traditional visibility layers, abusing Berkeley Packet Filter mechanisms to create network listeners that do not expose ports, processes, or conventional command-and-control indicators.

Telecommunications infrastructure is a prime espionage target.
Modern 4G and 5G networks rely on complex stacks of signaling systems, Containerized Network Functions, and high-performance infrastructure. Access to these environments can enable long-term intelligence collection, subscriber monitoring, and deep visibility into national communications infrastructure.

Security controls can be turned into delivery mechanisms.
In the latest BPFdoor variant, attackers weaponize normal security workflows. Traffic that passes through TLS termination and deep packet inspection can deliver malicious commands once it reaches the decrypted internal zone.

BPF-based implants are likely the beginning of a larger trend.
BPFdoor and new eBPF malware families like Symbiote demonstrate how kernel packet filtering can be abused for stealth persistence. As defenders improve visibility at higher layers, adversaries are increasingly shifting implants deeper into the operating system.

How defenders can detect BPFdoor activity

Detecting these threats requires shifting visibility deeper into the operating system and network stack, focusing on indicators such as unusual raw socket usage, anomalous packet filtering behavior, and unexpected service masquerading on critical infrastructure hosts. 

To support defenders in identifying potential BPFdoor activity, we developed a scanning script designed to detect both previously documented variants and the newer samples discussed in this research. The script focuses on identifying indicators associated with the stealth activation mechanism, kernel-level packet filtering behavior, and process masquerading techniques used by BPFdoor implants. By combining checks for known artifacts and behavioral patterns, the scanner helps security teams quickly assess whether systems may be impacted.

We are making this tool available to the community to assist organizations in proactively identifying potential compromises. The scanner can be used across Linux environments to search for artifacts linked to BPFdoor activity, including indicators observed in both historical samples and the latest variant analyzed during this research. Our goal is to help defenders rapidly validate exposure and begin incident response investigations where necessary.

In the video below, Rapid7 Labs demonstrates how our detection script would be run within the system of an infected victim organization. The video starts with the right window, showing that the BPFdoor backdoor is running and the particular services that relate are highlighted. Then, in the bottom left screen, the BPFdoor is activated by sending the right packet sequence and password, whereby a remote control shell is established. The attacker is running some commands on the victim machine and shows it can execute remote commands. Finally, in the top window, we run our developed detection script that will show the detected processes, and the alerts are showcased.  

⠀

⠀

Indicators of compromise (IOCs)

The IOCs we discovered during our investigation surrounding the new controller, as well as samples and other relevant data, can be found on our Rapid7 Labs Github page.

Interested in learning more?

Catch Sleeper Cells in the Telecom Backbone, Rapid7’s webinar via BrightTalk, led by Raj Samani, Chief Scientist, and Christiaan Beek, VP of Threat Analytics.

Web applications are no longer just business enablers, they’re often the front door to an organization. They can often generate revenue, enforce identity, connect systems and hold customer and business data.

“75% of successful Vector Command breaches were conducted through web apps.” –Principal Security Consultant, Vector Command Team at Rapid7

From SaaS platforms and identity providers to customer portals and internal tools, attackers increasingly rely on web applications as their initial access point. In fact, application-driven attacks account for a significant percentage of real-world breaches. But testing web applications for real risk isn’t the same as scanning for bugs; that’s where Vector Command (Rapid7’s continuous managed red team service) comes in.

How Vector Command approaches web applications

Vector Command evaluates web applications the same way real attackers do, by asking a single question: Can this application be used to meaningfully compromise the organization?

Rather than attempting to enumerate every possible vulnerability, Vector Command focuses on exploitation paths that lead to real outcomes, such as:

• Account takeover

• Session hijacking

• Abuse of SaaS trust relationships

• Access to internal systems through vulnerabilities, such as malicious file uploads, injection issues, or misconfigurations in common web frameworks

• Lateral movement across applications

• Exfiltration of source code, if found during a breach

Testing begins without authentication against externally facing applications, the external attack surface, or to put it another way, what a potential threat actor can see. If legitimate paths exist – self-registration, broken authentication and authorization controls, misconfigurations exposing unintended application functionality, or overall poor site hygiene leaking information that needs further research – those paths are pursued as part of a broader attack chain.

The result isn’t a long list of low-risk findings, but rather a clear picture of what actually works.

What Vector Command does not do

Vector Command is intentionally not a replacement for a full web application penetration test, although Rapid7 does offer this service.

It does not:

• Guarantee full application coverage.

• Perform DAST or SAST scanning.

• Enumerate non-exploitable low-severity or theoretical vulnerabilities.

• Review source code unless it’s obtained during an attack.

If your goal is to understand every potential flaw in an application, a dedicated web app penetration test is the right approach. However if your goal is to understand whether your sprawling stack of externally facing applications can be used to break into your organization, Vector Command is designed for that purpose.

A real-world example: when the ticketing system becomes the attack path

In one recent Vector Command engagement, attackers didn’t exploit a zero-day or complex vulnerability.

Instead, they targeted an externally accessible and very popular, SaaS ticketing portal used by IT. Through a well-placed social engineering attempt, they gained access to an internal support workflow. Any organization could register for the customer’s SaaS deployment, which was used to host IT documentation and their ticketing system.

The Vector Command team submitted a ticket to the customer’s IT team, seeking assistance to help fix an application installation issue. A SharePoint URL was provided to IT to view the software documentation, however… This SharePoint site was a proxy phishing portal, created by our Vector Command experts, designed to capture Office365 login sessions and the user’s MFA prompts. 

Hook, line and cookie: the result?

The unsuspecting IT help-desk employee had been phished and was convinced to run the Rapid7 payload, giving our Vector Command team access. The engagement demonstrated how easily trust relationships could be abused. From there, a malicious link led to session capture within a trusted collaboration platform.

• Account takeover

• Session theft

• Lateral movement using legitimate tools

• Access granted without triggering traditional defenses

No single “critical bug” caused the breach. It was the interaction between applications, identity, and trust that made it possible. That’s exactly the kind of risk Vector Command is designed to uncover and each one of our red team members has a particular speciality, when used together, they are formidable. 

Vector Command and web app pentesting: better together

Vector Command and web application penetration testing serve different, but complementary purposes. Web app pentests help teams build more secure applications, while Vector Command helps teams understand how those applications affect real-world security exposure.

One improves code; the other tests assumptions.

A final thought

Vector Command doesn’t try to answer “What could be wrong?”, answering instead, “What would actually succeed?”

Modern breaches rarely hinge on a single critical bug. They succeed because trusted systems interact in ways no one has validated. Vector Command tests those assumptions, continuously.

The research focuses on how these attacks work in practice. It details how interchip communications such as USB and universal asynchronous receiver-transmitter (UART) can be observed and manipulated. It also shows how hardware modifications can replace a device host, allowing an external system to assume control of the cellular module. The authors developed proof-of-concept tools, including a TCP port scanner using AT commands, an S3 bucket enumerator, a SOCKS5 proxy that routes traffic through the cellular module, and a Metasploit proxy module. These examples demonstrate how attackers can take advantage of trusted relationships between devices and connected services.

The findings highlight consistent risks across tested devices. Cellular modules often expose multiple interfaces, and unused UART or USB paths can provide direct access. With targeted printed circuit board modifications, an attacker can reroute traffic through the cellular interface. Many modules accept AT commands that support raw sockets, HTTP requests, and TCP tunnels, which can enable reconnaissance and lateral movement. All cellular devices the researchers examined lacked tamper protections and most did not encrypt sensitive data before transmission, increasing exposure in environments that use private access point names (APNs).

Organizations should treat cellular-enabled devices as privileged entry points into their networks as well as their critical data storage and management environments. This includes disabling or removing unused interchip interfaces, enforcing end-to-end encryption before data is transmitted through the cellular modules, and applying monitoring and outbound controls within APN architectures. Hardware-level security testing should be part of standard product security practices.To read the whitepaper, click here.

This isn't just a badge on a webpage. It's proof that our security controls work, not just on paper, but in practice, over time.

What is BSI C5 and why does it matter?

The Cloud Computing Compliance Criteria Catalogue (C5) was developed by Germany's Federal Office for Information Security (BSI). It sets some of the most rigorous cloud security standards in the world, covering everything from data protection to operational transparency.

A Type 2 attestation is the gold standard within that framework. Unlike a point-in-time audit, Type 2 validates that security controls aren't just well-designed, but that they're actively working consistently over a sustained period. It's the difference between a security promise and a security proof.

For organizations in the DACH region, C5 is more than a nice-to-have. It's a procurement requirement for German federal agencies, critical infrastructure operators, healthcare institutions, and financial services firms. If you're operating in any of these sectors, your cloud providers need to meet this bar. Rapid7 now does.

BSI C5 Type 2 and your cloud security strategy

Whether you're evaluating security vendors, managing compliance obligations, or looking to strengthen your organization's risk posture, the question is the same: How do you know your cloud security provider actually does what it says?

BSI C5 Type 2 attestation answers that question. It's independent, rigorous, and sustained over time. While rooted in German regulatory requirements, C5 is increasingly recognized as a benchmark for secure cloud operations across Europe. It's one of the clearest signals that a cloud provider has the operational maturity to handle sensitive environments.

The Rapid7 Command Platform unifies exposure management with detection and response, giving security teams clear visibility across their attack surface. Threat Command extends that protection further, identifying and helping remediate threats across the clear, deep, and dark web. Both are now independently validated against one of the world's toughest cloud security frameworks.

Why independent validation of security controls matters

Trusting a security vendor shouldn't require a leap of faith. Independent validation exists so you have the evidence to make that call with confidence. This attestation reflects our continued investment in meeting the highest security standards for customers across Germany and the wider European market. Rapid7 has achieved a milestone that speaks directly to the conversations had every day with public sector and enterprise organizations who need more than a promise. 

They need proof that a security provider's controls have been tested, verified, and proven to hold up over time. That's the kind of assurance that matters when the stakes are high.

Ready to see the Command Platform in action? Visit Rapid7.com for a free trial.

On March 23, 2026, Citrix published a security advisory for a critical vulnerability affecting their NetScaler ADC (formerly Citrix ADC) and NetScaler Gateway (formerly Citrix Gateway) products. This vulnerability, CVE-2026-3055, which is classified as an out-of-bounds read and holds a CVSS score of 9.3, allows unauthenticated remote attackers to leak potentially sensitive information from the appliance's memory.

The Citrix advisory states that systems configured as a SAML Identity Provider (SAML IDP) are vulnerable, whereas default configurations are unaffected. This SAML IDP configuration is likely a very common configuration for organizations utilizing single sign-on. Per the advisory, organizations can determine if they have an appliance configured as a SAML IDP Profile by inspecting their NetScaler Configuration for the specified string: add authentication samlIdPProfile .*

CVE-2026-3055 affects NetScaler ADC and NetScaler Gateway versions 14.1 before 14.1-66.59 and 13.1 before 13.1-62.23, as well as NetScaler ADC 13.1-FIPS and 13.1-NDcPP before 13.1-37.262. The advisory notes that only customer-managed instances are affected, not cloud instances managed by Citrix.

As of the advisory’s publication, there is no known in-the-wild exploitation and no public proof-of-concept (PoC) available. According to Citrix, the vulnerability was identified internally via security review. However, exploitation of CVE-2026-3055 is likely to occur once exploit code becomes public. Therefore, it is crucial that customers running affected Citrix systems remediate this vulnerability as soon as possible; Citrix software has previously seen memory leak vulnerabilities broadly exploited in the wild, including the infamous “CitrixBleed” vulnerability, CVE-2023-4966, in 2023.

Update #1: On March 29, 2026, a technical analysis of the vulnerability was published by watchTowr Labs. On March 30, 2026, CVE-2026-3055, was added to the U.S. Cybersecurity and Infrastructure Security Agency’s (CISA) list of known exploited vulnerabilities (KEV), based on evidence of active exploitation. A Metasploit module for CVE-2026-3055 is available here.

Mitigation guidance

Organizations running affected on-premise instances of NetScaler ADC and NetScaler Gateway should prioritize upgrading to fixed versions on an emergency basis to remediate CVE-2026-3055.

• Affected components:

• NetScaler ADC and NetScaler Gateway versions 14.1, fixed in 14.1-66.59.

• NetScaler ADC and NetScaler Gateway versions 13.1, fixed in 13.1-62.23.

• NetScaler ADC 13.1-FIPS and 13.1-NDcPP, fixed in 13.1-37.262 (also referred to as 13.1.37.262 in the vendor advisory).

Please read the vendor advisory (CTX696300) for the latest guidance.

Rapid7 customers

Exposure Command, InsightVM, and Nexpose

Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-3055 on Citrix NetScaler ADC with an authenticated vulnerability check expected to be available in the March 26 content release.

Updates

• March 23, 2026: Initial publication.

• March 30, 2026: Updated customer content release date.
• March 31, 2026: Updated overview to note the availability of a technical analysis, addition to KEV, and Metasploit module.

This release contains 2 new exploit modules, 2 enhancements, and 7 bug fixes. Community contributor Chocapikk submitted both exploit modules this release: one targeting AVideo-Encoder’s getImage.php file and another targeting FreePBX. Leading the enhancements is a granularization for LDAP queries allowing the omission of SACL data on security descriptors, as without the proper permissions the entire query of the security descriptor will fail if the SACL data is even just a part of the query.

New module content (2)

AVideo Encoder getImage.php Unauthenticated Command Injection

Authors: Valentin Lobstein chocapikk@leakix.net and arkmarta

Type: Exploit

Pull request: #21076 contributed by Chocapikk

Path: linux/http/avideo_encoder_getimage_cmd_injection

AttackerKB reference: CVE-2026-29058

Description: Adds an exploit module for CVE-2026-29058, an unauthenticated OS command injection in AVideo Encoder's getImage.php endpoint.

FreePBX filestore authenticated command injection

Authors: Cory Billington and Valentin Lobstein chocapikk@leakix.net

Type: Exploit

Pull request: #20719 contributed by Chocapikk

Path: unix/http/freepbx_filestore_cmd_injection

AttackerKB reference: CVE-2025-64328

Description: Adds a new Metasploit exploit module for FreePBX filestore authenticated command injection (CVE-2025-64328) with automatic vulnerable-version detection and full documentation, and renames the XorcomCompletePbx HTTP mixin to CompletePBX updating affected modules accordingly.

Enhancements and features (2)

• #20730 from zeroSteiner - This update modifies the ldap_query module to skip querying the SACL (System Access Control List) on security descriptors by default. This behavior is now controlled by a new option, LDAP::QuerySacl. This change is necessary when using a non-privileged user to query security descriptors via LDAP; otherwise, querying the SACL will cause the entire query to be blocked, resulting in no security descriptors being returned.
• #20997 from Nayeraneru - This adds a new OptTimedelta datastore option type. It enables module authors to specify a time duration and users to set it with a human-friendly syntax.

Bugs fixed (7)

• #20960 from g0tmi1k - This adds a DHCPINTERFACE option to the DHCP server mixin, allowing modules that start that server to specify a particular interface to bind to.
• #21020 from g0tmi1k - This makes a small change to the docs by removing two lines that were previously duplicated.
• #21024 from Aaditya1273 - Fixes a bug in the JSON-RPC msfrpcd functionality that incorrectly required SSL certificates to be present even when disabled with msfrpcd -S.
• #21025 from Hemang360 - Fixes a crash when calling the HTTP cookie jar with non-string values.
• #21028 from SilentSobs - Fixes a crash when using the reload_all command no module is present.
• #21081 from Hemang360 - Fixes a crash when using the windows/exec with non-ascii characters.
• #21139 from jheysel-r7 - This fixes a bug in the ldap_esc_vulnerable_cert_finder module that was preventing authentication from working when making a WinRM connection.

Documentation added (1)

• #21074 from jeanmtr - Adds documentation for the pop3_login module.

You can always find more documentation on our docsite at docs.metasploit.com.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:

• Pull Requests 6.4.122...6.4.123
• Full diff 6.4.122...6.4.123

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest. To install fresh without using git, you can use the open-source-only Nightly Installers or the commercial edition Metasploit Pro

Walk into a board meeting with a slide showing 1,200 critical vulnerabilities and 44 internet-facing assets, and you will likely see polite acknowledgment rather than meaningful discussion. The question that follows tends to cut through quickly: what does this mean for the business?

Boards allocate capital based on financial exposure, not vulnerability counts. A list of findings describes workload, but directors are responsible for revenue protection, liability, and risk to the balance sheet. When security reporting remains technical, it sits outside the way investment decisions are made elsewhere in the organization. The issue is less about communication and more about framing the problem in terms the business already understands.

From severity to risk

CVSS measures theoretical severity, but it does not measure business risk. A high score indicates that a flaw could be dangerous, yet it does not tell you whether the vulnerability is reachable in your environment, whether exploit code exists, or whether it is likely to affect revenue in the near term. It answers a useful engineering question, but it does not answer the question the board is asking.

That question is about likelihood and impact. Most enterprise risk frameworks define risk in those terms, and that is how financial decisions are made. The gap becomes clear when two vulnerabilities appear similar on a dashboard but carry very different consequences. A high-CVSS issue on a segmented lab system may present little business risk, while a moderately severe vulnerability on an internet-facing production system with active exploit activity can expose regulated data and revenue streams.

What is often missing in that comparison is threat context. Understanding how attackers behave, which vulnerabilities they are exploiting, and where access paths actually exist changes how risk is interpreted. Active Risk in InsightVM brings those elements together by combining exploit telemetry, attacker behavior, and asset context to estimate the likelihood that a vulnerability will be used. When that likelihood is paired with business impact, the conversation shifts toward exposure rather than severity.

From CVSS scores to financial exposure

Prioritization alone does not translate into board-level decisions. Knowing what is most likely to be exploited is necessary, but it is not sufficient when the goal is to justify investment.

FAIR provides a way to bridge that gap. The model defines risk as a combination of how often a loss event is likely to occur and how much that event would cost. In practical terms:

Annualized Loss Exposure (ALE) = Loss Event Frequency × Probable Loss Magnitude

Active Risk informs the likelihood side of that equation by grounding it in observed attacker behavior and exploit activity. FAIR converts that likelihood into financial terms, allowing security teams to describe exposure in a way that aligns with how capital is allocated.

Instead of reporting that a set of vulnerabilities is “high risk,” the discussion becomes more concrete. A team might say that a group of issues represents several million dollars in annualized exposure across systems tied to revenue. That is a number that can be evaluated alongside other business risks, rather than interpreted as a technical signal.

A practical example

Consider two vulnerabilities identified during a scan. The first is a CVSS 9.8 issue on a segmented guest Wi-Fi router. It is severe from a technical standpoint, but it has no access to sensitive data, no path into production systems, and no evidence of active exploitation.

The second is a vulnerability with a moderate CVSS score on an internet-facing customer database. Public exploit code exists, and the system stores regulated data tied directly to revenue and compliance obligations.

On a scanner dashboard, the first may appear more urgent. When viewed through a financial lens, the second carries greater risk.

Assume an annual probability of exploitation of 20 percent for the database scenario. If the potential impact includes $750,000 in incident response, $1.2 million from several days of business interruption, $600,000 in legal and regulatory costs, and $1 million in customer churn and reputational damage, the total loss for a single event is $3.55 million.

Applying the FAIR model results in approximately $710,000 in annualized exposure. That figure reflects the risk carried by that single vulnerability on a production system.

By contrast, even if the Wi-Fi router vulnerability had a 5 percent probability of exploitation and a $50,000 impact, the resulting exposure would be around $2,500. Both findings may appear critical in a technical report, but only one represents a material financial concern.

This is where Active Risk and FAIR work together. One identifies where attackers are likely to act, and the other expresses the consequence in financial terms. The combination changes how vulnerabilities are evaluated and how priorities are set.

Visualizing exposure across your environment

Once risk is expressed in financial terms, the next step is to understand how that exposure is distributed. Boards tend to think in terms of portfolios rather than individual issues, and the same principle applies to cybersecurity.

In most environments, exposure is not evenly spread. A relatively small number of systems and vulnerabilities account for a large portion of potential loss. Internet-facing services, systems tied to revenue, and assets with known exploit activity often sit at the higher end of that distribution.

This creates a practical way to focus effort. Rather than attempting to address every vulnerability equally, teams can identify where exposure is concentrated and reduce risk in those areas first. In many cases, addressing a small number of issues can significantly reduce overall exposure, particularly when those issues sit on systems that are both reachable and business-critical.

A before-and-after view helps make this visible. If an organization reduces modeled exposure from several million dollars to a substantially lower figure through targeted remediation, the result can be explained in terms of reduced downside risk rather than increased patching activity. Over time, tracking that change shows whether investments are producing measurable outcomes.

Making risk actionable

By the time exposure is expressed in financial terms, the discussion in the boardroom has already shifted. The focus moves away from counts and severity toward risk, trade-offs, and acceptable levels of exposure.

One of the first issues that arises in that context is the assumption that risk should be driven to zero. In practice, eliminating all exposure is neither achievable nor economically sensible. Reducing risk always involves trade-offs, and those trade-offs become clearer when expressed in financial terms.

If an organization has already reduced exposure significantly, but further reduction requires a disproportionate increase in cost, the decision becomes one of balance. The question is no longer why risk still exists, but whether the remaining exposure aligns with the organization’s tolerance.

The same logic applies when discussing budget. Requests framed in operational terms, such as additional headcount or tooling, are difficult to evaluate in isolation. When those requests are tied to measurable reductions in exposure, the relationship between cost and benefit becomes clearer.

For example, if additional resources reduce several million dollars of modeled exposure at a fraction of that cost, the investment can be assessed alongside other initiatives using the same financial lens. At that point, the discussion is no longer about capacity. It is about risk reduction.

Putting security in business terms

Reducing exposure also affects how the organization is perceived externally. Cyber insurance underwriting, for example, increasingly considers factors such as attack surface, exploit availability, and remediation speed. Demonstrating that exposure is measured and reduced over time can influence how risk is priced.

The same applies during customer due diligence. Being able to explain where risk exists, how it is prioritized, and how it has been reduced provides evidence of maturity. It shows that security is being managed deliberately rather than reactively.

Aligning to risk tolerance

Productive board discussions tend to end with agreement on acceptable levels of exposure. Without a financial view, every issue can appear urgent. With it, prioritization becomes more grounded.

Leadership can evaluate whether the level of risk being carried is consistent with business objectives, and whether further investment is warranted. That shifts vulnerability management from a process focused on volume to one focused on where exposure is concentrated and how it can be reduced most effectively.

Clear exposure, clearer decisions

Vulnerability management has often been treated as an operational activity centered on patching and scanning. When combined with threat context and financial modeling, it becomes part of enterprise risk management.

Instead of reporting how many vulnerabilities exist, security leaders can describe how much exposure the organization carries. Instead of focusing on activity, they can show how targeted actions reduce risk over time. That framing aligns cybersecurity with the same decision-making process used across the rest of the business.

When exposure is clear, decisions become clearer. Leadership can determine where to accept risk, where to transfer it, and where to invest in reduction. The conversation with the board moves away from technical detail and toward measurable impact, which is where security becomes part of strategy rather than an isolated function.

Rapid7 Labs recently identified a chain of security vulnerabilities in the Gainsight Assist plugin and its interactions with the associated domain app.gainsight.com. These vulnerabilities include an Information Disclosure flaw (CVE-2026-31381) and a Reflected Cross-Site Scripting (XSS) vulnerability (CVE-2026-31382). By chaining these vulnerabilities, an attacker can move from passive information gathering to active client-side exploitation.

The XSS vulnerability was remediated by Gainsight via a server side code-level fix on March 6, 2026. A patched update to the Chrome and Outlook plugins to remediate the Information Disclosure were released on March 9, 2026.

Product description

Gainsight Assist is a plugin that allows users to access Gainsight email templates and easily sync inbound and outbound emails to the Timeline within the Gainsight Customer Success (CS) product directly from their email platform.

Credit

These vulnerabilities were discovered and reported to the Gainsight team by Christopher O’Boyle, Cybersecurity Advisor at Rapid7. The vulnerabilities are being disclosed in accordance with Rapid7's vulnerability disclosure policy. Rapid7 is grateful to the Gainsight team for their assistance and collaboration.

Vulnerability details

The testing target was the Gainsight Assist plugin and its interactions with the app.gainsight.com domain, used as a callback mechanism that processes authentication data and error descriptions following user login attempts.

CVE-2026-31381: Information disclosure

During testing involving Salesforce and Okta authentication channels, an OAuth callback flow failure was observed. The resulting error message exposed the user's email address (PII) within a Base64 encoded state parameter in the URL. Because Base64 is merely obfuscation and not encryption, these email addresses can be easily harvested from server logs, proxies, or browser history by third parties.

CVE-2026-31382: Reflected XSS and HTML injection

The Gainsight callback URL contained an error_description parameter that was found to be vulnerable to content spoofing and HTML Injection. While Gainsight employs a Web Application Firewall (WAF) that successfully blocks most standard JavaScript execution, Rapid7 researchers bypassed this protection using a browser-specific payload targeting Safari’s onpagereveal event.

When the victim opens the malicious URL in Safari, the onpagereveal payload executes automatically without further user interaction. By injecting HTML content and spoofing the error page, an attacker can create a legitimate-looking prompt instructing the user to switch to a Safari browser to ensure the payload fires.

<body onpagereveal=open("https://www.rapid7.com")>
We have detected a browser compatibility issue for 
this step, this can only be completed on Safari <br><br>
Please copy the URL from the address bar above and 
paste it in a Safari browser...

Figure 1: Example of the injected HTML payload instructing the user to utilize Safari.

Chaining for Impact

When combined, these vulnerabilities create a high-impact attack path:

1. Target identification: The login error page includes the user’s attempted login email address in a Base64-encoded state parameter in the URL. Anyone with visibility into that URL (e.g., via the browser address bar, existing access to internal logs, or XSS on that page) can decode the state value to recover the email address. The vulnerability pertains to the data included in the URL rather than granting access to logs or history.

2. Luring the victim: Using HTML injection on the trusted app.gainsight.com domain, the attacker crafts a highly convincing phishing link to send to the targeted user.

3. XSS execution: Once the victim opens the link in Safari, the onpagereveal payload executes. Because the payload can recursively call the exact same URL, it can cause an infinite loop leading to client-side resource exhaustion, log flooding, or the delivery of malware.

Vendor statement

"Gainsight values the work of the security research community and appreciates Rapid7's collaboration. We have fully remediated the identified vulnerabilities through a platform-wide update that strengthens our input validation and WAF configurations. Our forensic investigation found no evidence of exploitation or impact to customer data. We continue to prioritize transparency and supporting our customers to build a more resilient and secure community together. "

Mitigation guidance

As of March 6, 2026, Gainsight has implemented a code-level fix to remediate these findings. Customers should ensure they are utilizing the latest version of the Gainsight Assist plugin.

Disclosure timeline

• January 30, 2026: Rapid7 makes initial outreach to Gainsight.

• February 1, 2026: Gainsight confirms outreach and requests details. Rapid7 provides vulnerability details.

• February 11, 2026: Gainsight confirms receipt, states that the vulnerability has been reproduced, and acknowledges that triage has begun.

• March 5, 2026: Gainsight and Rapid7 meet to discuss agreed impact, remediation, and next steps.

• March 6, 2026: Gainsight implements a server-side, code-level fix to remediate the XSS issue.

• March 9, 2026: Gainsight implements an update to the Chrome and Outlook plugins for the information disclosure vulnerability.

• March 12, 2026: Gainsight requests disclosure date of March 20, 2026.

• March 13, 2026: Rapid7 accepts the disclosure date of March 20, 2026.

• March 20, 2026: This disclosure.

Today, we are thrilled to announce that this vision is fully realized and integrated with Rapid7 Exposure Command. For our customers, this milestone represents our ability to deliver on the promise of a complete Cloud-Native Application Protection Platform (CNAPP) that helps security teams preemptively identify and proactively thwart attacks.

Exploring the possibilities of this unified CNAPP

At Rapid7, we believe that a CNAPP is unified if it operates from a single, objective source of truth. By integrating cloud runtime security directly into Exposure Command, we are seamlessly merging the preemptive (posture, configurations, identities, and vulnerabilities) with the proactive (runtime behavior and active threats). The table below summarizes this enhancement:

⠀

⠀

The true power of this unified architecture is best understood through the lens of a security practitioner’s daily battle against cloud threats. The previous blog post discussed this in theory; let’s use this blog to talk about the reality.

The baseline

Exposure Command continuously scans and assesses your cloud posture to identify whether a container exposure exists in a production cluster. Traditional scanners would stop here, leaving you to prioritize this vulnerability against others. In Exposure Command, this detection is not just part of a static score, but instead it is part of an attack path. Our preemptive security platform tells you, for instance, whether this specific container has internet access and an over-privileged IAM role, making it highly reachable and exploitable. This means that you are not just looking at a CVE; you are looking at the potential blueprint behind a major breach.

The proactive validation

This is where cloud runtime security turns theory into reality. Instead of treating the vulnerability as just a potential risk, the platform utilizes eBPF sensors to provide continuous, direct kernel-level observability and application L7 visibility. Exposure Command analyzes this sensor data, uses AI to establish baseline workload behavior, and uncovers anomalies in real time. For example, security analysts gain instant visibility when that vulnerable container suddenly spawns a reverse shell and initiates an external connection to a known malicious IP, rather than executing its standard database queries.

The response

When a runtime anomaly is detected on a high-priority asset, the platform instantly aggregates these events into streamlined alerts. It links the initial application-layer exploit to the infrastructure-level change, such as the attacker attempting a container escape using that over-privileged IAM role. More importantly, the platform can trigger an automated response. By automatically terminating the malicious process, pausing the compromised container, or isolating the namespace, Exposure Command effectively stops an attacker's lateral movement in seconds.

The investigation

Stopping the threat, understanding how it happened, and proving you resolved it, is what creates a truly resilient security program. Rapid7 Exposure Command does not just initially block the attack and leave you sifting through raw kernel logs to truly remediate the threat. Instead, it uses AI-generated remediation summaries to translate complex runtime telemetry into a clear, actionable remediation narrative. It explains exactly how the attacker bypassed initial defenses, what lateral movement they attempted, and the precise root-cause misconfigurations that allowed it. This empowers security teams to confidently report to leadership on the active threats they've neutralized, while providing developers with the exact context and code-level recommendations they need to patch the underlying exposure.

Amplifying signal vs. noise

When you combine predictive exposure analytics with deep application-layer and kernel-level visibility, you fundamentally change your operational efficiency. You stop chasing every theoretical risk and start focusing on what matters most. Exposure Command is a unified solution that eliminates the noisy alerts that tend to overwhelm security operations teams. Teams are able to prioritize remediation not just by CVSS score, but by real-time validation of what is actively loaded into memory and what is currently being exploited (i.e., risk and exposure). This means your developers spend less time patching vulnerabilities that fail to pose an immediate risk, and SecOps spends less time investigating benign container behavior.

With the general availability of cloud runtime security as part of Exposure Command, Rapid7 delivers a strategic, engineering-driven platform that achieves the mission of true CNAPP. We provide the precise answer to, "Could I be compromised?" through preemptive exposure management, and the definitive answer to, "Am I currently compromised?" through proactive runtime security. By closing the loop between these two questions, we allow enterprises to secure their cloud environments with accuracy, speed, and confidence. This is a great example of the wider approach to preemptive security that Rapid7 is delivering across different use cases through the Command Platform’s comprehensive exposure management and threat detection & response capabilities.

Visit Rapid7's CNAPP hub page to learn more about how the fully integrated Rapid7 Exposure Command with cloud runtime security can transform your cloud defense.

In 2025, high-impact vulnerabilities weren’t quietly accumulating risk. They were operationalized, and often within days.

Today, Rapid7 Labs released the 2026 Global Threat Landscape Report, an in-depth analysis of how attacker behavior is evolving across vulnerability exploitation, ransomware operations, identity abuse, and AI-driven tradecraft. The data shows a clear pattern: exposure is being identified and weaponized faster than most organizations are set up to defend.

From disclosure to exploitation in days, not weeks

In 2025, confirmed exploitation of newly disclosed CVSS 7–10 vulnerabilities increased 105% year over year, rising from 71 to 146. The median time from publication to inclusion in CISA’s Known Exploited Vulnerabilities list fell from 8.5 days to 5.0 days.

At the same time, the number of high-probability vulnerabilities that remained unexploited dropped sharply. The buffer that once allowed teams to triage and schedule remediation is shrinking to the point where some severe flaws were seen to have been exploited almost immediately.

The broader trend is unmistakable: vulnerability management programs built around reactive remediation cycles are struggling to keep pace with adversaries operating at machine speed.

Cybercrime as a structured market

Cybercrime in 2025 no longer resembles chaotic hacking. It resembles platform capitalism.

The report highlights how the underground economy now mirrors legitimate SaaS ecosystems. Initial Access Brokers obtain and validate network footholds. Ransomware operators focus on encryption and extortion. Infostealer operators sell subscription-style access to fresh credential logs.

This specialization lowers barriers to entry and increases scale creating a supply chain in which access is acquired, packaged, priced, and sold to anyone who wants it. 

Ransomware is a good example of this business maturity. It was present in 42% of Rapid7 MDR investigations in 2025 with leak posts increasing 46.4% year over year, and the number of active groups growing from 102 to 140. That kind of growth is anything but random or coincidental: it is an indication of systemic changes to the ransomware ecosystem indicating growing sophistication, specialization, and, ultimately, risk. 

Logging in, not breaking in

Authentication-based attacks remain incredibly common as the lack of consistency across organizations can lead to easy exploitation. Valid accounts without multi-factor authentication (MFA) were responsible for 43.9% of incidents over that year. Rather than forcing their way past defenses, attackers increasingly authenticate with stolen credentials, hijacked sessions, or abused tokens. This is where the increase in AI-driven attacks is particularly acute with the benefits generative AI can play in improving the maturity and sophistication of social engineering attacks. 

As enterprises extend trust across cloud platforms, SaaS ecosystems, APIs, and remote work environments, authentication systems have become the backbone of operational control. This represents a structural shift with the control layer of cyber risk moving away from network perimeters toward authentication flows.

Attacks are using reliable vectors, just at alarming speeds

One hallmark of the attack landscape in 2025 was the use of tried and true attack vectors rather than novel exploits and zero-day vulnerabilities. CVE disclosures continued to climb last year, but confirmed exploitation clustered around dependable weakness types like deserialization, authentication bypass, and memory corruption vulnerabilities.

Attackers are targeting flaws that enable pre-authentication access, repeatable execution, and rapid data theft. They are not, necessarily, chasing every vulnerability. Just the ones they deem reliable. This pattern reinforces a key theme of the report: exploitability and context matter more than raw volume.

AI as an accelerant

AI is serving as a force multiplier and an expanding attack surface at the same time. 

Generative AI is accelerating established attack methods by reducing the time, skill, and coordination previously required to execute them at scale. Rather than introducing entirely new categories of exploitation, threat actors are integrating AI into existing workflows to industrialize phishing, automate reconnaissance, and refine malicious scripts with greater speed and precision. 

AI-assisted phishing campaigns were more polished and tailored to specific industries or executive roles, reflecting a measurable improvement in personalization and believability. They accelerated open-source intelligence collection to create details from fragmented data. AI was used to troubleshoot malware development in near real time, effectively compressing the cycle between initial research and malware deployment. The result is not radical technical innovation, but efficiency, speed, and fewer missed opportunities. 

Meanwhile, AI platforms themselves are emerging as targets with model servers, orchestration frameworks, and token-based integrations, inheriting familiar weaknesses such as unsafe deserialization and weak authentication. As organizations operationalize AI quickly, governance gaps create new high-impact pathways to risk.

The geography of attacks

When it comes to targeted regions, no area of the globe represents a better convergence of exposure and financial opportunity than North America. Organizations on this continent accounted for 82.04% of observed incidents, with the United States representing roughly 70% of leak posts on ransomware leak sites. Manufacturing, business services, and retail were among the most targeted industries as these sectors often combine operational dependence, sensitive data, and financial leverage making them fat targets for attackers looking for reliability not only in their attack vectors, but in gains available from their chosen targets. 

Across criminal and state-aligned activity, attackers are converging on identity systems, edge infrastructure, collaboration platforms, and cloud control planes where trust, scale, and business continuity intersect.

What this means for security leaders

There is a sobering reality in this year’s data: the underlying weaknesses remain familiar. Weak credentials. Social engineering. Exposed services. Unpatched edge infrastructure.

What has changed is the speed.

Security programs can no longer rely on moving slightly faster than attackers. The model must shift toward reducing exposure before it is operationalized.

That means:

• Continuous exposure visibility with contextual prioritization

• Strong MFA enforcement and hardened identity controls

• Protected and monitored edge infrastructure

• Governance around AI systems and integrations

• AI-enabled security workflows capable of matching attacker velocity

The organizations that maintain clear, continuous insight into their exposure - and reduce it before it is monetized - will be best positioned to manage risk in this accelerated cycle.

The question is no longer whether exposure exists.
It is whether you can reduce it before attackers capitalize on it.

Read the full Rapid7 2026 Threat Landscape Report to explore the data and strategic implications in detail.