Wednesday, June 17, 2026

Crypto Clipper uses Tor and worm-like propagation for persistence and control

Microsoft Threat Intelligence and Microsoft Defender Experts identified a Windows-based cryptocurrency clipper that has affected users since February of 2026. Clipper malware relies on stealing clipboard data and parsing it for valuable assets.

The clipper in this campaign relies on Windows Script Host and ActiveX-driven logic to launch a bundled Tor proxy and poll a hidden-service C2 server. It carries out high-frequency clipboard theft, screenshot exfiltration, and wallet-address substitution.

The execution of this clipper is notable because it does not depend on a traditional installer or exposed IP-based C2 infrastructure. Instead, it deploys a portable Tor client, routes traffic through a local SOCKS5 proxy, and blends data theft with remote code execution, turning a financially motivated stealer into a lightweight backdoor.

For defenders, the strongest signals are behavioral: script interpreters spawning suspicious child processes, localhost:9050 proxy usage, screen-capture commands in PowerShell, and signs of clipboard inspection or crypto-address replacement.

Microsoft Defender for Endpoint detects multiple components of this threat such as Suspicious JavaScript process and Possible data exfiltration using Curl. Additionally, Microsoft Defender Antivirus detects this crypto clipper as Trojan: Win32/CryptoBandits.A.

Attack chain overview

Since February 2026, malicious shortcut (.lnk) payloads have infected devices with a cryptocurrency clipper. This malware comprises two components that it deploys on the compromised system: a worm component that ensures propagation and a clipper/stealer component that harvests and exfiltrates cryptocurrency wallet information.  

The worm functionality ensures propagation by creating additional malicious shortcuts of legitimate files it identifies on the device. It also delivers file-based payloads and excludes them from Defender scanning. It deploys scheduled tasks for execution and persistence for both the worm component and the stealer component.  Figure 1 presents a high-level execution flow of the two components.

The clipper runs as a script-based payload that interacts with the operating system through WScript and ActiveXObject. It includes an anti-analysis check that queries running processes and exits if Task Manager is detected. If the environment passes this gate, the malware launches a renamed Tor binary named ugate.exe in a hidden window, waits about 60 seconds for Tor to bootstrap, generates a victim GUID, and registers the infected device with a hidden-service C2.

After registration, the malware enters a continuous loop. It polls the C2 for instructions and monitors the clipboard roughly every 500 milliseconds, extracting seed phrases and private keys that match wallet-related patterns. It also hijacks cryptocurrency addresses by replacing copied wallet values with attacker-controlled alternatives and uploads screenshots through Tor. If the C2 returns an EVAL response, the malware executes attacker-supplied code at runtime.

Figure 1: High level execution flow.

Behaviors and methodologies

Initial access

Initial access occurs from malicious .lnk files. In instances we analyzed, these .lnk shortcuts were distributed on USB storage devices. The .lnk shortcut stages a worm component in the form of an executable. The malicious script checks for an existing malicious payload and stops if the device is already infected. If the payload is not present, the malware fetches the payload from the C2 through Tor. The Figure below illustrates the functions that stage and decrypt the initial payload.

Figure 2: Initial payload delivery.

The .lnk payload scans the USB device for common document files like .doc, .xlsx, .pdf, hides the original files, and creates additional .lnk shortcut files with the same file names. The shortcut files are crafted with arguments to link to the worm payload. The end user is not aware that they are launching an executable when opening the .lnk files.

Figure 3: Worm staged via additional shortcuts.

Execution

Once a user clicks on one of the shortcuts, the staged worm payload runs. It excludes staging folders and Windows binaries used in the execution of the stealer component. The malware then drops decrypted payloads, including two malicious JavaScript files, into the subfolder under the “C:\Users\Public\Documents” folder.

A five-character naming convention is used both for the subfolder and the scripts’ names.

The figure below illustrates an instance with files dropped under a ” C:\Users\Public\Documents\omoho” folder path:

Figure 4: JavaScript payload delivered following a Defender AV exclusion.

The worm component also establishes persistence by creating two indefinite scheduled tasks: one responsible for spreading itself to a freshly inserted uncompromised USB storage device, and another for the stealer activity.

Defense evasion

The malware employs multi-layered obfuscation, with all components encrypted and only decrypted at runtime. Installation is handled by a Python script that is itself obfuscated using PyArmor and packaged into a standalone executable via PyInstaller. In addition, the two JavaScript payloads are each protected with dual-layer obfuscation, further increasing analysis complexity. This design significantly reduces static visibility while maintaining flexible runtime behavior.

The sample also incorporates a basic anti-analysis check by querying the Win32_Process WMI class and terminating execution if Task Manager is detected. Although simplistic, this mechanism can hinder manual inspection and slow initial triage efforts.

The bundled Tor client is central to the operation. By routing communication over localhost:9050 and resolving “.onion” destination domains inside Tor, the malware reduces DNS visibility, obscures the final C2 destination, and complicates destination-based blocking. This design gives the operator anonymity benefits while keeping the malware compact and self-contained.

Command and control

The command and control over a Tor-routed domain routes network traffic through local IP address 127.0.0.1 on port 9050. The tunneled domain appears in the initiating process command line. The C2 domains use the following endpoints and actions across different execution stages.

  • C2 Domain: <domain>.onion
  • Endpoints:
    • /route.php : Beacon and command retrieval
    • /recvf.php : File upload (screenshots)
    • /stub.php: Payload download
  • Communication:
    • Protocol: HTTP over Tor (SOCKS5 proxy at localhost:9050)
    • Method: curl with POST requests
    • Authentication: GUID + GEIP (geolocation)
  • Actions Sent to C2:
    • GUID : Heartbeat beacon
    • SEED : Exfiltrated seed phrase
    • PKEY : Exfiltrated private key
    • REPL : Address replacement notification
    • GOOD : (legacy/fallback action)
  • Commands from C2:
    • GUID : Acknowledge/refresh victim GUID
    • EVAL : Execute arbitrary JScript code (remote code execution)

Figure 5: C2 endpoints specifications.

A file named “cfile” is created on the infected system as an output for payload hosted on the C2 domain.

The malware sample we analyzed also provided a function called checkC2Command. The function has an EVAL method, which would allow any payload placed in the cfile to be executed on the victim’s system.

Figure 6: cfile download from a C2 domain.
Figure 7: CheckC2Command function.

Collection

Seed

Clipboard theft focuses on high-value financial artifacts. The malware detects 12 or 24-word BIP39 seed phrases in clipboard data. It saves the seed to local file (GOOD path) as a backup and exfiltrates it to the C2 domain via Tor. It retries network transmission until it is acknowledged and deletes local backup after successful transmission. It also takes five screenshots (ten seconds apart) and uploads them asynchronously. The screenshots help the threat actor gain additional context on the end user’s wallet and balances.

Private Key extraction

The crypto clipper also detects cryptocurrency keys for both Ethereum and Bitcoin WIF. Once the captured keys are saved and exfiltrated, the malware captures screenshots of the user’s screen for a full context. The captured values are validated against a word list.

Address replacement

The stealer also probes for cryptocurrency addresses and replaces them with attacker’s addresses. The malware checks that the address has alphanumeric values.

  • For a Bitcoin legacy address which starts with “1” and has a length of 32-36 values, the address is replaced with an address that matches the first two characters.
  • For a Bitcoin P2SH address which starts with a “3” and has a length of 32-36 values, the stealer replaces the address with one matching the original address on the first two characters.
  • For a Bitcoin taproot address which starts with “bc1p” and has a length of 40-64 characters, the stealer replaces it with one matching the last character.
  • For a Bitcoin Bech32 address which starts with “bc1q” and has a length of 40-64 characters, the stealer replaces only the last character.
  • For a Tron address which starts with “T” and has exactly 34 characters, the stealer replaces the address with one that matches the first two characters.
  • For a Monero address which starts with a “4” or a “8” and has exactly 95 characters, the stealer replaces the address with a single address.

The following shows an example of address replacement:

Figure 8: Function used to replace a BTC P2SH wallet address.

This malware family shows how lightweight, script-based stealers can deliver outsized impact when paired with anonymized communications and runtime tasking. The combination of Tor-routed C2, clipboard targeting, screenshot capture, and remote code execution gives attackers both immediate monetization paths and continued control over compromised devices.

Organizations should focus on hardening script execution paths, monitoring local SOCKS proxy abuse, and using behavioral hunting to connect script activity with network, clipboard, and process signals. That combination offers the best chance of surfacing this class of threat before financial loss or broader follow-on activity occurs.

Mitigation and protection guidance

Defenders should prioritize behavioral detections over static signatures. Investigate systems where WScript, CScript, or related script engines launch curl, cmd.exe, PowerShell, or unexpected executables. localhost:9050 network activity, especially when coupled with suspicious scripting behavior, is also valuable context for triage.

Where operationally feasible, reduce abuse of script-based interpreters and review Attack Surface Reduction rules that block obfuscated scripts and suspicious child-process chains. Review detections for PowerShell-based screen capture and examine devices for indicators of clipboard inspection or wallet-address replacement.

Recommended actions

  • Disable AutoRun/AutoPlay for all removable media
  • Block .lnk execution from removable drives via GPO
  • Restrict unnecessary use of wscript.exe, cscript.exe, and similar script hosts where possible.
  • Review and enable relevant Attack Surface Reduction rules, especially those focused on obfuscated script execution and suspicious child-process behavior.
  • Investigate script-to-network chains involving curl, PowerShell, or cmd.exe.
  • Hunt for local SOCKS5 proxy activity on localhost:9050.
  • Review clipboard-related and screen-capture behaviors on devices handling sensitive financial workflows.

Microsoft Defender XDR detections

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Tactic Observed activity Microsoft Defender coverage 
 Initial Access/ExecutionMalicious .lnk delivers malware components  EDR Suspicious behavior by cmd.exe was observedSuspicious Python library load    
 Execution WScript / ActiveXObject execution and runtime tasking EDR Suspicious JavaScript processSuspicious Python library loadSuspicious behavior by cmd.exe was observed   AV Contebrew malware was prevented Behavior:Win64/PyPowJs.STA  
DiscoveryTask Manager check used as an anti-analysis gate  
 Persistence Scheduled tasks are created to run the JavaScript payload wrapped in a XML file.EDR Suspicious Task Scheduler activity    
Defense EvasionShuffled strings and decoder functions conceal commands and APIs  Task Manager if detected, the malware execution is haltedBehavior:Win64/ProcessExclusion.ST; Behavior:Win64/PathExclusion.STA Behavior:Win64/PathExclusion.STB  
Collection    Clipboard theft targets seed phrases, keys, and wallet addresses   PowerShell screenshot capture supports operational visibilityAV:
Trojan:Win32/CryptoBandits.A Trojan:Win32/CryptoBandits.B Trojan:JS/CryptoBandits.A Trojan:JS/CryptoBandits.B    
Command and ControlTraffic routed through Tor via local SOCKS5 proxying EDR Possible data exfiltration using curlBehavior:Win64/CurlOnion.STA  
ExfiltrationData posted using Curl through Tor via local SOCKS5 proxying  EDR Possible data exfiltration using curl

Microsoft Security Copilot  

Security Copilot customers can use the standalone experience to create their own prompts or run the following prebuilt promptbooks to automate incident response or investigation tasks related to this threat:  

  • Incident investigation  
  • Microsoft User analysis  
  • Threat actor profile  
  • Threat Intelligence 360 report based on MDTI article  
  • Vulnerability impact assessment  

Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.  

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Advanced hunting

Microsoft Defender customers can run the following queries to find related activity in their networks:

Execution launched from scheduled tasks

DeviceProcessEvents
| where FileName =="schtasks.exe"
| where ProcessCommandLine matches regex
@"(?i)schtasks\s+/create\s+/tn\s+[a-z]{4,6}\s+/xml\s+C:\\Users\\Public\\Documents\\[a-z]{4,6}\\[a-z]{4,6}\.xml\s+/f"

Local Tor proxy activity (localhost:9050)

DeviceNetworkEvents
| where ActionType =="ConnectionSuccess"
| where InitiatingProcessCommandLine has_all ("curl","socks5-hostname",".onion")

Tor-routed curl execution

DeviceProcessEvents
| where FileName =~ "curl.exe"
| where ProcessCommandLine has_all ("--socks5-hostname", "localhost:9050")
| project Timestamp, DeviceName, InitiatingProcessFileName, ProcessCommandLine

MITRE ATT&CK Techniques observed

This threat has exhibited use of the following attack techniques. For standard industry documentation about these techniques, refer to the MITRE ATT&CK framework.

Initial Access

  • T1091 Replication Through Removable Media

Execution

  • T1059 Command and Scripting Interpreter | EVAL-driven remote code execution from server tasking

Discovery

  • T1057 Process Discovery | Task Manager check used as an anti-analysis gate

Persistence

  • T1053.005 Scheduled Task/Job | Scheduled Task

Defense evasion

  • T1027 | Shuffled strings and decoder functions conceal commands and APIs

Collection

  • T1115 Clipboard Data | Clipboard theft targets seed phrases, keys, and wallet addresses
  • T1113 Screen Capture | PowerShell screenshot capture supports operational visibility

Command and Control

  • T1090 Proxy | Traffic routed through Tor via local SOCKS5 proxying

Exfiltration

  • T1048.002 Exfiltration Over Alternative Protocol

Indicators of compromise (IOC)

IndicatorTypeDescription
7630debd35cac6b7d58c4427695579b3e3a8b1cc462f523234cd6c698882a68cSHA-256Crypto Clipper Worm  
a7abf1d9d6686af1cefcd60b17a312e7eb8cfe267def1ec34aeab6128c811630SHA-256Crypto Clipper Worm
23c1e673f315dafa14b73034a90dd3d393a984451ff6601b8be8142be6487b43SHA-256Crypto Clipper Worm
cf9fc891ea5ca5ecd8113ef3e69f6f52ff538b6cccbdaa9559106fc72bc6da30SHA-256  Crypto Clipper Worm
100407796028bf3649752d9d2a67a0e4394d752eb8de86daa42920e814f3fae8SHA-256  Crypto Clipper Worm  
d14b80cbd1a19d4ad0473a0661297f8fdf598e81ff6c4ab24e212dcad2e54b3fSHA-256  Crypto Clipper Worm  
9d90f54ae36c6c5435d5b8bed40faf54cc91f6db28574a6310b5ffaeb0362e96SHA-256  Crypto Clipper Worm  
67fc5cf395e28294bbb91ed0e954fdf2e80ebd9119022a115a42c286dc8bacf5SHA-256  Crypto Clipper Worm  
0020d23b0f9c5e6851a7f737af73fd143175ee47054931166369edd93338538aSHA-256  Crypto Clipper Worm  
35a6bc44b176a050fd6824904b7604f0f45b0fdfa26bf9500b9e05973b387cfdSHA-256  Crypto Clipper Worm  
c824630154ac4fdfce94ded01f037c305eab51e9bef3f493c60ff3184a640502SHA-256  Crypto Clipper Worm  
d43bf94f0cb0ab97c88113b7e07d1a4024d1610617b5ad05882b1dbab89e15baSHA-256  Crypto Clipper Worm  
b2777b73a4c33ac6a409d475057843be6b5d32262ef28a1f1ff5bb52e3834c5fSHA-256  Crypto Clipper Worm  
7787a9a7d8ae393aa32f257d083903c4dc9b97a1e5b0458c4cd480d4f3cb5b05SHA-256  Crypto Clipper Worm  
f3b54984caca95fd496bcfe5d7db1611b08d2f5b7d250b43b430e5d76393f9e0SHA-256  Crypto Clipper Worm  
20db98af3037b197c8a846dbf17b87fc6f049c3e0d9a188f9b9a74d3916dd5e1SHA-256  Crypto Clipper Worm  
ugate.exe  FilenamePortable Tor binary  
cgky6bn6ux5wvlybtmm3z255igt52ljml2ngnc5qp3cnw5jlglamisad.onion  DomainC2 domain
gfoqsewps57xcyxoedle2gd53o6jne6y5nq5eh25muksqwzutzq7b3ad.onionDomainC2 domain
he5vnov645txpcv57el2theky2elesn24ebvgwfoewlpftksxp4fnxad.onion  DomainC2 domain
lyhizqy2js2eh6ufngkbzntouiikdek5zsdj3qwa22b4z6knpqorgiad.onionDomainC2 domain
j3bv7g27oramhbxxuv6gl3dcyfmf44qnvju3offdyrap7hurfprq74qd.onion  Domain  C2 domain  
shinypogk4jjniry5qi7247tznop6mxdrdte2k6pdu5cyo43vdzmrwid.onion  Domain  C2 domain  
7goms4byw26kkbaanz5a5u5234gusot7rp5imzc3ozh66wwcvmcudjid.onionDomain  C2 domain  
facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg7kx5tfyd.onion  Domain  C2 domain  
wt26llpl5k6gok3vnaxmucwgzv2wk3l7nuibbh25clghrtus3p5ctsid.onion  Domain  C2 domain  
ijzn3sicrcy7guixkzjkib4ukbiilwc3xhnmby4mcbccnsd7j2rekvqd.onion  Domain  C2 domain

References 

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedInX (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.   

The post Crypto Clipper uses Tor and worm-like propagation for persistence and control appeared first on Microsoft Security Blog.



from Microsoft Security Blog https://ift.tt/Gq96jTD
via IFTTT

Identity Security for VMware Cloud Foundation: IAM, PAM, and Zero Trust in Practice

In a private cloud built on VMware Cloud Foundation (VCF), identity serves as the first line of defense. Access to vCenter, NSX, SDDC Manager, and VCF Operations is provided through an enterprise identity provider, while network policies are tied to specific users and services.

The entire topic of “identity security in VCF” can be divided into three layers:

  • IAM (Identity and Access Management) — single sign-on (SSO), federation with a corporate IdP, multi-factor authentication (MFA), and role-based access control (RBAC).
  • PAM (Privileged Access Management) — elimination of “standing” administrative passwords, just-in-time (JIT) privilege elevation, secret rotation, and session recording.
  • Zero Trust — continuous verification, NSX Distributed Firewall (DFW) microsegmentation, and a “deny by default unless explicitly allowed” security model.

 

Core identity security layers in VMware Cloud Foundation: IAM, PAM, and Zero Trust.

Figure 1. Core identity security layers in VMware Cloud Foundation: IAM, PAM, and Zero Trust.

 

These layers operate together: the IdP determines who you are, RBAC defines what you are allowed to do, PAM controls privileged operations, and NSX DFW enforces policies at the network level. All events are consolidated into centralized auditing. According to NIST SP 800-207, Zero Trust assumes that being inside the network does not provide any implicit trust — every session requires explicit authentication and authorization.

VCF Architecture and Attack Surface

VCF is an integrated platform that automates deployment and lifecycle management of the entire software-defined data center (SDDC). It includes a single Management Domain for infrastructure management components and separate Workload Domains for tenant and application workloads. The Management Domain is deployed through Cloud Builder and contains SDDC Manager, vCenter Server, and NSX Manager. Workload Domains are created and managed through SDDC Manager, following the VMware VCF Reference Architecture.

 

VMware Cloud Foundation architecture with Management Domain and Workload Domains.

Figure 2. VMware Cloud Foundation architecture with Management Domain and Workload Domains.

 

From a security perspective, VCF consists of four key operational planes:

  • Virtualization layer — vCenter and ESXi, including direct hypervisor access.
  • Network security layer — NSX Manager, Distributed Firewall, and East-West traffic control.
  • Orchestration layer — SDDC Manager and VCF Operations for fleet management and lifecycle management (LCM).
  • Operational layer — auditing, logging, and compliance validation.

VCF 5.2.1 introduced three SSO deployment models:

  • Shared SSO domain through Enhanced Link Mode (ELM)
  • Isolated SSO domains for Workload Domains in multi-tenant environments
  • Federation with external Identity Providers (IdPs)

VCF Operations can centrally enable federated SSO across all vCenter instances and NSX Local Managers.

VCF 9.0 introduced the VCF Identity Broker (VIDB), a component that provides unified SSO for vSphere Client, NSX Manager, VCF Operations, and other management interfaces. VIDB supports modern identity providers such as Entra ID, Okta, Ping, ADFS, and generic SAML implementations, along with JIT and SCIM provisioning methods. Deployment can be performed either in embedded mode or on a dedicated appliance cluster.

VMware positions VCF as a “hardened out-of-the-box” platform with built-in RBAC, Identity Federation (Entra ID, Okta), and lateral security enforcement through vDefend and NSX.

IAM: SSO, Federation, RBAC, and Auditing

Within VCF, IAM functions as an end-to-end identity control plane for accessing vCenter, NSX, SDDC Manager, and VCF Operations. It consists of three key components: authentication (SSO/IdP), authorization (RBAC), and observability (auditing).

  • vCenter SSO and Identity Sources – vCenter SSO provides centralized authentication for vSphere components through token exchange mechanisms, eliminating the need for separate authentication between services. Two identity models are supported: federation with an external IdP and built-in identity provider (vsphere.local) with integration to Active Directory via LDAP/LDAPS or Integrated Windows Authentication (now considered legacy).
  • Federation with Enterprise Identity Providers – the primary advantage of federation is that MFA and Conditional Access policies are enforced directly by the IdP, while vCenter and NSX sessions inherit those security decisions, including geographic restrictions, device posture validation, and risk-based authentication. VCF Operations supports integration with AD FS, Azure AD / Entra ID, Okta, Ping Identity, and OAuth 2.0 providers. This enables centralized identity management across the entire VCF fleet.
  • RBAC and least privilege – VMware recommends the following RBAC best practices: use named administrative accounts; assign the Administrator role only where strictly necessary; create custom roles instead of relying on global administrative access; use dedicated service accounts for applications and integrations. An important operational detail is that vCenter automatically rotates the vpxuser account password every 30 days, which must be considered when integrating with PAM solutions (discussed in more detail here).
  • Identity Lifecycle Management – in VCF 9, Identity Broker supports JIT provisioning (automatic account creation during first login) and SCIM provisioning (automated synchronization of users and groups from external directories). Directory groups can be automatically mapped to roles across VCF components (for more details, see here).
  • Auditing and visibility – VCF Operations includes Security Operations dashboards, user authentication monitoring, permission auditing, event auditing, and compliance checks.

Summary of IAM capabilities in VCF:

 

Area Mechanism Protocol / Approach Benefits
vCenter vCenter SSO Token exchange, embedded or federated IdP Unified vSphere authentication, AD/LDAP integration, IdP federation
VCF fleet management SSO and Identity Management AD FS, Azure AD, Okta, Ping, OAuth 2.0 Unified login across multiple VCF components
VCF 9 VCF Identity Broker (VIDB) SAML/OIDC, JIT/SCIM Unified SSO across management consoles, modern IdP support
Authorization RBAC and custom roles Least privilege, named accounts, group-based access Reduced blast radius during credential compromise

 

In practice, a reference IAM implementation for VCF typically looks like this:

  • An external IdP provides MFA and Conditional Access enforcement.
  • Roles in vCenter and NSX are assigned to IdP groups rather than individual users.
  • Local accounts remain only as break-glass accounts and are protected through PAM.
  • All administrative activity is forwarded into centralized auditing and SIEM platforms.

Example declarative group and role model (GitOps-style):

# Declarative group and role model for VCF (pseudo-YAML)

identity:

idp: "entra-id" # or okta / ping / adfs

groups:

- name: "vcf-platform-admins"

description: "Full administrative access to VCF infrastructure"

- name: "vcf-vcenter-ops"

description: "vCenter operators with limited privileges"

- name: "vcf-nsx-secops"

description: "Network security operations: NSX DFW and segmentation"

- name: "vcf-audit-readonly"

description: "Auditors with read-only access"

rbac:

vcenter:

- group: "vcf-platform-admins"

role: "Administrator"

scope: "global"

- group: "vcf-vcenter-ops"

role: "CustomRole-VirtualInfraOps"

scope: "Management-Domain"

nsx:

- group: "vcf-nsx-secops"

role: "Enterprise Admin"

scope: "default-space"

operations:

- group: "vcf-audit-readonly"

role: "ReadOnly-Audit"

PAM: JIT Access, Secret Rotation, and Session Recording

PAM is required in VMware Cloud Foundation for two main reasons. First, many operational tasks require superuser privileges, including domain creation, Distributed Firewall (DFW) policy management, certificate operations, and lifecycle management (LCM). Permanent administrative passwords create a direct path to compromise. Second, even in environments using federated identity providers, local and service accounts still exist — including break-glass accounts, bootstrap accounts, and integration credentials — and these must remain under strict control.

The four core PAM capabilities are:

  • Secret management – secure storage and controlled issuance of passwords, keys, and tokens on demand.
  • Credential rotation – automated password rotation on schedule or after every use.
  • Session recording – proxying and recording of SSH, RDP, and web sessions.
  • Just-In-Time (JIT) access — temporary privilege elevation granted through approval workflows.

The following technologies are used to implement PAM in VCF:

  • CyberArk PSM – privileged session recording. CyberArk Privileged Session Manager (PSM) proxies and records privileged administrative sessions, including access to the vSphere Client. A dedicated web connector supports vSphere platforms 7.0, 8.0, and 9.0, allowing administrators to work through a monitored proxy session without ever seeing the actual password. Session recordings are temporarily stored locally before being uploaded into the CyberArk vault, while operators receive visible notification that session recording is active.
  • HashiCorp Vault – one-time SSH passwords. HashiCorp Vault can generate one-time passwords (OTP) for every SSH session. A helper utility on the target host validates the OTP and immediately invalidates it after use. Every login attempt is logged through the Vault audit device. An intercepted OTP is useless because it has already been consumed.
  • BeyondTrust – policy-based credential rotation. BeyondTrust supports both manual and automated credential rotation, including rotation after every use, scheduled rotation policies, and account-level rotation controls. An important consideration is that certain service accounts — such as run-as accounts in failover clusters — may have operational limitations related to password rotation. These scenarios must be validated during testing.

Comparison of PAM approaches:

 

Solution Strengths Limitations Primary VCF use case
CyberArk PSM Session recording, vSphere web connector, vault-based recording storage Requires PSM/PVWA infrastructure; scalability planning is important Recording administrator actions in vSphere and NSX, break-glass access control
HashiCorp Vault Dynamic and one-time secrets, TTL-based leases, audit devices Does not replace session recording; requires policy design JIT SSH access, CI/CD and automation secrets
BeyondTrust Post-use and scheduled rotation, account-level policies Limitations for certain service accounts Password rotation for management components

 

In practice, PAM in VCF environments typically operates as follows:

  • All local accounts (vCenter, NSX, SDDC Manager, ESX) are stored and rotated through the PAM platform.
  • Interactive administrative access is performed through PAM proxies with session recording enabled, especially for web consoles.
  • Automation uses minimally privileged service accounts with password rotation, or ephemeral secrets issued through Vault.

Example Vault commands for SSH OTP:

# Enable auditing (all access attempts are logged)

vault audit enable file file_path=/var/log/vault_audit.log

# Enable the SSH secrets engine

vault secrets enable ssh

# Configure an OTP role (adjust cidr_list for your network)

vault write ssh/roles/vcf-ops-ssh-otp \

key_type=otp \

default_user=vcfops \

cidr_list=10.10.0.0/16

# Generate an OTP for a specific host

vault write ssh/creds/vcf-ops-ssh-otp ip=10.10.20.15

Zero Trust: NSX DFW and Microsegmentation

Zero Trust is not a product — it is an architectural discipline. According to NIST SP 800-207, Zero Trust assumes that presence inside the corporate network grants no implicit privilege. Every request to a resource requires explicit authentication and authorization.

For VCF, this translates into four core principles:

  • Administrative access is allowed only through federated identity with MFA.
  • East-west traffic between virtual machines is inspected and controlled rather than implicitly trusted.
  • Security policies are application-centric rather than VLAN-centric.
  • All entities — users, services, and devices — must remain continuously observable and verifiable.

NSX Distributed Firewall

The NSX Distributed Firewall (DFW) operates directly in the hypervisor kernel. Security policies move together with workloads during vMotion and DRS operations, remain independent from the guest operating system, and scale linearly across the environment. This provides high-performance Layer 4 filtering directly at the kernel level.

 

Path to Zero Trust using NSX Distributed Firewall (DFW).

Figure 3. Path to Zero Trust using NSX Distributed Firewall (DFW).

 

VMware describes the Zero Trust journey with DFW in three stages:

  • Zonal segmentation — separation of Production, Development, DMZ, and Shared Services.
  • Application segmentation — defining Frontend → Application → Database policies for each business application.
  • Microsegmentation — VM-to-VM policies with a deny-by-default model.

DFW rule categories. DFW processes rules in the following order: Ethernet > Emergency > Infrastructure > Environment > Application. VMware recommends designing policies based on traffic type, using tags and dynamic groups extensively, and minimizing the Applied To scope to reduce processing overhead.

vDefend and lateral security. vDefend extends VCF security capabilities through vDefend Firewall and vDefend Firewall with ATP. These services provide comprehensive Zero Trust lateral security capabilities. Within this architecture, DFW acts as the scalable enforcement engine for microsegmentation.

Zero Trust controls in VCF:

 

Control VCF implementation IAM/PAM integration
Explicit authentication and MFA Federated SSO for vCenter, NSX, and VCF Operations IdP groups mapped to roles; break-glass accounts managed through PAM
Trust zone minimization DFW with deny-by-default policies
DFW modifications controlled through RBAC and PAM session recording
Application-level segmentation DFW categories, tags, and dynamic groups Unified tag taxonomy and audited policy changes
Observability Event Auditing and Security Operations in VCF Operations Correlation with IdP identities and PAM session recordings

 

Example NSX policy for application microsegmentation:

# Pseudo-JSON for the NSX Policy API: application microsegmentation

{

"resource_type": "SecurityPolicy",

"display_name": "APP1-Application-Segmentation",

"category": "Application",

"sequence_number": 1000,

"stateful": true,

"rules": [

{

"display_name": "APP1-Allow-Frontend-to-App",

"action": "ALLOW",

"services": [{"destination_ports": ["8443"], "l4_protocol": "TCP"}],

"source_groups": ["/infra/domains/default/groups/APP1-FRONTEND"],

"destination_groups": ["/infra/domains/default/groups/APP1-APP"],

"scope": ["/infra/domains/default/groups/APP1-APP"]

},

{

"display_name": "APP1-Allow-App-to-DB",

"action": "ALLOW",

"services": [{"destination_ports": ["5432"], "l4_protocol": "TCP"}],

"source_groups": ["/infra/domains/default/groups/APP1-APP"],

"destination_groups": ["/infra/domains/default/groups/APP1-DB"],

"scope": ["/infra/domains/default/groups/APP1-DB"]

}

]

}

When validating segmentation policies, VMware recommends using Traceflow and monitoring hit counts before transitioning to a full deny-by-default enforcement model.

Integration Scenarios: IAM + PAM + Zero Trust

These three disciplines are effective only when implemented together. Federation without microsegmentation still allows lateral movement after a single host compromise. Microsegmentation without PAM leaves “standing” passwords available for abuse. PAM without federation results in dozens of unmanaged local accounts operating without MFA protection.

Scenario 1: Multi-Tenancy with isolated SSO domains.

 

Multi-Tenancy with Isolated SSO Domains in VMware Cloud Foundation.

Figure 4. Multi-Tenancy with Isolated SSO Domains in VMware Cloud Foundation.

 

In VCF, it is possible to combine Enhanced Link Mode (ELM) for some domains with Isolated SSO Workload Domains for others, enabling administrative separation between tenants. The VCF FAQ describes Isolated Workload Domains (WLDs) and the ability to centrally enable federated SSO. Key design principles include separate IdP groups for each domain, DFW microsegmentation based on environment and application policies, and administrative isolation that prevents any single administrator from having visibility into all tenant resources.

Scenario 2: VCF 9 Identity Broker with MFA across all consoles

 

Unified authentication with VCF Identity Broker (VIDB).

Figure 5. Unified authentication with VCF Identity Broker (VIDB).

 

VCF 9 Identity Broker provides unified SSO across all management consoles with support for Entra ID, Okta, Ping, and generic SAML providers.

The recommended security model is:

  • MFA enforced at the IdP layer
  • Local logins prohibited except for break-glass scenarios
  • Roles assigned only to groups, never directly to users
  • Privileged sessions allowed exclusively through PAM proxies with session recording enabled

This creates a centralized authentication and authorization boundary for the entire SDDC management plane.

Scenario 3: Secure Day-2 automation with Vault

 

Secure Day-2 automation using HashiCorp Vault and least-privilege access.

Figure 6. Secure Day-2 automation using HashiCorp Vault and least-privilege access.

 

CI/CD pipelines and automation systems should never store persistent passwords. SSH access to jump hosts is provided through Vault-issued one-time passwords.

DFW policies are managed as code:

  1. Pull request submission
  2. JSON/YAML validation
  3. Deployment through the NSX API using minimally privileged service accounts
  4. Full audit logging of policy changes

Scenario 4: Responding to credential compromise

 

Coordinated Incident Response Using IAM, PAM, and Zero Trust Controls.

Figure 7. Coordinated Incident Response Using IAM, PAM, and Zero Trust Controls.

 

When compromise of an administrative account is suspected, the combined IAM + PAM + Zero Trust architecture enables rapid containment:

  • IdP — disable the account, enforce step-up MFA, and revoke active sessions.
  • PAM — terminate active privileged sessions and rotate local administrative credentials.
  • NSX — apply quarantine microsegmentation and block East-West propagation of malicious activity.
  • Auditing — reconstruct the sequence of events using PAM session recordings and Event Auditing data in VCF Operations.

Deployment Roadmap and Common Mistakes

Identity Security Implementation Roadmap for VMware Cloud Foundation.

Figure 8. Identity Security Implementation Roadmap for VMware Cloud Foundation.

 

Phase 1: IAM

  • Select the SSO model: ELM or Isolated Workload Domains.
  • Integrate the enterprise IdP and configure MFA/Conditional Access. VCF Operations supports AD FS, Azure AD, Okta, Ping, and OAuth 2.0 providers.
  • Create IdP groups and assign roles to those groups in vCenter and NSX.
  • Connect vCenter to the corporate identity source using either federation with an external IdP or Active Directory integration through LDAP or IWA.

Phase 2: PAM

  • Inventory all local and service accounts across (vCenter, NSX, SDDC Manager, ESX).
  • Define a rotation policy (on a schedule or after use). BeyondTrust documents the available options and limitations.
  • Enable session recording for high-risk operations. CyberArk PSM provides a connector for vSphere.

Phase 3: Zero Trust Through NSX and vDefend

  • Start with zonal segmentation (Prod/Dev/Shared Services), then move to application-level segmentation and microsegmentation. This approach is described in the Well-Architected DFW framework.
  • Standardize tags and dynamic groups.
  • Enable rule logging for investigations (DFW logging is disabled by default).

Phase 4: Operations and Compliance

  • Configure Event Auditing and Compliance Checks in VCF Operations.
  • In VCF 9 – use TLS 1.3 by default and adopt desired-state configuration management (VCF 9 Security Blog).
  • Test credential rotation procedures in non-production environments
  • Document operational runbooks.

Common Mistakes:

  • Federation without RBAC. If all federated administrators receive the global Administrator role, the security risk has simply been transferred into the IdP. VMware recommends minimizing use of the Administrator role and creating custom roles instead.
  • Forgotten service accounts. The vpxuser account is automatically rotated every 30 days — this must be taken into account when integrating with PAM.
  • Deny-all policies without observability. Microsegmentation without monitoring and Traceflow validation frequently causes outages. VMware recommends an iterative implementation model: zones > applications > microsegmentation.
  • Credential rotation without testing. Certain service accounts may not support aggressive rotation policies and require validation before production deployment.
  • PAM without microsegmentation. Compromise of a jump host (a host used to connect to infrastructure management tools) without DFW enables lateral movement across the entire SDDC.

The end goal is a closed security loop: IdP and RBAC define access, PAM controls privileges, NSX/DFW enforces policies at the resource level, and VCF Operations provides continuous validation and auditability.

Conclusion

Identity Security in VMware Cloud Foundation is not three separate projects — it is a single architectural discipline. IAM eliminates anonymity by binding every action to a verified identity through federation and MFA. PAM secures the unavoidable local and service accounts: credential rotation, JIT access, and session recording transform the “permanent password” from a persistent liability into a controlled operational mechanism. NSX DFW extends the Zero Trust model down to the virtual machine level — even if credentials are compromised, lateral movement is constrained by microsegmentation. The integration works as a unified system: the IdP determines who the user is; RBAC defines what they are allowed to do; PAM controls how privileged access is performed; DFW enforces policy where the actual resource resides.

In practice, the most important principle is to avoid deploying everything simultaneously. Start with federation and strict group-based RBAC. Then bring privileged accounts under PAM control. Introduce microsegmentation gradually: zones, applications, VM-to-VM enforcement. At every stage, observability is critical. Without auditing and logging, security policies become a source of outages rather than a source of protection. VCF 9 — with Identity Broker, TLS 1.3 enabled by default, and built-in compliance checks — simplifies this journey considerably. However, the architectural decisions remain the responsibility of the organization implementing the platform.



from StarWind Blog https://ift.tt/Z81WyJM
via IFTTT

The Agentic SOC: Solving Security’s Investigation Capacity Crisis in the Frontier AI Era

The security industry spent the last decade solving detection. Endpoint. Cloud Workloads. Identities. AI. We built better models. We moved beyond signatures. We reduced false positives. We got the alert into the right queue. Then, we discovered the harder problem had been waiting behind it.

The constraint in every SOC today is not detection. It’s investigation capacity. Security teams are generating more critical alerts than any staffing plan can possibly accommodate. The queue grows. Triage waits on analyst availability. Coverage drops on nights, weekends, and surges, exactly when adversaries know to move.

Frontier AI is about to make this exponentially worse. The same models reshaping every industry are being weaponized to chain hidden gaps and vulnerabilities, accelerate attacks, and compress attacker timelines. Investigation cannot stay a human-paced or human-scaled activity. If it does, defenders lose. We built Purple AI to change that.

Every Alert. Investigated. Now.

Starting today, we’re opening up Purple AI Agentic Investigation to all new and existing SentinelOne® EDR customers. In the Singularity™ console. Activated with a single click.

The moment a new EDR alert is flagged Critical and Malicious, Purple AI acts, using flags you can trust. It is the output of over a decade of AI and ML models running natively at the edge, from behavioral analysis to real-time threat intelligence. Purple AI investigates signal vs. noise.

It collects evidence. It correlates telemetry across endpoint, identity, cloud, and third-party data. It builds the attack timeline and delivers a verdict: True Positive, False Positive, or Unknown. The complete evidence chain arrives with it before an analyst opens the console. We call it ‘zero-click’ investigation: Automated trigger, zero wait, coverage gaps closed.

Open the Alerts view, and you see it live: Purple AI retrieving context, running threat hunts, querying host telemetry, building the investigation in real time. Then, the verdict lands, supported and traceable, ready for a decision. This is investigation at machine speed. Continuous. At scale. Integrated into existing workflows.

 

The Native Platform Advantage

Purple AI investigates at this depth because it operates natively on the Singularity Platform. Zero integrations required. Where your team already works. Where your security data already lives.

Bolt-on AI tools layered onto other platforms start from a disadvantaged position. They require connectors, data mapping, and integrations before they can reason. Purple AI reasons directly on telemetry already in Singularity: endpoint, identity, cloud, and third-party data in the Singularity Data Lake. Nothing to configure. One click to activate.

The intelligence is distinct. Purple AI takes a multi-model approach that keeps customers at the edge of frontier AI reasoning capability. Models from leading frontier providers like Anthropic (Claude) and OpenAI (GPT) are part of that architecture. So is SentinelOne’s own Ultraviolet family of models, purpose-built on petabytes of real security telemetry and trained for SOC investigation reasoning. Here, frontier AI reasoning combined with Autonomous Security Intelligence.

Autonomy With Accountability

Agentic AI without defined limits and guardrails is a liability. As an AI-first company, we get that. So we built the limits first. Investigations run autonomously. Response stays on your terms. You decide your human-in-the-loop comfort zone.

Every verdict connects to one-click or policy-driven response actions in Singularity, including governed automated execution through Hyperautomation, SentinelOne’s workflow automation layer. Nothing fires outside the guardrails your team defines. Activation is admin-controlled and reversible at any time. Access is role-based. Every verdict carries a complete, auditable evidence chain. We’ve eliminated black-box decisions. Your analysts can see and review every AI step. The agentic SOC keeps humans in control of what happens next, by design.

What Customers Are Doing With It

Purple AI customers are already seeing the shift. Agentic Investigation is built to extend it further.

“By using Purple AI, we’re saving between 40% and 50% of the time to investigate incidents, allowing us to respond much quicker. It gives us readily available information on alerts — which systems, which users, and why they may be malicious,” said Rod Goldsmith, Cybersecurity Leader at YKK Americas.

“Purple AI really increases our efficiency. It allows users to search logs quickly without knowing any query languages and get answers faster, reducing our Mean Time to Respond,” said John McLeod, CISO at NOV Inc.

“SentinelOne helps us with our incident response process tenfold. We have so many options, from automation to using Purple AI, to give my analysts more confidence in their abilities,” said Zack Moody at KYOCERA AVX.

AI designed to give human defenders a decisive operating advantage. The machine removes the ceiling on what humans can cover.

Singularity Credits

Alongside Agentic Investigation, we are introducing Singularity Credits: a new unified currency for AI-powered workflows across the Singularity Platform. AI should be accessible. Utilization should be visible. Spending stays in the hands of those who set the limits. Credits are built around all three.

Every eligible SentinelOne customer gets free access starting this week. No payment method required. After the trial, Credits are available through partners, direct billing, and eCommerce channels. The balance is visible in real time. Built-in spending controls keep consumption bounded.

Agentic SOC, Autonomous SOC, AI SOC, ISOC: Call it what you want. Just don’t call it a roadmap item.

What we are delivering today is real, accessible and, for the next couple of months, complimentary. It is the agentic SOC in operation. GA, now. Critical alerts automatically investigated. Verdicts autonomously reached. Workflows automatically triggered. Governed authorization. Responses that execute within the policies your team controls and human-in-the-loop gates that your team decides.

The industry has called this many things: The Autonomous SOC, the Agentic SOC, the AI SOC. Gartner now has a name for this model: the Integrated Security Operations Center. Modern threat detection, investigation, and response as a single, continuous, AI-driven loop vs. the historic siloed functions and tool sprawl. More than solving alert fatigue, the new model has the potential to solve the investigation capacity gap and shrink MTTR to a scale and speed that cybersecurity will require in the frontier AI era. At SentinelOne, we have been building for this moment for years.

Investigation capacity should never again be the reason a critical alert goes unexamined. Frontier AI belongs where the data and the analysts already are: In the console, in the workflow, governed by the human customer. We put it there.

Activate Purple AI Agentic Investigation in your Singularity console or visit s1.ai/agentic.

Why Most AI SOC Deployments Stall. How the Fastest Teams Don't.
Join the webinar on Wednesday, June 24, 2026 at 10:00AM PT/ 1:00PM ET.


from SentinelOne https://ift.tt/hxTP2be
via IFTTT

Adversarial Exposure Validation Turns Security Visibility into Confident Prioritization

For security teams, the findings never stop, but confidence in knowing which ones matter is becoming harder to maintain.

The problem is no longer visibility. It's validation. Security teams must decide which findings warrant action while operating under constant pressure and incomplete information. Increasingly, the challenge is not discovering potential risks. It is determining which risks deserve attention first.

Visibility Got Us Here. Validation Moves Us Forward.

The security industry has spent the better part of a decade improving visibility. Vulnerability scanners, cloud security posture tools, endpoint detection, attack surface platforms, code analysis, and threat intelligence feeds all contribute to a more complete understanding of the attack surface. The investment has been enormous, and it has largely worked. Modern enterprises can see their environments in ways that would have seemed remarkable ten years ago.

Yet improved visibility has not automatically translated into improved outcomes. The 2025 Verizon Data Breach Investigations Report highlights a persistent reality: exploitation of vulnerabilities is a leading initial access vector, while remediation timelines are often measured in days, weeks, or even years. Organizations are discovering more, but they are also being asked to evaluate and prioritize more.

Whether findings originate from automated tools, attack surface monitoring, or penetration testing services, security teams still face the same question: Which risks deserve attention first? That evolution has created a new challenge. Success increasingly depends on how quickly teams can determine which findings represent meaningful risk.

From Detection to Decision

Every new finding competes with every existing finding for a finite pool of attention, resources, and remediation capacity. In many cases, security teams have more visibility than ever before. The challenge is understanding which findings represent meaningful, exploitable risk and which ones can be addressed over time. 

Those are two very different exercises. One is a detection problem. The other is a validation problem.

Organizations that excel at prioritization are not necessarily the ones with the fewest vulnerabilities. They are the ones who can consistently distinguish between theoretical exposure and practical risk. That ability allows them to focus resources where they will have the greatest impact.

When every finding is presented as urgent, prioritization becomes more difficult. Teams often find themselves balancing competing demands while trying to determine where action will make the biggest difference. The result is a lack of context.

Context Is What Converts a Vulnerability into a Decision

A vulnerability on its own provides only part of the picture. Security teams need to understand whether it is reachable, whether it can realistically be exploited, what systems sit downstream, and what business processes could be affected. The answers to those questions determine whether a finding represents a routine issue or a priority that demands immediate attention.

The organizations making the greatest progress in risk reduction are not necessarily collecting more data, but rather, they are building better ways to interpret it by creating workflows that connect technical findings to operational and business impact. This allows teams to make decisions with greater speed and confidence.

Adversarial Exposure Validation Turns Context into Confidence

This need for context is one reason Adversarial Exposure Validation (AEV) gained momentum within modern security programs. As a core component of Continuous Threat Exposure Management (CTEM), AEV moves beyond identifying potential weaknesses and focuses on validating which exposures represent realistic risk.

Unlike traditional assessment approaches that primarily surface findings, AEV evaluates how an attacker could interact with an environment. It uses adversary simulation to test security controls, attack paths, and response readiness while selectively incorporating adversary emulation techniques when deeper validation is required.

The objective is not to generate more alerts. It is to determine which exposures are actually reachable, exploitable, and consequential in the context of the organization's environment.

Security teams do not need additional evidence that vulnerabilities exist. They need confidence in understanding which vulnerabilities create meaningful business risk. By validating exposures through realistic attack scenarios, AEV helps transform findings into actionable priorities, enabling organizations to focus remediation efforts where they matter most.

Where AI Fits, and Where It Doesn’t

This is also where the conversation about AI belongs.

Automation provides tremendous value in discovery, scale, and signal processing across environments that are far too large for manual review alone. It can help organizations identify patterns, surface potential exposures, and accelerate analysis.

What it cannot do on its own is solve a judgment problem.

The questions that matter most in security prioritization require an understanding of business context, risk tolerance, operational dependencies, and adversary behavior. Those inputs extend beyond what scanners and algorithms can observe. They require human expertise, organizational knowledge, and informed decision-making from experienced offensive security experts.

AI can accelerate security operations, but confidence still comes from human accountability.

The Shift from Visibility to Validation Is Already Happening

Many mature security programs have already begun making this shift.

Conversations across the CISO community increasingly focus on exploitability, attack paths, and demonstrated exposure rather than raw finding counts. The goal is not simply to discover vulnerabilities. It is to understand which vulnerabilities create meaningful risk and require action.

That shift is as much about culture and process as it is about technology. Organizations leading the way have built workflows that ensure context accompanies findings before decisions are made. They have defined what exploitable means within their own environments. They have connected technical risk to business impact in language that resonates across leadership teams.

None of that requires a specific tool. It requires a different way of thinking about what security programs are designed to achieve.

Confidence Is a Security Capability Worth Building

The next phase of security maturity will not belong to organizations that discover the most vulnerabilities. For most enterprises, visibility is already well established.

What will distinguish leading security programs is their ability to turn visibility into confident action quickly, consistently, and at a pace that keeps up with an evolving threat landscape.

Confidence is not a soft concept. It is an operational capability. It enables teams to prioritize effectively, communicate risk clearly, and invest resources where they can reduce the most exposure.

In an era defined by AI, automation, and an ever-expanding volume of findings, confidence may be one of the most important security capabilities that humans can bring.

About BreachLock

BreachLock is a global leader in offensive security, delivering scalable and continuous security testing. Trusted by global enterprises, BreachLock provides human-led and AI-powered attack surface management, penetration testing, red teaming, and adversarial exposure validation (AEV) services that help security teams stay ahead of adversaries. With a mission to make proactive security the new standard, BreachLock is shaping the future of cybersecurity through automation, data-driven intelligence, and expert-driven execution.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.



from The Hacker News https://ift.tt/hA7aKpt
via IFTTT

The Top 10 Attack Surface Exposures in 2026

Breaches don't always start with a zero-day. An exposed admin panel can get brute-forced, or credentials reused from a previous attack. But when a vulnerability does drop — like MongoBleed earlier this year, which let attackers pull credentials and session tokens from server memory without authentication — anything internet-facing is immediately at risk.

With time-to-exploit now down to a single day, the question isn't just how fast you can patch. It's why the service was exposed in the first place.

The team at Intruder analyzed 3,000 attack surfaces to find out how much of a typical organization's attack surface consists of services that have no reason to be there. We grouped what we found into four categories — HTTP panels, risky ports and services, databases, and publicly accessible files and information.

The full findings, including breakdowns by company size and industry, are in our 2026 Attack Surface Management Index.

How widespread is the problem?

  • 60% of organizations had at least one HTTP panel exposed — admin consoles, management UIs, login pages for internal tools that have no business being publicly reachable.
  • Nearly half (49%) had a risky port or service exposed.
  • 42% had a database reachable directly from the internet. 
  • 30% had files or information publicly accessible that shouldn't be — API documentation, config files, data that was never intended to be discoverable.

The ten most common exposures

These are the most common attack surface exposures affecting organizations in the past 12 months.

  1. MySQL Database Exposed — 26%
  2. Postgres Database Exposed — 16%
  3. API Documentation Exposed — 15%
  4. WordPress Admin Panel Exposed — 15%
  5. Remote Desktop Service Exposed — 11%
  6. SNMP Service Exposed — 9%
  7. phpMyAdmin Admin Panel Exposed — 8%
  8. UPnP Service Exposed — 8%
  9. NTP Service Exposed — 7%
  10. RPC Portmapper Service Exposed — 7%

Databases dominate the top two spots

Exposed databases take the top two spots, with more than a quarter of organizations exposing MySQL and Postgres, affecting 1 in 6. Internet-facing databases have long been a target for opportunistic attackers. The PLEASE_READ_ME ransomware campaign in 2020 compromised more than 250,000 MySQL databases by brute-forcing weak credentials. MongoDB and Elasticsearch have faced the same.

API documentation is more exposed than RDP

API documentation ranked third — ahead of RDP, which surprised us. Some API docs are intentionally public, but organizations frequently overlook documentation tied to private or admin-side APIs that were never meant to be discoverable. Public API docs can turn otherwise hard-to-find vulnerabilities into documented attack paths.

RDP remains a ransomware entry point

RDP at number five is a concern given its history as an initial access vector in ransomware attacks. BlueKeep in 2019 left nearly a million systems immediately exploitable. Credential guessing against exposed RDP remains one of the most reliable ways ransomware operators get in.

The rest of the list was never meant to be internet-facing

The remainder of the list — SNMP, UPnP, NTP, RPC — are legacy services designed for internal networks that were never meant to be internet-facing. 

Get the full findings

Most teams treat patching as the priority. But for a lot of what's on this list — databases, admin panels, legacy services — the better question is why they're reachable at all. That's where attack surface reduction comes in — and for most organizations, it's not getting the same attention as vulnerability management.

The full findings, including breakdowns by company size and industry, are in the 2026 Attack Surface Management Index.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.



from The Hacker News https://ift.tt/LUhi6KO
via IFTTT

Malicious JetBrains Plugins Steal AI API Keys as Chrome Extensions Capture Chatbot Chats

Cybersecurity researchers have flagged a "coordinated malware campaign" on the JetBrains Marketplace that has published no less than 15 malicious plugins capable of exfiltrating artificial intelligence (AI) provider keys.

"Every plugin poses as an AI coding assistant built on DeepSeek and other large language models, offering chat, commit messages, code review, bug finding, and unit tests," Aikido Security researcher Ilyas Makari said. "They function exactly as advertised. However, the AI provider API key you enter gets exfiltrated to a server controlled by the attacker."

The activity is said to have been ongoing since the end of October 2025, with new plugins released as recently as June 10, 2026. Two of the plugins, CodeGPT AI Assistant and DeepSeek AI Assist, have more than 25,000 downloads each, although it's not clear if the counts are authentic or if they have been inflated to fake their popularity.

The complete list of plugins is below -

  • DeepSeek Junit Test (org.sm.yms.toolkit)
  • DeepSeek Git Commit (com.json.simple.kit)
  • DeepSeek FindBugs (org.bug.find.tools)
  • DeepSeek AI Chat (org.translate.ai.simple)
  • DeepSeek Dev AI (com.yy.test.ai.simple)
  • DeepSeek AI Coding (com.dev.ai.toolkit)
  • AI FindBugs (com.json.view.simple)
  • AI Git Commitor (com.my.git.ai.kit)
  • AI Coder Review (org.check.ai.ds)
  • DeepSeek Coder AI (com.review.tool.code)
  • AI Coder Assistant (org.code.assist.dev.tool)
  • DeepSeek Code Review (com.coder.ai.dpt)
  • CodeGPT AI Assistant (com.my.code.tools)
  • DeepSeek AI Assist (ord.cp.code.ai.kit)
  • Coding Simple Tool (com.dp.git.ai.tool)

Aikido Security said all 15 plugins share a similar codebase, requiring users to open the settings panel and enter an API key for an AI like OpenAI, SiliconFlow, or DeepSeek in order to carry out the promised functionality.

While the plugins work as they are intended to, they have been found to sneak in the ability to covertly siphon the provided API key to a remote server ("39.107.60[.]51") under the attacker's control over an HTTP request in plaintext format.

"The plugins also run a paid tier," the company said. "After a user pays a small fee through the donation wall built into the plugin, the server sends an API key back down to the client, and the plugin starts using that key for its model calls instead of your own, which is bizarre, since no legitimate operator would simply hand a user a working and unrestricted key to a paid AI provider."

This has raised the possibility that the operators behind the campaign are likely sharing the stolen AI provider API keys with other threat actors as part of an illicit monetization scheme, effectively turning it into a service that grants paying users access to the victim's AI provider.

"The operator collects money on one side and free credentials on the other, while the genuine key owners pay the bill," Makari added.

The campaign is further evidence of how threat actors are increasingly targeting developer environments through the open-source ecosystem, which has become a lucrative target owing to the fact that they host source code, cloud credentials, signing keys, and API keys for paid AI services that can be resold for LLMjacking schemes.

"Treat a plugin the same way you would treat any dependency that runs with your privileges, and be cautious about pasting long-lived secrets into tools you have not vetted," Aikido Security said.

Malicious Chrome Extensions Steal AI Conversations

The development coincides with the discovery of two Google Chrome ad blocker extensions that have been caught capturing users' conversations with AI chatbots like OpenAI ChatGPT, Anthropic Claude, Google Gemini, Microsoft Copilot, Perplexity, DeepSeek, xAI Grok, and Meta AI. The data collection operation has been codenamed PromptSnatcher by researcher Jean-Marie R.

The names of the extensions, which are still available on the Chrome Web Store, are as follows -

  • Smart Adblocker (ID: iojpcjjdfhlcbgjnpngcmaojmlokmeii) - 90,000 users (Published in October 2022)
  • Adblock for Browser (ID: jcbjcocinigpbgfpnhlpagidbmlngnnn) - 10,000 users (Published in August 2023)

"While presented as ad blockers, the extensions ship a custom-built interception engine that records non-public conversations, model usage, and account-tier metadata from every major AI platform (ChatGPT, Claude, Gemini, and others)," the researcher said. "The operation uses legitimate public filter lists (EasyList, IDCAC) as functional cover, providing genuine ad-blocking utility while running an undisclosed telemetry channel."

The fact that the two extensions have been around for several years indicates that the AI-related updates were introduced in the form of software updates.

These efforts are part of an attack technique called Prompt Poaching. Over the past several months, browser extensions, both legitimate and malicious, have been observed adopting this method to stealthily capture AI chats. What's unclear is whether these practices violate Google's policies for browser extensions.

"The extensions intercept full AI conversation history, model usage, and subscription tier from eight platforms, and transmit this data to operator-controlled infrastructure without notification to the user beyond a generic 'Enhanced Protection' consent string," the researcher noted.



from The Hacker News https://ift.tt/pdDuPoa
via IFTTT