How a Single Wrong Return Value Opens the Door to Root

The macOS Screen Sharing service (screensharingd) implements the Secure Remote Password (SRP) protocol to authenticate remote users before granting desktop access over the Remote Framebuffer (RFB) protocol on TCP port 5900. Researchers at Huntress describe the root cause with striking precision: “a single wrong return” in the daemon’s state-machine validation — the frame-length validator erroneously returns a stale success status after a crafted packet sequence, causing screensharingd to treat the connection as fully authenticated when it is not. Sessions subsequently proceed without cryptographic protection, in plaintext.

What makes CVE-2026-65400 especially dangerous is what happens immediately after. The SSFileCopySender helper process spawned by screensharingd inherits the kTCCServiceSystemPolicyAllFiles entitlement — the same Full Disk Access privilege that Apple’s Transparency, Consent, and Control (TCC) framework is supposed to gate behind an explicit user prompt. An unauthenticated attacker therefore bypasses both the authentication layer and TCC in a single exploit, gaining the ability to read any file on the filesystem and write data to privileged paths.

Three companion vulnerabilities were silently patched alongside CVE-2026-65400: CVE-2026-43779 (CVSS 9.8), which introduces a logic flaw enabling process-level network interception; CVE-2026-43760 (CVSS 8.6), a confused-deputy condition enabling post-authentication file access escalation; and CVE-2026-43777 (CVSS 7.5), a remote denial-of-service condition. Apple’s 6 August security release was larger than the headline CVE suggested.

The Anatomy of an Active Attack: From Port Scan to Monero Miner

The Dutch National Cyber Security Centre (NCSC-NL) disclosed active exploitation on 12 August 2026 after investigating several compromised macOS systems. Forensic reconstruction shows a methodical, low-noise attack chain:

1. Reconnaissance: Mass-scan for TCP/5900 on the public internet. Censys data at the time of disclosure identified approximately 40,000 macOS hosts with Screen Sharing directly internet-facing — roughly half in the United States, with the remainder spanning academic institutions, cloud-hosted Mac infrastructure, and commercial entities globally.
2. Authentication bypass: The attacker sends a crafted SRP packet sequence, triggering the frame-length validation bug. The daemon transitions to an authenticated session state without any cryptographic exchange.
3. Persistence establishment: Using the RFB session, the attacker transfers an SSH public key and setup scripts to the device, establishes SSH-based re-entry for persistence, then clears shell history and system logs to impede forensic investigation.
4. TCC and firewall evasion: Packet Filter rules are modified to suppress outbound traffic alerts. The inherited kTCCServiceSystemPolicyAllFiles entitlement is abused to write files to protected system directories.
5. Cryptomining payload: XMRig 6.26.0 is deployed as a hidden binary at ~/.config/sysmond, masquerading as com.apple.airportd — a legitimate Apple process name unlikely to trigger manual review. A KeepAlive LaunchDaemon plist ensures the miner auto-restarts on reboot. Monero (XMR) was chosen deliberately: its CryptoNight algorithm is optimised for general-purpose CPUs, making stolen Mac compute cycles directly monetisable without specialised hardware. As Bitdefender noted, Monero does not depend on ASICs — any compromised Mac contributes meaningfully to a mining pool.

The attack leaves no ransom note, no defaced files, no obvious indicator of compromise for non-technical users. Victims typically discover it through anomalous CPU load, unexpected electricity bills, or EDR alerts — often days or weeks after initial compromise.

CISA’s Unusually Swift Re-Rating and the KEV Clock

Apple’s initial advisory assigned CVE-2026-65400 a CVSS base score of 7.1. Following the NCSC-NL disclosure and confirmation of exploitation across multiple targets, CISA intervened on 14 August 2026 to rescore the vulnerability to 9.8 Critical — a two-point jump reflecting the network-accessible, no-credential-required attack vector. On 18 August 2026, CISA formally added CVE-2026-65400 to the Known Exploited Vulnerabilities (KEV) catalogue, mandating remediation by 21 August for all US federal civilian agencies.

While the KEV deadline is binding only on federal agencies, the real-world signal is clear: exploitation is happening at scale, the flaw is trivially weaponisable, and the patch has been available for nearly three weeks as of this writing. Any organisation still running an unpatched, internet-exposed Screen Sharing host is operating a documented, publicly-known root-access backdoor.

Why Indian Enterprises Face Elevated Risk

Apple Silicon adoption in Indian IT, design, media production, and financial services has accelerated sharply since 2023. Many Indian enterprises now operate mixed Windows-macOS fleets — often without macOS-specific endpoint detection or MDM policies that enforce OS-level patch compliance. Screen Sharing is routinely enabled for internal IT helpdesk workflows and remote work arrangements, and in environments without rigorous network segmentation, TCP/5900 may be inadvertently reachable from beyond its intended scope.

The risk compounds significantly for Indian software firms and managed service providers running cloud-hosted Mac infrastructure for iOS/macOS CI/CD pipelines. These machines commonly have Screen Sharing enabled for administrative access, and port-5900 exposure is widespread. A compromised build server is not merely a crypto-miner — it is a launchpad into your software supply chain, a threat vector explored in depth after the RUSTSEC-2026-0260 Rust crate supply-chain attack earlier this month.

This vulnerability also reinforces a broader architectural lesson: trusting OS-level authentication as a network perimeter is not a security strategy. As seen with APT29’s WhatsApp MFA bypass and now this Screen Sharing flaw, when the authentication mechanism itself is the vulnerability, strong passwords and MFA tokens offer no protection. Only network-level zero-trust segmentation — where no endpoint is inherently trusted based on its location — provides resilient defence.

What You Should Do Right Now

Sanjay Seth’s recommended response, structured for Indian IT and security teams managing multi-platform environments:

Detection Signatures for Your Security Stack

Add the following indicators to your EDR and SIEM detection rules:

• Endpoint Security event: ES_EVENT_TYPE_NOTIFY_SCREENSHARING_ATTACH with session_username: root
• Process creation: SSFileCopySender launched with arguments 0 80
• File creation: ~/.config/sysmond executable; any com.apple.airportd-named plist in /Library/LaunchDaemons/
• Outbound network: connections to known Monero pool endpoints (e.g., pool.supportxmr.com:3333, xmrpool.eu:9999)
• Log integrity: truncated or cleared /var/log/system.log correlated with a preceding Screen Sharing session event

Frequently Asked Questions

Am I vulnerable if Screen Sharing is enabled but not exposed to the internet?

Your risk is significantly reduced if TCP/5900 is not accessible from untrusted networks. However, lateral-movement scenarios remain relevant — an attacker who gains initial access to your internal network via another vector (phishing, VPN compromise) can exploit CVE-2026-65400 to escalate to root on any internal Mac with Screen Sharing enabled. Patching remains mandatory; firewall rules provide defence-in-depth, not a substitute for the patch.

Does this affect Apple Silicon (M-series) as well as Intel Macs?

Yes. CVE-2026-65400 resides in the screensharingd daemon, which is architecture-independent. Both Apple Silicon (M1 through M4) and Intel-based Macs running affected macOS versions are equally vulnerable. The exploit does not rely on any processor-specific behaviour.

Is this related to generic VNC vulnerabilities?

No. While macOS Screen Sharing uses the RFB protocol (which VNC also uses), CVE-2026-65400 is a distinct flaw in Apple’s own SRP authentication implementation within screensharingd — not a generic VNC bug. Third-party VNC servers such as RealVNC are unaffected by this specific CVE.

What if we cannot patch immediately — are there effective workarounds?

The most effective interim mitigations are: (1) disable Screen Sharing entirely via System Settings → General → Sharing; and (2) block inbound TCP/5900 at your perimeter and host-based firewall. If Screen Sharing is operationally essential, restrict it to a dedicated management VLAN and mandate VPN authentication before any session. These are workarounds, not fixes — apply the Apple security update at the earliest possible opportunity.

CVE-2026-65400 is a blunt reminder that convenience features become attack surfaces the moment they face an untrusted network. Apple’s Screen Sharing has been a trusted IT tool for years — one wrong return value in a state machine has turned it into an unauthenticated root-access gateway. The patch has existed since 6 August; active exploitation was confirmed on 12 August; CISA flagged it as Critical on 14 August. Every day without the patch is a day this door stays open.

If your organisation operates macOS endpoints and you are uncertain about your exposure, attack surface, or zero-trust network readiness, contact Sanjay Seth for a security assessment. Whether auditing your Apple fleet, reviewing FortiGate firewall policies, or designing a zero-trust architecture that treats every endpoint as untrusted — the team helps Delhi NCR businesses and enterprises across India close these gaps before attackers find them.

The post CVE-2026-65400 (CVSS 9.8): Attackers Are Silently Rooting Macs via Screen Sharing — 40,000 Hosts Exposed, Monero Miners Deployed appeared first on Sanjay Seth — Cybersecurity & Network Consultant.

For CISOs, NOC leads, and IT security teams in India and the APAC region, this advisory carries a sharper edge than most: Gunra’s preferred front door is a pair of authentication-bypass vulnerabilities in Fortinet FortiOS and FortiProxy — the very infrastructure that underpins perimeter security across tens of thousands of Indian enterprises, government networks, and critical-infrastructure operators.

What Is Gunra Ransomware and Where Did It Come From?

Gunra first surfaced in April 2025, emerging from the same reservoir of leaked Conti source code that has spawned an entire generation of capable ransomware variants. Within a year, its operators had industrialised the operation: in January 2026, Gunra launched a formal RaaS affiliate programme on dark-web forums, complete with a browser-based management panel, a configurable ransomware builder producing cross-platform payloads, and structured documentation designed to onboard affiliates efficiently.

The group has also operated under the alias Golden Community. Notably, the advisory states that Gunra actors have actively recruited penetration testers and ethical hackers as initial-access brokers — a deliberate strategy that dramatically raises the sophistication floor across their affiliate pool and makes attribution more complex.

Technical Breakdown: How Gunra Breaks In and Burns Down

Gunra’s attack chain is methodical and brutally efficient. Understanding each stage is essential for building effective detections and controls.

Stage 1 — Initial Access via FortiOS and FortiProxy Exploits

The advisory confirms that CVE-2024-55591 and CVE-2025-24472 are the primary intrusion vehicles. Both flaws allow an unauthenticated remote attacker to obtain super-administrator privileges on the targeted appliance — effectively handing over the keys to the perimeter.

CISA added CVE-2024-55591 to its Known Exploited Vulnerabilities (KEV) catalog with a January 2025 remediation deadline for U.S. federal agencies. Organisations still running the affected versions in August 2026 — over 18 months past that deadline — are operating on borrowed time. Beyond these CVEs, Gunra actors also exploit SSL-VPN appliances with default credentials and probe for any exposed management interface, making baseline hardening as important as patching.

Stage 2 — Credential Harvesting and Lateral Movement

Once inside, operators deploy Impacket tools — specifically psexec.py, smbclient.py, and secretsdump.py — to dump credentials from domain controllers and Active Directory NTDS databases. Stolen credentials and session cookies enable session hijacking of legitimate user accounts. MFA is actively bypassed by manipulating OTP flows on VDI portals, and SMB provides the lateral-movement highway between systems. The combination is fast and hard to stop once it is in motion.

Stage 3 — Cloud-Based Exfiltration to MEGA

Gunra operators deploy a custom executable — main.exe — that systematically collects data from OneDrive and SharePoint repositories, compresses it into archives, and uploads everything to MEGA. This cloud-based exfiltration route is particularly problematic because MEGA is a legitimate file-sharing service, making it difficult to block without disrupting legitimate business use.

Stage 4 — Encryption, Backup Destruction, and Double Extortion

Backup infrastructure is deleted both before and after encryption to eliminate recovery options. The payload uses stream ciphers (Salsa20 or ChaCha20) engineered for speed — the advisory notes the capability to encrypt 9 TB of data in a limited timeframe. Victims receive a ransom note with a 5–7 day payment window before stolen data appears on the group’s dark-web leak site. Ransom demands have exceeded USD $10 million in the majority of documented cases.

Critical advisory for Linux administrators: A March 2026 analysis uncovered a catastrophic cryptographic weakness in Gunra’s Linux variant. The encryption seed is derived from system time at the point of encryption — time-seeded randomisation — which makes the encryption mathematically reversible without paying the ransom. Linux victims should not pay; engage a specialised incident-response firm to leverage this weakness immediately.

Who Is Being Targeted — and Why India Should Be on High Alert

The advisory identifies a broad set of high-value sectors: healthcare and public health (hospitals, diagnostic chains, pharma manufacturers), financial services and insurance, government services, critical manufacturing and construction, transportation and logistics, utilities (power, water, telecom), as well as academia, media, retail, and professional services.

Among the 51 confirmed victims, South Korea, Brazil, Spain, Thailand, and Hong Kong appear with the highest frequency. The advisory explicitly covers the Asia-Pacific region — and India, with its enormous installed base of internet-facing FortiGate appliances securing enterprise, BFSI, and government networks, sits squarely within the blast radius of this campaign. As I covered in my earlier analysis of The Gentlemen ransomware, CVE-2024-55591 is already being weaponised by multiple independent threat actors simultaneously — Gunra is simply the largest and most operationally mature of them to date.

What You Should Do Right Now: Actionable Defence from Sanjay Seth

As a zero-trust architect and FortiGate specialist who has spent three decades hardening enterprise perimeters across India and the APAC region, here are concrete, prioritised actions — not generic advice.

1. Patch immediately and verify. If your FortiOS is on any version between 7.0.0 and 7.0.16, or FortiProxy between 7.0.0–7.0.19 or 7.2.0–7.2.12, you are vulnerable right now. Upgrade today. Refer to the Fortinet PSIRT advisory portal for the current patch matrix. After patching, verify the running version — do not assume the patch completed successfully without confirmation.
2. Disable management access from the internet. CVE-2024-55591 targets the management interface via the Node.js websocket module. If your FortiGate HTTPS management port is reachable from the public internet, lock it down to a dedicated management VLAN with strict source-IP ACLs — today, not during next month’s change window.
3. Audit and rotate all credentials immediately. Gunra actors use secretsdump.py against NTDS databases at scale. Assume that any domain administrator credential stored on or accessible from a Fortinet appliance may be compromised. Rotate service accounts, enforce a minimum password length of 20 characters for privileged accounts, and implement Privileged Access Workstations (PAWs) for all administrative sessions.
4. Enforce phishing-resistant MFA across all privileged access. Gunra explicitly bypasses time-based OTP on VDI portals. Move to FIDO2 or passkey-based MFA for all privileged accounts. Explore zero-trust reference architectures available on this site — FortiGate’s ZTNA capabilities provide an additional enforcement layer beyond traditional VPN.
5. Block MEGA and similar cloud exfiltration services. Unless your organisation has a documented business need for MEGA, block it at the perimeter firewall and proxy. Additionally, configure DLP rules to flag large outbound transfers to any cloud storage endpoint and alert your SOC team in real time.
6. Harden backup infrastructure with immutability. Gunra deletes backups before and after encryption. Apply the 3-2-1-1-0 backup rule: three copies, two different media types, one off-site, one air-gapped or immutable, zero unverified restores. Test your RTO and RPO quarterly under realistic ransomware-recovery conditions.
7. Deploy Impacket and lateral-movement detections in your SIEM. Push detection rules for psexec.py, smbclient.py, and secretsdump.py artefacts. Gunra’s TTPs are fully mapped to MITRE ATT&CK. Your SOC should be hunting for these proactively — reactive detection after encryption is too late. Refer to the Infosecurity Magazine analysis for detailed IOC references.

Frequently Asked Questions

Is Gunra the same as the Gentlemen ransomware that also exploited FortiGate CVEs?

No — Gunra and The Gentlemen are distinct and unrelated threat actors that independently weaponise the same FortiOS and FortiProxy vulnerabilities. The fact that multiple unrelated groups are actively exploiting these flaws simultaneously is precisely what makes patch priority so urgent for any deployment running affected versions.

Does Gunra only affect FortiOS 7.0.x, or are other versions at risk?

The advisory specifically identifies FortiOS 7.0.0–7.0.16 and the corresponding FortiProxy version ranges as vulnerable to CVE-2024-55591 and CVE-2025-24472. Other versions are not listed as affected by these specific CVEs. However, Gunra operators also target SSL-VPN appliances using default credentials and exposed management interfaces — attack vectors that are version-agnostic. A full hardening review is warranted regardless of FortiOS version.

If our Linux servers were hit by Gunra, should we pay the ransom?

Definitively no. Security researchers identified a fundamental flaw in Gunra’s Linux payload: the encryption key is seeded from system time at the point of encryption, making it mathematically reversible. Engage a specialised incident-response firm that can exploit this weakness to recover your data. Paying the ransom is unnecessary, and paying also funds further attacks on other organisations.

How do we determine if we have already been compromised?

Indicators to hunt for include: unexpected FortiOS management-interface authentication events from IPs outside your approved management range; Impacket tool artefacts (psexec.py, secretsdump.py) in Windows Security and System event logs; large or unexpected outbound transfers to MEGA.nz; deletion of VSS shadow copies or backup catalogue files; and anomalous SMB lateral-movement patterns between servers outside of normal business hours. If you observe any of these, escalate to your incident-response team immediately and do not attempt to patch live in a potentially compromised environment.

Secure Your Organisation Before the Next Victim Is Named

Advisory AA26-222A represents the most credible level of warning available short of an active incident on your own network. Six agencies do not jointly publish an advisory for a marginal or theoretical threat. Gunra is real, operationally mature, actively recruiting, and specifically targets the Fortinet infrastructure that protects your organisation.

Whether you need a rapid FortiGate patch-status and configuration audit, a zero-trust architecture review for your NOC and SOC, a ransomware tabletop exercise for your leadership team, or a full incident-response retainer, I am here to help — and the conversation starts with a single message. Request your no-obligation security assessment today — before Gunra finds your organisation first.

The post Gunra RaaS: Six Intelligence Agencies Issue Emergency Alert as Conti’s Heir Exploits FortiGate Vulnerabilities — 51 Victims, $10M+ Ransom Demands appeared first on Sanjay Seth — Cybersecurity & Network Consultant.

Welcome to the post-passkey era. In the past fortnight, three independent research teams and one criminal marketplace have shattered the comfortable myth that passkeys are inherently phishing-resistant. The identity security assumptions you built your zero-trust architecture on need an urgent audit.

Three Research Bombs and One Criminal Marketplace

August 2026 will be remembered as the month that brought passkey security back to earth. The convergence started at Black Hat USA 2026 (August 5), where SpecterOps presented Pass-the-Passkey, demonstrating how Windows Event Logging stored WebAuthn assertion signatures from hardware security keys in readable plaintext. Within days, Unit 42 published its Golden Pass-ta-Key research targeting Google Password Manager’s synced credential infrastructure. Researcher Dirk-jan Mollema added a third vector exploiting Windows Hello in already-compromised sessions.

Then, on August 20, 2026, Abnormal Security found something chilling on a criminal forum: iAuthFlow v2, a polished, commercially sold phishing toolkit specifically engineered to weaponise the passkey enrollment process itself — no CVE required.

How iAuthFlow v2 Works: A Six-Second Backdoor

iAuthFlow v2 operates through a four-stage browser-in-the-middle (BitM) architecture that exploits the passkey enrollment flow rather than any cryptographic weakness:

1. Phishing Relay: The victim receives a unique link to a fake Google (or Microsoft, iCloud, LinkedIn) sign-in page hosted via Cloudflare Tunnels. The page is indistinguishable from the legitimate login experience; it proxies every interaction in real time to an attacker-controlled remote browser.
2. Session Hijack: Once the victim completes authentication — including any MFA challenge — the attacker’s server-side browser obtains authenticated SID/SSID session cookies with full account access.
3. Stealth Passkey Enrollment: While displaying a “Verification, Processing…” hold screen to the victim, iAuthFlow v2 uses the authenticated session to silently register an attacker-controlled WebAuthn credential. The entire enrollment takes approximately 6 seconds. A software-based virtual authenticator retains the credential’s private key on the attacker’s infrastructure.
4. Persistent Re-entry: When the victim notices suspicious activity, changes their password, and revokes all active sessions — the standard incident-response playbook — the attacker simply authenticates again using their enrolled passkey. Password resets do not remove attacker-enrolled passkeys.

The toolkit is priced at $10,000 for the base package, with additional modules sold separately for Microsoft, iCloud, and LinkedIn targets. It was discovered listed on Russian-language cybercrime forums by Abnormal Security researchers, who analysed seller demonstrations rather than executing the malware itself.

Detection fingerprints published by Abnormal Security include a Shodan MMH3 favicon hash of 1987889572, a stylesheet SHA-256 of 9dd237a185b6c2ff26a10cb9d1f670a59c1a0b4b, and session cookies using access_key=<32 hex characters>. These indicators should be immediately loaded into your threat intelligence platforms and SIEM rules.

CVE-2026-34348: When Your YubiKey Becomes the Attacker’s YubiKey

SpecterOps researchers Karl Fosaaen and Ethan Robish discovered that the Windows Event Logging Service was writing WebAuthn assertion signatures — the cryptographic proof produced by a hardware security key like a YubiKey during authentication — to event log files in cleartext. Any low-privilege domain user with read access to those logs could extract a valid, unexpired signature and replay it against Microsoft Entra ID, successfully impersonating a privileged account and bypassing phishing-resistant MFA entirely.

Microsoft patched CVE-2026-34348 in the July 2026 Patch Tuesday cycle — Windows updates now make WebAuthn assertions written to event logs unusable for replay. However, SpecterOps noted as of August 10 that Entra ID itself had not yet received corresponding hardening on challenge validation. If you haven’t applied July 2026 Windows updates across your domain controllers and endpoints, this is a priority-one gap.

The Zero-Trust Blind Spot: Why This Changes the Calculus

Zero-trust architectures rest on a foundational assumption: “verify every access, every time, regardless of network location.” Passkeys became the verification mechanism of choice precisely because they were categorised as phishing-resistant. The discoveries of this month reveal that the verification layer itself can be compromised without breaking cryptography.

Consider what this means for a typical enterprise in India’s BFSI, IT, or pharma sector deploying hybrid Microsoft 365 environments:

• A phishing email targets a finance director. The iAuthFlow v2 page captures credentials AND enrolls a rogue passkey — all while the user thinks they just completed a routine verification.
• The SOC’s next-morning alert fires on the initial credential capture. The analyst resets the password and revokes sessions. Incident closed.
• Six weeks later, the attacker silently re-enters via the enrolled passkey, accesses the SharePoint environment, and begins exfiltrating financial documents — all from a clean authentication event that shows a valid passkey login.

This is not hypothetical. It is the precise persistence mechanism that iAuthFlow v2 is designed and sold to enable. The fact that this attack mirrors APT29’s documented OAuth persistence playbook should concern every CISO — nation-state techniques are now available to any criminal with $10,000.

The Microsoft Entra ID vulnerabilities we have seen exploited this month reinforce a clear pattern: identity infrastructure is the new perimeter, and it is under sustained, sophisticated assault.

What You Should Do Right Now

As a cybersecurity consultant who works with enterprises across Delhi NCR on zero-trust architecture and identity security, my recommendations are specific and sequenced:

1. Apply July 2026 Windows patches immediately. CVE-2026-34348 is patched — but only if your endpoints and domain controllers are current. Run a vulnerability scan today and close this gap before exploitation tooling proliferates.
2. Audit enrolled passkeys and security keys across all user accounts. For Microsoft environments: review Azure AD > Users > Authentication Methods and flag any FIDO2 credentials enrolled from unfamiliar devices or registered outside business hours. For Google Workspace: check Admin Console > Users > Security > 2-Step Verification and revoke unrecognised passkeys.
3. Hunt for iAuthFlow v2 infrastructure. Load the Shodan favicon hash (1987889572) and the stylesheet SHA-256 into your threat intelligence feeds. Block the session cookie pattern access_key=<32hex> at your web proxy. Flag unusual Cloudflare Tunnel domains in DNS logs.
4. Treat passkey enrollment as a high-risk event requiring approval. Implement manager-approval workflows or step-up authentication (including a separate hardware token) before any new passkey or FIDO2 credential can be registered on privileged accounts.
5. Implement Continuous Access Evaluation (CAE) for Microsoft 365. CAE enforces near-real-time session revocation and can significantly reduce the persistence window of compromised passkey sessions.
6. Require device attestation in WebAuthn policies. Platform authenticators (Touch ID, Windows Hello) tied to hardware TPMs are dramatically harder to spoof than software-based virtual authenticators like those used by iAuthFlow v2. Enforce attestation verification in your WebAuthn Relying Party configuration.
7. Brief your SOC on the updated incident-response checklist. When a phishing incident is detected: password reset + session revocation is no longer sufficient. Add a mandatory step: enumerate and revoke ALL passkeys and FIDO2 credentials on the compromised account. Document this in your IR playbooks today.

For organisations using Google Workspace: enable the “Only security key” restriction in 2-Step Verification settings and consider enrolling high-risk users in the Advanced Protection Program, which restricts which applications can access account data and adds friction to new device/key enrollment.

Frequently Asked Questions

Does this mean passkeys are broken and we should stop using them?

No — passkeys remain far superior to passwords and SMS-based OTP, which are trivially phishable. The vulnerabilities uncovered this month exploit implementation flaws in surrounding systems (event logging, sync mechanisms, enrollment controls) rather than the underlying WebAuthn/FIDO2 cryptography. The answer is hardened passkey deployment with proper enrollment controls, attestation enforcement, and proactive credential auditing — not abandonment.

Are FIDO2 hardware security keys (YubiKey, Titan) still the gold standard?

Hardware security keys remain the strongest available authenticator for high-privilege accounts, but CVE-2026-34348 demonstrates that the surrounding OS infrastructure can undermine them if not patched. Apply July 2026 Windows updates, enforce hardware attestation, and treat signature logging as a security-sensitive data plane requiring protection equivalent to credential storage.

How does iAuthFlow v2 get around Google’s or Microsoft’s device-binding protections?

iAuthFlow v2 exploits a window during active, authenticated sessions — before any device-binding verification is anchored. It uses a software-based virtual authenticator (leveraging Chromium’s WebAuthn API) to enroll a credential that is technically valid under the platform’s enrollment policy. The platform authenticates the session, not the physical device, at enrollment time. This is why enforcement of hardware attestation at the Relying Party level is the critical control — it would reject a software-based virtual authenticator credential at enrollment.

How should India-based enterprises using Microsoft 365 and hybrid Active Directory respond specifically?

Prioritise three actions: (1) apply July 2026 Windows patches to all AD CS and domain controller infrastructure — CVE-2026-34348 is especially dangerous in environments with on-premises AD federated to Entra ID; (2) enable Phishing-Resistant MFA policy in Entra Conditional Access and set it to require hardware attestation for all FIDO2 credentials; (3) run the Entra ID Sign-In Logs query for passkey-based authentications over the past 90 days and validate each enrolled credential against your authorised device inventory. If you find unrecognised entries, assume compromise and escalate.

The identity layer is your new perimeter. Three Black Hat presentations and one criminal marketplace listing in a single week prove that attackers are obsessively focused on breaking the “phishing-resistant” label — and succeeding through implementation gaps rather than mathematical breaks. Your passkey deployment is only as secure as the enrollment controls, patch cadence, and incident-response procedures around it.

If you are unsure whether your organisation’s identity security posture is ready for this threat landscape, let’s talk. Sanjay Seth and the P J Networks team specialise in zero-trust architecture design, identity security reviews, and SOC advisory for enterprises across India. Request a security assessment →

The post iAuthFlow v2 & Pass-the-Passkey (CVE-2026-34348): The $10,000 Attack Turning Your Passkeys Against You appeared first on Sanjay Seth — Cybersecurity & Network Consultant.

The Ghost Login: How Russia’s Spies Walk Through Your MFA

Traditional credential theft is a blunt instrument: phish the password, crack the hash, buy it on a dark-web market. Multi-factor authentication was supposed to render that playbook obsolete. Russia’s APT29 — operating today under Google’s designation ICE RELIC — has spent the last fourteen months engineering a more surgical approach: make the victim hand over authenticated access using only legitimate authentication flows.

On 21 August 2026, Google’s Threat Intelligence Group (GTIG) published a detailed breakdown of three distinct sub-clusters executing this strategy at scale. The report is chilling not because of exotic zero-day exploits, but because of the mundane legitimacy of every step the victim sees. From a user’s perspective, they clicked a real Google login page and entered real credentials. From an attacker’s perspective, the resulting OAuth token is as valid as one produced by the account owner — because it was.

Three Clusters, One Russian Hand

GTIG tracks the activity across three operationally distinct but tactically overlapping clusters:

All three are assessed with high confidence to have a Russian intelligence nexus. UNC6293 and UNC7005 are linked — with moderate confidence — to APT29, the FSB-affiliated group historically known as Cozy Bear and Midnight Blizzard. UNC5976’s heavier malware footprint and focus on Ukrainian military and Armenian aerospace suggests potential alignment with GRU, though GTIG stops short of a firm attribution.

Technical Breakdown: Four Attack Vectors That MFA Cannot Stop

1. App-Specific Password (ASP) Phishing

UNC6293 impersonates senior U.S. State Department officials, sending highly targeted PDF lures — in some cases reaching fewer than five individuals per campaign. The PDFs contain fabricated instructions for setting up an app password labelled ms.state.gov. Once created, app-specific passwords bypass all MFA: they authenticate directly to legacy protocols (IMAP, SMTP) that Google still supports for backward compatibility. The attacker doesn’t break MFA — they use a legitimate bypass built into the platform itself.

2. OAuth Device-Code Phishing

This is the campaign’s workhorse technique. The attacker registers a convincing domain (for example my-invite[.]org spoofing GLOBSEC, or finishoperations[.]com spoofing Finland’s Operations Centre for defence exporters). The victim visits the page, is invited to register for a conference or download a document, and sees a legitimate Google OAuth consent screen. After authenticating normally — including passing MFA — the victim’s token is silently redirected to an attacker-controlled Google Cloud project in testing mode, which Google flags with a warning most users dismiss. The token grants full account access, typically to Gmail, Drive, and Calendar. UNC7005 went further, embedding browser fingerprinting scripts to detect sandbox analysis before rendering the phishing page.

3. WhatsApp Device-Linking Hijack

Perhaps the most brazen vector: UNC7005 operates domains like wa-connect[.]eu and wa-invite[.]com that walk the victim through a genuine WhatsApp device-linking flow. The victim enters their phone number, receives a real WhatsApp QR code and six-digit linking code — served by the legitimate WhatsApp backend — and scans or enters it. The attacker’s device is now linked as a secondary WhatsApp session. Post-linking, the phishing page offers “voice call”, “encrypted chat”, or “file download” options — each triggering JavaScript that activates the device camera and microphone to record audio-video and exfiltrate it to the attacker’s server.

4. CaptiveCrunch — DNS Poisoning at Hotels and Conferences

Between April and July 2026, UNC7005 infrastructure was linked to captive-portal DNS poisoning at hotel Wi-Fi gateways and conference-centre networks. Travellers connecting to what appears to be an ordinary hotel portal were silently redirected through attacker-controlled Microsoft OWA-spoofing pages (owa-ms365[.]com, m365-owa[.]com). This campaign aligns with Microsoft’s independent “CaptiveCrunch / Midnight Blizzard” reporting from 31 July 2026 and Reliaquest’s threat spotlight from 23 July 2026.

Post-Compromise Malware Arsenal

Once initial access is achieved, the clusters drop purpose-built tools:

• VIDAR (Windows infostealer, Go binary, SHA256: 1d9299799…): Exfiltrates browser credentials, saved payments, cookies, and addresses. C2: 107.189.18[.]7.
• ATOMIC / AtomicStealer (macOS, MaaS-operated): Targets Safari and Chrome credential stores, crypto wallets.
• ENGINELIGHT (Go-based, C2: statistic-ms[.]live): Lightweight persistent implant for long-haul espionage access.
• CHERRYPIE / ChocoShell (PowerShell): LLM-assisted artifacts — meaning AI was used to generate evasion-ready code — harvesting credentials and clipboard data.
• HEADRUSH (malicious Excel plugin, SHA256: 2c7f4165…): Distributed via spoofed Ukrainian institute file-sharing pages, drops an HTA downloader for secondary payload staging.

The use of AI-generated malware code in CHERRYPIE marks a tactical shift worth noting: AI is now a force-multiplier for state actors producing evasion-tuned malware at speed. Defenders’ signature databases will perpetually lag.

Why This Matters for Indian Enterprises and Government Bodies

While today’s confirmed victims are primarily in Europe, the United States, Ukraine, and Armenia, the Indian threat landscape is directly implicated for three reasons. First, the same OAuth-abuse TTPs are deployed across multiple threat actor clusters, not just Russian-nexus groups — China-nexus actors (notably APT41) and criminal ransomware operators have been observed using device-code phishing against Indian IT service providers and their global clients. Second, India’s defence and aerospace sector — DRDO, HAL, BEL, and their supply chains — are high-value targets for multiple state-sponsored actors who study ICE RELIC’s techniques as a template. Third, Indian IT and consulting firms manage the digital infrastructure of European and American defence clients, making them an indirect vector into these primary targets.

The previous post on this blog about The Gentlemen Ransomware campaign targeting India through FortiGate backdoors illustrates how threat actors pivot through Indian infrastructure. OAuth-based initial access provides an even quieter entry point — no exploit, no firewall alert, no AV detection.

What You Should Do: Sanjay’s Zero-Trust Defensive Playbook

These attacks succeed precisely because they look legitimate. A perimeter firewall, a SIEM rule tuned for “suspicious login”, and even FIDO2-based MFA can be bypassed or circumvented depending on configuration. The response must be architectural, not just tactical.

1. Kill App-Specific Passwords entirely. In Google Workspace Admin Console, navigate to Security → 2-Step Verification and disable app-specific passwords for all users. There is no legitimate use case that requires them in a modern, managed environment.
2. Restrict 2FA to hardware security keys only. TOTP, SMS, and app-push MFA all remain susceptible to real-time phishing. FIDO2/WebAuthn hardware tokens (YubiKey, Google Titan) are origin-bound and cannot be relayed. Enforce this for all privileged accounts immediately, and for all users within 90 days.
3. Enrol high-risk users in Google’s Advanced Protection Programme (APP). APP prevents app-password creation and restricts which apps can access account data, neutralising both the ASP and OAuth vectors simultaneously.
4. Audit OAuth consent grants monthly. In Workspace Admin → Security → API Controls → Domain-wide delegation, review all connected apps. Any OAuth grant from an unverified or testing-mode application should be immediately revoked. Third-party tools like Google Security Command Center and Microsoft Defender for Cloud Apps can surface shadow OAuth grants automatically.
5. Implement WhatsApp Device Audit policies. For any organisation where WhatsApp is used for business communication (common in India’s MSME sector and even in enterprise sales teams), mandate quarterly linked-device audits under WhatsApp → Settings → Linked Devices. Consider migrating sensitive communications to platforms with richer enterprise audit controls.
6. Treat conference-centre and hotel Wi-Fi as hostile networks. All remote-working and travelling employees should connect via corporate VPN (ideally with zero-trust network access, where the device is continuously verified rather than granted blanket tunnel access) before opening any cloud authentication flow. The CaptiveCrunch campaign is a direct warning against portal-authenticated Wi-Fi.
7. Integrate threat intelligence feeds. The IOC table from GTIG — including domains like wa-connect[.]eu, foreignrelations[.]us, my-invite[.]org, and IPs 104.194.159[.]150 and 107.189.18[.]7 — should be immediately loaded into your firewall and NGFW threat intelligence feeds. FortiGate’s FortiGuard Threat Intelligence service will distribute these IOCs automatically for customers using the premium threat-intelligence subscription.

Frequently Asked Questions

Does hardware MFA (FIDO2/WebAuthn) protect against OAuth device-code phishing?

Mostly yes, with a critical caveat. Hardware security keys are origin-bound: the key will refuse to sign a challenge for a domain that does not match the registered origin. This blocks real-time phishing of MFA codes. However, OAuth device-code phishing operates differently — the victim authenticates to the genuine Google domain, so the hardware key signs correctly. The attack hijacks the resulting token, not the authentication event. Combining hardware keys with OAuth app whitelisting and unverified-app consent blocking is required for full protection.

We use Microsoft 365, not Google Workspace. Are we affected?

Yes. UNC7005 and Midnight Blizzard both operate device-code phishing campaigns against Microsoft 365 accounts, as confirmed by Microsoft’s own CaptiveCrunch reporting from July 2026. The attack flow is nearly identical: a spoofed Microsoft login page, a real device-code prompt, and a stolen access token. Microsoft’s Conditional Access policies with compliant-device enforcement and the blockDeviceCodeFlow authentication context provide the equivalent mitigation.

How do I tell if my Google or WhatsApp account has already been compromised this way?

For Google: check Security → Recent Security Activity and Third-party apps with account access. Look for apps you don’t recognise, especially those granted sensitive scopes (Gmail read, Drive full access) within the last six months. For WhatsApp: Settings → Linked Devices shows all active secondary sessions with approximate location — any unfamiliar device should be immediately unlinked. Neither indicator is infallible; a sophisticated attacker will have already exfiltrated what they need and may have unlinked. SIEM correlation of authentication tokens from unusual IPs or user-agents against normal baseline behaviour is more reliable at the enterprise level.

Is this APT29 campaign specifically targeting Indian organisations?

Current GTIG reporting does not name Indian victims. However, the techniques — particularly OAuth phishing and WhatsApp device-linking — are platform-agnostic and are being replicated by multiple threat actor families beyond APT29. Indian defence subcontractors, IT service providers managing European defence accounts, and diplomatic missions in Delhi are plausible targets under a supply-chain or indirect-access strategy. The Indian Computer Emergency Response Team (CERT-In) has not yet issued a specific advisory, but organisations in the defence, government, and critical-infrastructure sectors should treat this as an active risk.

The Bottom Line: Legitimate Flows Are the New Attack Surface

The most significant insight from the GTIG report is architectural: perimeter security and traditional MFA were built to defend against illegitimate access — but these attacks use entirely legitimate flows. The token is real. The login page is real. The QR code is real. The only thing that is manufactured is the context in which the victim uses them.

Zero-trust — which demands continuous verification of identity, device health, and access context at every step, not just at the perimeter — is the only framework that structurally addresses this class of attack. App whitelisting, OAuth consent monitoring, and hardware-bound authentication are not optional hardening steps for high-security environments. They are baseline hygiene for any organisation whose people use cloud platforms — which, in 2026, means everyone.

The sources for this article are the Google Threat Intelligence Group primary report, The Hacker News coverage, The Register’s technical analysis, and Security Affairs.

The post APT29 Ghost Login: Russian Spies Bypass MFA Using Google OAuth and WhatsApp — GTIG Reveals Three Active Espionage Clusters appeared first on Sanjay Seth — Cybersecurity & Network Consultant.

How We Got Here: A Timeline of Two CVEs

SharePoint’s authentication stack has been under siege in 2026. CVE-2026-55040 is the fifth actively exploited SharePoint vulnerability this year, joining CVE-2026-45659, CVE-2026-56164, CVE-2026-58644, and CVE-2026-50522 in an alarming sequence. Stephen Fewer, Senior Principal Security Researcher at Rapid7, discovered both CVEs and worked with Microsoft on coordinated disclosure.

Technical Breakdown: Four JWT Weaknesses Chained Into One Master Key

At its core, CVE-2026-55040 is a flaw in SharePoint’s SPJsonWebSecurityTokenHandlerV2 and SPJsonWebSecurityBaseTokenHandlerV2 classes. Rapid7’s analysis reveals that the vulnerability is not a single bug but a chain of four independently weak JWT validation steps that, together, let an attacker mint a token the server accepts as legitimate.

1. Algorithm confusion (“alg: none”): SharePoint’s token handler does not reject JWTs with an "alg": "none" header, meaning no cryptographic signature is required at all.
2. Unverified certificate thumbprint: The server uses the attacker-supplied thumbprint in the JWT header to resolve a signing key from its own STS certificates — without validating that the thumbprint corresponds to a trusted issuer.
3. Skipped TrustedSecurityTokenServices check: The TrustedSecurityTokenServices validation for the token issuer is bypassed, so the attacker can claim any issuer identity.
4. Unsigned actor tokens accepted: Actor tokens embedded in the JWT are processed without signature verification, allowing the attacker to claim any user identity — including a site collection administrator.

The practical attack flow, per Rapid7’s public PoC: an attacker who knows a target user’s Active Directory Security Identifier (SID) or User Principal Name (UPN) — both obtainable through LDAP enumeration or public LinkedIn data — can craft a forged JWT in seconds and submit it to any SharePoint endpoint that accepts bearer token authentication. The server returns a valid session cookie granting administrative privileges.

The Full RCE Chain: CVE-2026-55040 + CVE-2026-63520

Alone, CVE-2026-55040 delivers admin-level access to SharePoint content. Chained with CVE-2026-63520 (CVSS 8.1, patched August 12), the exploit escalates to unauthenticated remote code execution on the server itself.

CVE-2026-63520 is an unsafe .NET type instantiation flaw in SharePoint’s Business Connectivity Services (BCS) component. On its own, it requires an authenticated session. But once CVE-2026-55040 provides that forged authentication token, BCS can be abused to instantiate arbitrary .NET types — resulting in full server-side code execution. Rapid7 has committed to publishing full technical details for CVE-2026-63520 by approximately September 10, 2026, giving defenders a small window to patch before the RCE technique becomes commodity knowledge.

This is, functionally, a zero-credential, over-the-internet, full-server-takeover vulnerability. For SOC teams and IT leaders, it belongs in the same threat category as Log4Shell and ProxyLogon.

Why This Matters Especially for Indian Enterprises

SharePoint Server remains deeply embedded in Indian government departments, public-sector banks, large BFSI institutions, and IT services firms — many of which are running on-premises SharePoint 2016 or 2019 rather than cloud-hosted SharePoint Online. (SharePoint Online in Microsoft 365 is not affected by these CVEs — this is an on-premises flaw.)

The threat becomes acute given three India-specific factors:

• End-of-life exposure: SharePoint Server 2016 received its final ever security patch on July 14, 2026. Any organisation still running 2016 after that date has zero future patches coming.
• Sensitive content: SharePoint farms in India routinely host employee PII, financial records, legal documents, and project IP — exactly the data ransomware actors and state-sponsored groups target.
• CERT-In compliance risk: A compromise involving personal data triggers mandatory 6-hour reporting obligations under CERT-In’s 2022 directions and could expose organisations to regulatory liability under India’s Digital Personal Data Protection Act, 2023.

The exploit chain also creates a natural pivot path: a compromised SharePoint farm typically has service accounts with elevated permissions across Active Directory, Azure AD Sync, and on-premises Exchange — making it an ideal beachhead for lateral movement. This pattern mirrors what we saw in the Microsoft Entra ID RCE chain (CVE-2026-69836) covered earlier this month, where identity infrastructure served as both the entry point and the lateral movement engine.

What You Should Do: Expert Defensive Guidance

Based on Sanjay Seth’s three decades working on enterprise security in Delhi NCR, here is the priority action list for any organisation running SharePoint on-premises:

1. Patch immediately — both CVEs, both months. Apply the July 2026 Patch Tuesday update for CVE-2026-55040 and the August 2026 update for CVE-2026-63520 to all SharePoint Server Subscription Edition, 2019, and 2016 instances. Do not treat these as separate patch cycles — the chain requires both.
2. Audit your JWT issuer trust configuration. Open SharePoint Central Administration → Security → Manage Trust. Remove any Trusted Security Token Service entries that are no longer actively used. Each unnecessary entry expands the attack surface.
3. Review Business Connectivity Services (BCS) data connections. Disable BCS connections that are not actively used in production. Reducing BCS exposure limits the RCE vector even if CVE-2026-63520 has not yet been patched.
4. Enable SharePoint Unified Audit Log and forward to your SIEM. Look specifically for FileAccessed, PageViewed, and SiteCollectionAdminAdded events from service accounts or unfamiliar UPNs. Exploitation typically involves enumerating users and escalating to site-collection admin.
5. Apply network-layer controls via your NGFWs. If you are running FortiGate, enable IPS signature updates and ensure the SharePoint-specific signatures are active. Restrict external access to SharePoint ports (TCP 80/443) at the perimeter to trusted IP ranges where operationally feasible. Similar to the Citrix NetScaler auth bypass situation earlier this year, perimeter segmentation is your first line of defence while patches are being staged.
6. If you are still on SharePoint 2016, migrate now. No future security patches will be released for SharePoint 2016. Migration to SharePoint Server Subscription Edition or SharePoint Online is no longer optional — it is a security imperative.
7. Zero-trust posture check: Verify that your SharePoint farm’s service accounts follow the principle of least privilege. A compromised SharePoint admin account should not have unrestricted access to Active Directory, email, or file servers. Micro-segmentation and conditional access policies are your insurance if exploitation occurs before patching is complete.

Frequently Asked Questions

Is SharePoint Online (Microsoft 365) affected?

No. CVE-2026-55040 and CVE-2026-63520 affect only on-premises SharePoint Server deployments — SharePoint Server Subscription Edition, SharePoint Server 2019, and SharePoint Server 2016. Microsoft’s cloud-hosted SharePoint Online was patched on Microsoft’s side without customer action required.

Does the attacker need any existing credentials or network access?

When CVE-2026-55040 is exploited standalone, the attacker needs to know a target user’s Active Directory SID or UPN — obtainable through LDAP, public directories, or social engineering. No password is required. If your SharePoint is internet-facing (accessible without a VPN), it is exposed to the internet-based exploitation attempts already observed.

How quickly can I tell if I have already been compromised?

Indicators of compromise to hunt for in your logs: unexpected SiteCollectionAdminAdded events since July 19, 2026; authentication events from service accounts at unusual hours; HTTP 200 responses to /_vti_bin/ or BCS-related endpoints from external IPs; and new Azure AD Sync credentials or service principal registrations linked to SharePoint. CISA’s advisory and Rapid7’s technical writeup contain specific IoCs.

What if we cannot patch immediately due to change management constraints?

Apply compensating controls in this order: (1) Place SharePoint behind a VPN or Zero Trust Network Access (ZTNA) gateway so it is not directly reachable from the internet. (2) Enable WAF rules blocking requests with JWT alg:none headers and unusual thumbprint patterns. (3) Disable BCS if not business-critical. (4) Increase SIEM alerting sensitivity for SharePoint admin events. Then fast-track the patch through an emergency change window — CISA’s KEV listing means federal agencies have a hard remediation deadline, and private-sector organisations should treat it the same way.

The Bottom Line

CVE-2026-55040 and CVE-2026-63520 together represent one of 2026’s most dangerous vulnerability chains for on-premises Microsoft infrastructure. The patches have existed since July and August respectively — the only reason organisations remain exposed is patch lag. With a public PoC available, exploitation will only grow more automated and widespread in the coming weeks.

If your organisation operates SharePoint on-premises and has not yet applied both patch cycles, treat this as a P0 incident in progress. The question is not whether attackers will attempt exploitation — they already are. The question is whether your defences are in place before you become the next case study.

The post CVE-2026-55040 + CVE-2026-63520 (CVSS 9.1): Attackers Now Forge SharePoint Admin Credentials — No Password Required appeared first on Sanjay Seth — Cybersecurity & Network Consultant.

Who Are The Gentlemen? A Qilin Splinter Turned RaaS Juggernaut

The Gentlemen first appeared on VirusTotal on 17 July 2025, when a researcher flagged a novel Go-based ransomware sample with unusual build characteristics. Within two months, the group had begun openly marketing their ransomware-as-a-service affiliate programme on criminal forums, openly courting defectors from Qilin, LockBit, and RansomHub with one compelling differentiator: a 90 percent affiliate revenue split — the highest payout ever documented in underground ransomware markets.

The origin story matters. An affiliate known as hastalamuerte had previously operated under the Qilin umbrella and filed a payment dispute in July 2025 after allegedly being shorted approximately $48,000 in commissions. That dispute catalysed the fork. Hastalamuerte joined forces with operator zeta88 and seven other core members to build The Gentlemen from scratch, incorporating what the group describes as “cherry-picked” encryption routines, obfuscation layers, and EDR evasion methods reverse-engineered from Babuk, Qilin, LockBit 5.0, and Medusa. The result is a ransomware toolkit that is modular, cross-platform, and operationally mature from day one.

Growth has been staggering. The group recorded 48 attacks in January 2026, 91 in February — nearly doubling in a single month — and 89 in April 2026. By June 13, 2026, researchers at Ransomnews had tracked 483 distinct victims, while Halcyon’s Threat Actor Index places the figure above 500 as of this writing. That makes The Gentlemen the second most prolific ransomware brand of 2026, trailing only Qilin — the very organisation they splintered from. Cyber risk analysts at The Insurer designated them the most active threat actor in Q2 2026.

India in the Crosshairs: Four Confirmed Victims in 2026

While the group’s overall victim geography skews towards Thailand (their most-targeted country), the United States, Brazil, and France, India has emerged as a consistent and growing target. At least four Indian organisations have been publicly claimed as victims in 2026:

The Tikona Infinet breach is particularly alarming for India’s digital infrastructure community. Tikona provides broadband and enterprise connectivity to tens of thousands of Indian businesses. A threat actor with access to a major ISP’s internal systems could potentially intercept traffic, harvest credentials from downstream customers, or map enterprise network topologies — intelligence that compounds the risk far beyond Tikona itself. The group posted a public leak warning on their dark-web site: “The full leak will be published soon, unless a company representative contacts us.”

This pattern of targeting telecom, manufacturing, and supply-chain firms mirrors the group’s global playbook. They specifically hunt organisations where operational disruption is catastrophic — where ransom payment is often perceived as faster than recovery. Indian CISOs and IT directors in these verticals must treat this as a direct, active warning. This India-focused threat intelligence context aligns with what we covered in our analysis of Lazarus targeting Indian aerospace — adversaries are not ignoring India, they are specifically selecting it.

Technical Deep Dive: How The Gentlemen Break In and Spread

The group’s primary initial access vector is CVE-2024-55591 — a critical authentication bypass flaw in FortiOS and FortiProxy that allows an unauthenticated remote attacker to gain super-admin privileges via crafted requests to the Node.js websocket module. Fortinet disclosed and patched this in January 2024, yet Halcyon’s threat assessment documents that The Gentlemen maintain a standing pool of approximately 14,700 already-compromised FortiGate appliances globally — devices where the exploit succeeded months or years ago and persistent access has been quietly maintained, ready to activate for affiliate campaigns.

This is a chilling example of the “land and hibernate” technique: compromise the perimeter at scale, stay silent, then monetise when the affiliate pays up. For every Indian organisation running an unpatched or post-exploit-but-not-reimaged FortiGate, the clock is already ticking.

Post-access, the group’s kill chain is methodical:

• Lateral movement: AnyDesk, PsExec, PowerShell Remoting across the internal network
• Privilege escalation: PowerRun to achieve SYSTEM-level access; Active Directory Group Policy Object (GPO) hijacking for domain-wide deployment
• Defence evasion: Windows Defender disabled with path exclusions; Volume Shadow Copies and Recycle Bin deleted; backup, database, and virtualisation services terminated; event logs cleared; free disk wiped on Linux targets
• Data exfiltration: Sensitive files exfiltrated before encryption, enabling double-extortion leverage
• Encryption: Go-based encryptor deployed for Windows and Linux; a dedicated C-based locker handles ESXi hypervisors. Files ≤1 MB are fully encrypted; larger files use intermittent encryption for speed. Each file receives a unique ephemeral key, preventing bulk decryption even if the master key is partially obtained. Encrypted files receive a .umc16h extension and a ransom note named README-GENTLEMEN.txt.

GentleKiller: Purpose-Built EDR Destruction

What separates The Gentlemen from commodity ransomware operators is their investment in GentleKiller — a dedicated EDR-destruction framework that arrives before the encryptor. GentleKiller ships with named driver components including HexKiller, ThrottleBlood, and HavocKiller, each targeting specific endpoint security platforms. The group also leverages BYOVD (Bring Your Own Vulnerable Driver) techniques, weaponising publicly disclosed vulnerable driver proof-of-concepts within days of their release.

The practical consequence: by the time the encryptor runs, most standard endpoint detection and response tools are already blind. This is why threat intelligence briefings from multiple vendors consistently flag that organisations relying solely on EDR for ransomware defence are dangerously under-protected against this threat actor.

This is a known risk pattern — as we’ve seen with other advanced ransomware operators like DeadLock’s blockchain-based C2 evasion, modern ransomware groups invest heavily in defeating the defensive tools organisations trust most.

The May 2026 Breach: A Rare Window Into Operations

In an extraordinary development in May 2026, an unknown party compromised The Gentlemen’s own internal backend infrastructure. On 4 May 2026, the breach was confirmed; by the following day, internal data was being advertised for sale at $10,000 in Bitcoin, with proof files posted publicly.

What leaked was operationally significant: nine internal accounts including administrator zeta88 and IAB hastalamuerte; server credentials and password hashes; shared VPN and Synology accounts; real-time intrusion coordination logs spanning November 2025 to April 2026; C2 infrastructure setup procedures; and payout tracking across campaigns. The leaked chats revealed the group had studied the Black Basta February 2025 leak as an operational template, and were actively using uncensored AI models (specifically cited Qwen variants) to assist with operations planning.

Despite this exposure, the group did not pause operations. Their attack volume in May and June 2026 remained consistent with prior months — a sign of deep operational resilience and compartmentalisation that security researchers found alarming. The playbook being used against Indian firms today was documented in that leak.

What You Should Do Now: Sanjay Seth’s Expert Defence Checklist

The Gentlemen’s success rests on three foundational failures at target organisations: unpatched edge devices, flat Active Directory architectures, and missing offline backups. Address these and you deny the group their entire kill chain. Here is the prioritised action list for Indian IT and security teams:

1. Audit all FortiGate and FortiProxy devices immediately. Patch to firmware versions not affected by CVE-2024-55591. But patching alone is insufficient — if a device was exposed before patching, assume it may be compromised. Re-image affected appliances from clean firmware, reset all admin credentials, and rotate all certificates and VPN pre-shared keys. Check for rogue admin accounts and unexpected firewall policy changes.
2. Hunt for persistence indicators. Search for the scheduled task named gentlemen_system, the .umc16h file extension, and processes invoking --system or --shares command-line arguments. Scan for AnyDesk installations not authorised by your IT team.
3. Segment and tier your Active Directory. The group’s GPO hijacking technique succeeds against flat AD designs. Implement AD tiering: separate Tier 0 (domain controllers), Tier 1 (servers), and Tier 2 (workstations). Restrict NETLOGON and SYSVOL write access. Monitor for unauthorised GPO and scheduled task creation with real-time alerting.
4. Deploy phishing-resistant MFA everywhere. The group leverages infostealer-sourced credentials and session cookies to bypass standard MFA. Use FIDO2/hardware tokens for privileged accounts, VPN gateways, and Outlook Web Access. This is especially relevant given their documented use of compromised OWA mailboxes as an alternate initial access path.
5. Implement immutable, air-gapped backups. The group deletes VSCs and terminates backup services before encrypting. Ensure you maintain at least one backup that is offline or immutable (e.g., WORM storage) and test restoration quarterly. Follow the 3-2-1-1 rule: three copies, two media types, one off-site, one air-gapped.
6. Consider a Zero Trust review of your edge posture. If your organisation is running Fortinet, Cisco, or Citrix edge devices — all targeted by various 2026 campaigns — it is time for a professional assessment of your perimeter security posture before you become the next entry in a ransomware group’s victim table.

Frequently Asked Questions

Is CVE-2024-55591 still dangerous if I patched my FortiGate in 2024?

Patching closes the vulnerability but does not undo a prior exploitation. The Gentlemen’s model involves compromising devices and quietly maintaining access for months before activating. If your FortiGate was exposed to the internet while unpatched at any point after January 2024, you should conduct a forensic review of configuration changes, admin account activity, and outbound traffic anomalies — even if the firmware is now current.

Why are Indian manufacturing and telecom firms being targeted specifically?

Ransomware groups target organisations where operational downtime is most painful and where ransom payment is perceived as faster than recovery. Manufacturing firms cannot afford production halts; telecom providers face SLA penalties and regulatory scrutiny. India’s growing industrial and digital economy makes it an attractive target, and the relatively lower cybersecurity maturity compared to US or European peers means attackers often face less resistance. The Gentlemen’s Southeast Asian affiliate base may also provide linguistic and cultural familiarity with Indian targets.

The group’s backend was hacked in May 2026 — does that mean the threat is diminished?

Unfortunately, no. Despite the breach of their own infrastructure, The Gentlemen continued operating at full pace through June and July 2026. The Indian attacks on Tikona Infinet and others occurred after the backend compromise. The leak exposed their playbook but not their operational capacity. Threat intelligence teams can use the leaked data to improve detection signatures, but organisations should not conclude that the group is weakened.

What should I do if I suspect my organisation has already been compromised by The Gentlemen?

Do not attempt to remediate without professional support. Immediately isolate affected systems from the network, preserve forensic evidence (do not wipe machines), and engage a specialist incident response team. Check for the gentlemen_system scheduled task and .umc16h extensions. Alert your data protection officer — under India’s DPDP Act and applicable CERT-In requirements, breach notification obligations may apply. Crucially, do not pay the ransom without legal counsel: there are sanctions implications and no guarantee of data deletion.

The Gentlemen ransomware group is not a future threat — it is a present one, actively targeting Indian organisations right now. The window to act before a breach is shorter than most IT leaders realise. A compromised FortiGate appliance you patched last year may already be a doorway an affiliate purchased last month.

If you need an expert eye on your edge device posture, Active Directory architecture, or incident response readiness, reach out to Sanjay Seth for a security assessment. With 30 years in cybersecurity, specialising in zero-trust architecture and enterprise network defence across India and the NCR region, Sanjay’s team can help you close the gaps before a ransomware affiliate does.

The post The Gentlemen Ransomware: India in the Crosshairs as 500+ Victims Fall and FortiGate Backdoors Enable Global Strikes appeared first on Sanjay Seth — Cybersecurity & Network Consultant.

For enterprise security teams, CISOs, and DevSecOps practitioners across India and globally, the RUSTSEC-2026-0260 incident is not just another open source compromise — it is a strategic signal about where nation-state adversaries are choosing to fight in 2026: inside your build pipeline.

What Happened: The 86-Minute Attack Window

The attack was painstakingly prepared. As early as 01:17 UTC on 20 August, an attacker created a crates.io account named dtolney — a deliberate impersonation of David Tolnay, maintainer of the widely trusted proc-macro2 library. By 01:55 UTC, a benign clone of proc-macro2 was uploaded as proc-macro1, quietly seasoning crates.io’s index for what was to come.

At 07:11 UTC, the malicious version of proc-macro1 (1.0.107) was slipped in. Four minutes later, the attacker published arrayref 0.3.10 through the legitimate but compromised account of David Roundy (droundy), a registered maintainer since 2009. Versions of internment and append-only-vec followed within 23 minutes, all adding a single-line dependency on the poisoned proc-macro1.

Critically, the attacker exploited a subtle Cargo mechanic. Yanking older legitimate versions (0.3.5–0.3.9) of arrayref under the droundy account made 0.3.10 appear to be the only safe available release to many automated resolvers and developers accepting warnings about yanked dependencies. The Nextron Systems GmbH Research Team filed the initial incident report at 07:54 UTC. Within roughly 86 minutes of the first malicious publish, crates.io yanked the files. But the damage window was real.

Inside the Build-Time Payload: How cargo build Became a Weapon

The technical ingenuity here deserves careful attention. Rather than modifying the actual library source code, the attacker embedded malware entirely within a Cargo build script (build.rs) inside the typosquatted proc-macro1 dependency. Build scripts in Rust run arbitrary code as part of compilation — a powerful feature for legitimate cross-compilation tasks, and a devastating one when abused.

The build.rs script reassembled its command-and-control addresses from base64 fragments at compile time, evading simple static string searches. It then deployed platform-appropriate second-stage implants:

• Linux/macOS: Wrote payload bytes to /tmp/rust-setup, marked the file executable, and spawned a detached process to escape Cargo’s cleanup mechanisms.
• Windows: Created %TEMP%\rust-setup.ps1 and used a hidden wscript.exe VBScript launcher to run PowerShell in a way that escaped Cargo’s job object — meaning the malware survived even after the build process ended.
• macOS ARM64: Separate architecture-specific binary delivered; targeting Apple Silicon developer machines.

The stage-2 implant established persistence through Registry Run keys on Windows, LaunchAgent plists on macOS, and systemd user services on Linux. It communicated with C2 at 23.254.165.112 over HTTPS POST to a hardcoded path (/49890878), with TLS validation disabled via an unconditional certificate verifier. Once established, it supported four operator commands: termination, C2 reconfiguration, persistence adjustment, and arbitrary script execution.

On the credential-theft front, the Windows implant queried SQLite login databases belonging to Chrome, Brave, and Edge — extracting origin URLs and usernames. Security researchers noted that the implant queried password_value columns as well, though analysis of the Windows binary remained inconclusive on whether full password decryption was attempted. Linux and macOS payloads were not fully analysed as of the advisory date.

What makes this especially alarming for enterprise teams: the payload fired during any of cargo build, cargo check, or cargo test. A developer pulling dependencies in a clean environment, a CI runner spinning up a fresh container, a security engineer auditing a project — all were equally exposed. No end-user interaction with the library’s actual API was required.

The North Korea Fingerprint: Connecting MIDNIGHT NEPTUNE and Sapphire Sleet

Within hours of the incident, Wiz researchers published analysis documenting “substantially overlapping” infrastructure between the arrayref campaign and two prior DPRK-linked supply chain operations:

• Mastra npm compromise (June 2026) — attributed by Microsoft with high confidence to Sapphire Sleet, a DPRK threat actor known to blend financial theft with intelligence collection.
• axios npm compromise (April 2026) — attributed by Google Threat Intelligence Group to MIDNIGHT NEPTUNE (UNC1069), a group Mandiant has linked to North Korean operations targeting developers.

The technical overlaps were damning. Both the Mastra and arrayref campaigns used the identical C2 path /49890878. The attacker’s IP address (23.254.165.112, on Hostwinds LLC’s 23.254.164.0/23 range) appeared in Google Cloud Threat Intelligence’s UNC1069 analysis. The same hosting provider and same C2 endpoint structure across three separate npm/cargo campaigns strongly suggests operational continuity — or at minimum, a shared toolchain and infrastructure pool within the DPRK’s offensive apparatus.

This is not North Korea’s first software supply chain operation. This is, however, their first confirmed intrusion into the Rust ecosystem — a language increasingly used in financial infrastructure, blockchain runtimes (Ethereum, Solana), systems programming, and embedded security tooling. The arrayref crate alone has 403 dependent packages on crates.io, including widely used projects like blake3 (cryptographic hashing), egui, iced (GUI frameworks), and components of blockchain wallets.

India context: DPRK threat actors have already demonstrated active interest in targeting Indian aerospace, defence, and IT services sectors — as seen in the concurrent CVE-2026-68820 Lazarus campaign against Indian aerospace firms. Indian software product companies, fintech startups, and IT services organisations building Rust-based backend or blockchain systems face elevated risk given the DPRK’s established pattern of financially motivated supply chain attacks.

Scope: Which Projects and Pipelines Were Exposed

The blast radius of this attack is large by any measure. arrayref has amassed 245,385,500 all-time downloads, with over 53.9 million in the 90 days before the attack. Dependency chain analysis reveals that any project using Cargo’s default semver-compatible resolution (^0.3) on arrayref would have automatically pulled 0.3.10 as the latest stable release.

Known affected dependency chains include:

• winit → sctk-adwaita → tiny-skia → arrayref (cross-platform windowing)
• Various blake3, blake2b_simd, and blake2s_simd dependents (these maintainers dropped the arrayref dependency within minutes of discovery)
• Ethereum and Solana ecosystem crates
• GUI frameworks: egui, eframe, iced

The Rust Security Response Team confirmed there is no direct evidence that any malicious version was executed in a downstream environment — though this assessment is limited by the incomplete telemetry available to open source maintainers. If your CI/CD pipeline ran a Rust build between approximately 07:15 and 09:25 UTC on 20 August 2026, you must assume potential exposure.

What You Should Do Now — The Defensive Playbook

Speaking from my experience building and securing NOC/SOC infrastructure for enterprise clients, software supply chain compromises like this require a structured, time-sensitive response. Here is the immediate action plan:

Immediate Response (0–24 Hours)

1. Audit your Cargo.lock files. Search all repositories for arrayref = "0.3.10", internment = "0.8.7", or append-only-vec = "0.1.9". Run: grep -r "arrayref.*0.3.10" .cargo/registry/cache/
2. Identify exposure window. Check build logs and CI pipeline timestamps for Rust builds between 07:15–09:25 UTC on 20 August 2026.
3. Treat exposed machines as compromised. For any host that ran an affected build, initiate full incident response: isolate, image for forensics, rebuild from clean state.
4. Search for indicators of compromise. Look for /tmp/rust-setup (Linux/macOS), %TEMP%\rust-setup.ps1 or rust-setup-launch.vbs (Windows). Monitor for outbound traffic to 23.254.165.112 on ports 443 and 9089.
5. Rotate all credentials. Every credential, API token, CI secret, code signing key, and cloud IAM credential accessible from an exposed build environment must be treated as stolen. This includes GitHub tokens, AWS IAM keys, NPM publish tokens, and Docker registry credentials stored in CI runners.

Medium-Term Hardening (1–4 Weeks)

• Pin dependency versions explicitly. Replace version ranges with exact pinned hashes in Cargo.lock and commit the lockfile. Use cargo audit against the RustSec advisory database in your CI pipeline.
• Sandbox build environments. Run cargo build in network-isolated containers where build scripts cannot initiate outbound connections. Tools like --offline and Cargo’s [net] offline = true setting help; consider tools like Bubblewrap or OCI container sandboxing.
• Enable Software Composition Analysis (SCA). Integrate SCA scanning (OWASP Dependency Check, GitHub Dependabot, or equivalents) for all Rust projects. Track RustSec advisories as a feed.
• Monitor for new yanks as an attack signal. Sudden yanking of established crate versions is now a meaningful threat intelligence signal — monitor crates.io RSS or your package mirror for unexpected yank events on dependencies you rely on.
• Apply zero-trust principles to your CI/CD pipeline. Least-privilege CI tokens, ephemeral build environments, and mandatory code review for dependency changes reduce the blast radius of future supply chain attacks. This is the same zero-trust architecture philosophy we apply to network access — and it applies equally to your build system.

This attack is an important case study in why the LiteLLM supply chain compromise we covered earlier this year was not a one-off event. Nation-state actors have systematically identified open source package registries as high-leverage attack vectors: one compromised maintainer credential = potential access to millions of developer pipelines. The industry must respond with systemic controls, not reactive patching.

Frequently Asked Questions

I use Rust in my project but didn’t build anything on 20 August — am I safe?

If your Cargo.lock does not reference arrayref 0.3.10, internment 0.8.7, or append-only-vec 0.1.9, and you did not run a Rust build during the exposure window (07:15–09:25 UTC, 20 August 2026), you are almost certainly not affected. Verify by checking your lockfiles and CI build timestamps.

Does this affect Rust projects that include arrayref transitively (not directly)?

Yes. Any project whose Cargo dependency graph resolves to an affected version — even through multiple transitive dependencies — would have pulled the malicious proc-macro1 build script and triggered the payload during compilation. Check your full resolved dependency tree, not just direct dependencies.

Has a CVE been assigned? Where can I get official updates?

No CVE has been assigned as of 21 August 2026. The authoritative advisory is RUSTSEC-2026-0260 published on the Rust Security Advisory database. The official Rust Blog post and the Wiz threat intelligence report are the primary sources for ongoing attribution and technical analysis.

What systemic changes is the Rust ecosystem making to prevent this?

A pull request implementing global-min-publish-age in Cargo — which would introduce a mandatory cooling-off period before new crate versions appear in the index, similar to GitHub Dependabot’s July 2026 default — entered its final comment period on 18 August 2026 but remained unmerged as of the attack date. Expect this and additional account-security requirements (2FA enforcement, verified maintainer identities) to accelerate following RUSTSEC-2026-0260.

The post RUSTSEC-2026-0260: North Korean Hackers Poison arrayref Rust Crate With Build-Time Infostealer — 245 Million Downloads at Risk appeared first on Sanjay Seth — Cybersecurity & Network Consultant.

For Indian IT leaders and security practitioners, the timing could not be more sobering. Entra ID underpins Microsoft 365 tenants across India’s BFSI, IT/ITeS, healthcare, manufacturing, and government sectors. Under CERT-In’s six-hour mandatory breach-reporting directive, the exploitation window that preceded disclosure may have already obligated many organisations to report — whether they knew it or not.

What Is CVE-2026-69836?

CVE-2026-69836 is a remote code execution vulnerability in Microsoft Entra ID caused by the insecure handling of serialised data. Microsoft’s official description is precise: “Deserialization of untrusted data in Microsoft Entra ID allows an unauthorized attacker to execute code over a network.” The underlying weakness is classified as CWE-502 (Deserialization of Untrusted Data) — a class of bug where an application converts externally-supplied byte streams into live objects without sufficient validation, inadvertently handing attackers a code-execution primitive.

The vulnerability was published on 20 August 2026 and was discovered by Robert Fitzpatrick, Principal Security Engineer, according to Microsoft’s Security Response Center advisory. Because Entra ID is a Microsoft-operated cloud service, the “patch” was deployed directly by Microsoft to its infrastructure — affected organisations do not need to apply a hotfix or restart anything.

Technical Deep Dive: Why CVSS 10.0?

The maximum score of 10.0 is not awarded loosely. The full CVSS 3.1 vector — AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — tells a precise story:

The Scope: Changed rating is particularly significant. It means a successful exploit does not just compromise the Entra ID service in isolation — it potentially pivots into downstream resources within the same trust boundary: Microsoft 365 mailboxes, SharePoint libraries, Teams channels, Dynamics environments, and any application registered against the tenant. This is a single vulnerability that can unlock an entire enterprise’s cloud estate.

For a deeper understanding of how CVE-2026-69836 is catalogued on NVD, the record confirms the CWE-502 classification and the vendor-assessed CVSS vector.

Why “Fully Mitigated” Doesn’t Mean “You’re Safe”

Microsoft’s statement that “there is no action for users of this service to take” is reassuring at face value. The server-side patch is real and deployed. But that phrasing obscures a critical truth: the exploitation window was open before the patch. Microsoft confirmed active exploitation in the wild prior to public disclosure.

What that means operationally:

• Threat actors may have already executed code within Entra ID infrastructure and left behind service principals, OAuth app grants, or credential changes inside your tenant.
• The patch closes the RCE door but does not evict any attacker who used it to gain a foothold.
• Unlike an on-premises vulnerability where your patch deployment is visible, cloud-side mitigations give organisations zero transparency into the timeline of exploitation.

This is precisely the scenario that BleepingComputer’s reporting on the flaw underscores: organisations must treat their tenant as potentially compromised and conduct active threat hunting in their identity logs — not simply note that Microsoft patched and move on.

The Zero-Trust Angle: When Your Identity Plane Is the Attack Surface

Zero-trust architecture is built on the principle that identity is the new perimeter. The NIST SP 800-207 framework positions identity verification as the primary policy enforcement point for every resource access request. When the identity plane itself carries a CVSS 10.0 vulnerability that has been weaponised, the entire zero-trust trust-chain is called into question.

The answer is not to abandon zero-trust — it is to harden the foundations. This means:

• Treating Entra ID as a critical infrastructure component with its own patch and audit cadence, not merely a supporting service.
• Layering Conditional Access Policies to restrict token issuance by device compliance, location, and risk signal — so even if an attacker steals a token, the downstream damage is bounded.
• Implementing Privileged Identity Management (PIM) to ensure Global Administrator and other high-privilege roles are time-limited and require just-in-time activation.
• Connecting Entra ID logs to a SIEM / SOC platform so anomalous sign-in patterns and service principal changes surface as alerts in real time.

At P J Networks, Sanjay Seth’s team has implemented this layered identity approach for enterprises across Delhi NCR, combining FortiGate SD-WAN perimeter controls with Entra ID Conditional Access and identity-segmented network policy — ensuring that even if the cloud identity service is attacked, adversaries face multiple additional checkpoints before reaching production assets.

India’s Cloud Identity Exposure

India is one of the fastest-growing Microsoft 365 enterprise markets in Asia-Pacific. The country’s BFSI, IT/ITeS, healthcare, and manufacturing sectors run significant workloads on the Microsoft cloud stack — meaning Entra ID is the key to millions of privileged accounts across the subcontinent. Under CERT-In’s mandatory incident reporting directive, organisations that identify evidence of exploitation related to CVE-2026-69836 within their tenant have a six-hour window to notify CERT-In before the deadline passes.

India-based organisations should also note the cascading risk illustrated by the recent Lazarus Group exploitation of Windows afd.sys (CVE-2026-68820) targeting Indian aerospace and defence — a reminder that nation-state actors view India’s IT infrastructure as a priority target, and vulnerabilities in Microsoft’s identity stack will be weaponised against Indian enterprises just as quickly as any other geography.

India’s businesses that have invested in hybrid Active Directory + Entra ID environments face a compounded risk: a cloud-side exploit that issues malicious tokens can be used to authenticate back into on-premises resources via Pass-the-Token attacks, erasing the perimeter entirely.

What Your Security Team Should Do Right Now

Microsoft’s server-side fix is in place, but your team’s work is not done. Here is Sanjay Seth’s prioritised response checklist:

1. Pull 30-day Entra ID audit logs — Look for unusual service principal creations, app permission grants, role assignments, and directory synchronisation changes. Export from the Azure Portal → Entra ID → Monitoring → Audit Logs.
2. Review sign-in logs for anomalous activity — Filter for sign-ins with Risk Level “High” or “Medium,” sign-ins from unfamiliar locations, and token-only sign-ins (no interactive authentication). Use Entra ID Identity Protection risky sign-in reports.
3. Audit OAuth app registrations and enterprise applications — Unauthorised app registrations are a classic post-exploitation persistence technique. Revoke permissions for any unrecognised application.
4. Validate privileged role assignments — Confirm that Global Administrator, Privileged Role Administrator, and Application Administrator accounts match your expected list. Remove any unknown assignments immediately.
5. Enable and enforce phishing-resistant MFA — FIDO2 hardware keys or Windows Hello for Business for all admin accounts. Retire SMS-based MFA. This mitigates CVE-2026-62869 (CVSS 8.8 identity spoofing companion) which does require tenant action.
6. Review Conditional Access Policies — Confirm no policy has been weakened or disabled, and that device-compliance requirements are enforced for all privileged access.
7. Connect Entra ID to your SIEM — If your SOC is not already ingesting Entra ID logs, remediate that gap today. Real-time detection of lateral movement through identity is only possible with log coverage.

Timeline of Events

• Pre-August 2026: Unknown threat actors exploit CVE-2026-69836 in the wild against Microsoft Entra ID tenants.
• 20 August 2026: The Hacker News reports on the advisory; Microsoft confirms exploitation and full server-side mitigation.
• 21 August 2026: Threat intelligence community begins scanning for post-exploitation artifacts in affected tenants; MSRC advisory published with CVE-2026-69836 record.
• Ongoing: Organisations should continue threat hunting for persistence artifacts until confirmed clean.

Frequently Asked Questions

Do I need to apply a patch or update anything in my Microsoft 365 tenant?

For CVE-2026-69836 specifically, Microsoft has applied the fix at the infrastructure level — no tenant-side update, hotfix, or configuration change is required to close the RCE vulnerability itself. However, you should still audit your tenant for signs of prior exploitation, and you do need to take action on the companion CVE-2026-62869 (CVSS 8.8) identity spoofing issue, which recommends Conditional Access hardening and phishing-resistant MFA.

How do I know if my organisation’s Entra ID tenant was targeted during the exploitation window?

There is no definitive indicator published yet, but security teams should look for: new or modified service principals created without change-management records, OAuth2 permission grants to third-party applications, unexpected role assignments at the directory level, and sign-in events from unusual IP ranges or geographies during the pre-disclosure period. Use Microsoft’s Entra ID Identity Protection and Defender for Identity to cross-reference signals.

Does this vulnerability affect on-premises Active Directory?

CVE-2026-69836 is specific to the cloud-hosted Entra ID service, not on-premises Active Directory Domain Services (AD DS). However, organisations running hybrid identity environments with Entra Connect (formerly Azure AD Connect) face a lateral-movement risk: an attacker who compromises cloud tokens could leverage them to authenticate into on-premises resources via Pass-the-Token techniques, effectively bridging cloud and on-premises environments.

Is this vulnerability connected to the Lazarus Group or nation-state actors?

Microsoft has not publicly attributed CVE-2026-69836 exploitation to any specific threat actor. The concurrent exploitation of CVE-2026-68820 by the Lazarus Group is a separate campaign. That said, maximum-severity cloud identity vulnerabilities invariably attract sophisticated state-sponsored actors, and organisations in high-risk sectors — defence, BFSI, critical infrastructure — should assume elevated targeting probability.

Is Your Entra ID Tenant Secured Against the Latest Threats?

CVE-2026-69836 is a reminder that even the largest cloud providers can carry maximum-severity vulnerabilities — and that the exploitation window precedes your awareness. A secure identity posture requires continuous monitoring, zero-trust architecture, and expert review that goes beyond checking a dashboard once a month.

Sanjay Seth and the P J Networks team specialise in end-to-end security assessments covering cloud identity (Entra ID / Azure AD), network perimeter (FortiGate, SD-WAN), and SOC/NOC operations for enterprises across Delhi NCR and India. If you are not confident your tenant is clean — or want an independent review of your Conditional Access Policies, PIM configuration, and hybrid AD architecture — reach out for a security assessment today.

The post CVE-2026-69836 (CVSS 10.0): Microsoft Entra ID’s Maximum-Severity Deserialization RCE Was Exploited Before You Knew It Existed appeared first on Sanjay Seth — Cybersecurity & Network Consultant.

CVE-2026-19490: The Vulnerability in Technical Detail

The flaw is classified under CWE-288 — Authentication Bypass Using an Alternate Path or Channel. In plain terms, it means an attacker can reach internal authentication logic through a code path that Citrix’s standard authentication checks do not cover. This is not a logic error in user-supplied input validation; it is an architectural gap where a secondary request route bypasses the front-door authentication gate entirely.

Discovered by Samarth Vashisht of JPMorgan Chase’s penetration testing team and responsibly disclosed to Citrix, CVE-2026-19490 affects the following product lines:

Exposure prerequisites: The vulnerability is only exploitable when the NetScaler appliance serves as a Gateway virtual server (SSL VPN, ICA Proxy, CVPN, or RDP Proxy) or as an AAA virtual server. Citrix provides configuration detection strings to help administrators quickly determine exposure:

• add authentication samlAction.* — SAML-based authentication actions
• add authentication vserver.* — AAA virtual server configurations
• add vpn vserver.* — VPN/gateway virtual server configurations

If any of these strings appear in your running configuration, your appliance is in scope. Treat this as a P0 patching task.

Alongside CVE-2026-19490, the same bulletin addresses CVE-2026-19489 (CVSS 8.8) — a memory overflow that can cause unpredictable behaviour or denial-of-service when SIP ALG is enabled on a Large Scale NAT (LSN) group. Detection command: add lsn group.*sipalg.*. While the memory overflow’s immediate impact is typically DoS, memory corruption vulnerabilities in network-facing code have a history of being elevated to RCE by determined attackers.

Why Exploitation Is Virtually Certain — and Soon

Citrix products occupy the network perimeter — the exact position that sophisticated threat actors prize most. Once authentication is bypassed on a gateway appliance, an attacker does not just gain access to that one box; they inherit whatever remote access that gateway was designed to provide: VPN tunnels, application proxies, identity federation endpoints. In enterprise environments, a compromised NetScaler gateway is a master key.

The threat intelligence record on Citrix products is unambiguous. CVE-2023-4966 (“Citrix Bleed”) — a session token leakage vulnerability disclosed in October 2023 — was exploited in the wild within weeks, attributed to ransomware groups including LockBit and Medusa, and ultimately responsible for breaches at Boeing, the Industrial and Commercial Bank of China, DP World, and Allen & Overy, among others. CVE-2026-8451, a Citrix SAML flaw this site covered earlier this year, was exploited within 24 hours of disclosure. The pattern is consistent: Citrix vulnerabilities become weapons quickly.

The presence of over 22,000 internet-exposed NetScaler ADC instances (ShadowServer data, August 2026) ensures that once a working exploit for CVE-2026-19490 surfaces on underground forums or proof-of-concept repositories, mass scanning will begin within hours. Ransomware-as-a-Service affiliates, initial access brokers, and nation-state APT groups all have established playbooks for Citrix exploitation. The responsible disclosure period gives defenders a head start — but only if they act on it immediately.

India Alert: Your NetScaler Is in the Crosshairs

India’s enterprise IT landscape is heavily dependent on Citrix NetScaler. Major banks, insurance companies, IT outsourcing giants, and central government ministries use NetScaler Gateway as the primary SSL-VPN gateway for remote workforce access and application delivery. In sectors governed by RBI cybersecurity guidelines and SEBI cyber resilience frameworks, a compromised gateway appliance would trigger mandatory breach disclosure and attract regulatory scrutiny.

The Asia-Pacific region consistently appears in Citrix exploitation incident reports — typically in the second wave of attacks that follow initial Western-market exploitation. Indian organisations that believe they have more time than North American or European counterparts should discard that assumption. Ransomware groups that exploited Citrix Bleed were active in APAC within weeks of the initial disclosures. Gunra ransomware — which also exploited VPN gateway vulnerabilities — specifically listed Asia-Pacific as a target region in its CISA advisory.

If your organisation runs NetScaler ADC or Gateway in any configuration, your security team needs to be working on this today.

What You Should Do Right Now: An Expert Checklist

Here is a prioritised response plan built on zero-trust principles and hard-won experience defending enterprise perimeters:

1. Patch immediately. Upgrade all NetScaler ADC and Gateway appliances to builds 14.1-73.32 or 13.1-63.21 (or the corresponding FIPS variants) before end of business today. There is no safe deferral window for a CVSS 9.3 authentication bypass on an internet-facing gateway.
2. Run the configuration audit right now. On every NetScaler appliance, execute show ns runningConfig | grep -E "samlAction|authentication vserver|vpn vserver". Document which systems are in scope and prioritise them for emergency patching.
3. Enable NetScaler Console Global Deny Lists. If you are running firmware 14.1-60.52 or later (or 13.1-63.16 or later), activate the Global Deny Lists feature via NetScaler Console as an interim compensating control while patches are staged. This provides signature-based blocking of known exploitation patterns.
4. Review authentication logs for anomalies going back 72 hours. Although active exploitation has not been publicly confirmed, responsible hunting assumes disclosure has already attracted private attacker attention. Look for: authenticated sessions without corresponding MFA events, unusual source IPs accessing the gateway management interface, and new VPN session establishments from countries outside your normal geography.
5. Segment post-VPN access. Even if CVE-2026-19490 is not yet exploited against you, the Citrix Bleed playbook demonstrated how attackers pivot from a compromised gateway into internal systems. Enforce least-privilege network segmentation so that a compromised gateway cannot reach domain controllers, backup repositories, or financial application servers directly.
6. Audit SAML trust configurations. The vulnerability’s detection strings include SAML actions. If your NetScaler is federated to an identity provider (Azure AD, Okta, ADFS), verify that SAML assertions are cryptographically validated and that no unauthorised relying party trusts have been added.
7. Subscribe to Citrix security bulletins. Enable proactive notification at support.citrix.com/user/alerts so your team receives future advisories without delay. The official advisory reference for this bulletin is CTX696939.

A Broader Zero-Trust Lesson

CVE-2026-19490 illustrates a fundamental truth about perimeter-first security architectures: when the gateway itself fails, every control behind it becomes worthless. NetScaler appliances function as trust anchors — the devices your network relies on to verify who is allowed in. An authentication bypass at this layer does not just compromise one appliance; it potentially compromises the identity of every user session your gateway manages.

Zero-trust architecture addresses this by ensuring that successful VPN authentication is not the final control. Under a zero-trust model, every internal resource access request is independently verified, continuously evaluated, and scoped to the minimum necessary privilege — regardless of how the user authenticated at the perimeter. Organisations that have implemented zero-trust principles (micro-segmentation, device posture checks, continuous session validation) have far smaller blast radii when gateway appliances are compromised, because the attacker’s network movement is constrained even after initial access.

If your organisation is still relying on implicit trust after VPN authentication, CVE-2026-19490 is a timely reminder of the cost of that architectural debt.

Frequently Asked Questions

Is my organisation affected if we use Citrix Cloud or ShareFile instead of on-premises NetScaler?

Citrix has confirmed that Citrix-managed cloud services are not affected by CVE-2026-19490. The vulnerability exists only in on-premises NetScaler ADC and NetScaler Gateway appliances that you manage yourself. If your NetScaler is hosted on-premises or in a self-managed cloud VM, check your version and patch accordingly.

Can we mitigate the risk without patching by taking our gateway offline?

Taking a gateway offline eliminates the attack surface for CVE-2026-19490 but also eliminates remote access for your users. The more practical approach is to enable the NetScaler Console Global Deny Lists compensating control while you stage and test the firmware upgrade in a maintenance window. For organisations with stringent change management processes, the risk of an unpatched internet-facing CVSS 9.3 vulnerability should be sufficient justification for an emergency change request.

How quickly have Citrix authentication bypass vulnerabilities been exploited historically?

The track record is sobering. CVE-2023-4966 (Citrix Bleed) was exploited in mass campaigns within two weeks of disclosure. CVE-2026-8451, the earlier NetScaler SAML flaw, was exploited within 24 hours of disclosure. With over 22,000 exposed instances and a proof-of-concept likely being developed in private, security teams should budget 48–72 hours at the outside before exploitation becomes widespread.

Should we also address CVE-2026-19489 (the memory overflow flaw) at the same time?

Absolutely. Both vulnerabilities are addressed in the same firmware update, so patching one patches both. CVE-2026-19489 (CVSS 8.8) is exploitable only when SIP ALG is enabled on an LSN group, but if that configuration is present, a memory overflow in a network-facing service has the potential to escalate from DoS to code execution depending on attacker capability. Apply the patch regardless of whether you use SIP ALG, and audit whether that feature is even necessary in your environment.

Sources & Further Reading: Citrix Advisory CTX696939 · Rapid7 Analysis · The Hacker News · SecurityWeek · NVD CVE-2026-19490 · CISA KEV Catalog

The post CVE-2026-19490 (CVSS 9.3): Critical Citrix NetScaler Auth Bypass Puts 22,000+ Gateway Appliances at Risk — Patch Before Exploitation Begins appeared first on Sanjay Seth — Cybersecurity & Network Consultant.

If you run any endpoint or server on a supported Windows build, this is a “patch tonight, verify tomorrow” story. If you are a CISO in Delhi NCR, Bengaluru or Hyderabad with even a tangential relationship to aviation, aerospace, defence contracting, or MoD supply chain — it is a “patch, hunt and reset postures” story.

Why this vulnerability is a big deal — even at CVSS 7.0

The base score does not tell the whole story. afd.sys is the kernel-mode driver that sits underneath virtually every socket operation on Windows — every browser TCP handshake, every Outlook connection, every RDP session, every VPN keepalive. A memory-safety flaw in that driver is not a niche curiosity; it is a universal privilege-escalation primitive that upgrades any initial foothold, no matter how humble, into full SYSTEM.

According to SecurityWeek and The Hacker News, Lazarus operators used it as the pivot between a low-privilege phishing implant and a kernel rootkit strong enough to disable Windows security telemetry. That is exactly what the exploitability score misses — the compound risk of chaining a “7.0” driver bug with an “8.8” execution bug is functionally a 10.

The technical breakdown: what really happens inside afd.sys

CVE-2026-68820 is a use-after-free race condition. Two threads inside the WinSock driver briefly disagree about who owns a socket structure. An attacker who wins the race gets to read and write freed kernel memory. From there the exploit builds a read/write primitive, walks the EPROCESS token list, and swaps its own process token for that of the SYSTEM account. Rootkit installed. Game over.

Reports from GCN confirm compiled artefacts of the updated FudModule 3.1 rootkit carrying timestamps as early as 7 July 2026, meaning Lazarus had a working kernel exploit in production for at least five weeks before Microsoft’s August Patch Tuesday shipped a fix on 11 August.

The full attack chain

The Troy DLL implant, first documented in this campaign, exposes 17 discrete operator commands ranging from file enumeration, upload and download to interactive shell, process termination and in-memory DLL injection. ForestTiger, a long-attributed Lazarus C2, then uses compromised WordPress, SharePoint and Roundcube servers (leveraging CVE-2025-49113) to relay traffic — which frustrates network-level detection built around IOC blocklists.

Why India is on the target list

Lazarus’s targeting profile has always tracked DPRK strategic priorities: cryptocurrency theft to fund the regime and aerospace/defence intellectual property to shortcut the missile programme. What is new is the persistence of Indian-sector targeting. Independent reporting from TechTimes confirms Indian aerospace and aviation organisations were among the small, tightly scoped victim set — alongside French, German and Brazilian firms.

For any engineering firm in the HAL supply chain, private-sector satellite integrators, drone startups, MRO contractors or defence-adjacent SaaS providers, the operational reality is this: you are inside a live campaign target list, whether you know it yet or not.

What you should do — the Sanjay Seth playbook

I have run zero-trust and NOC/SOC transformation for enough Indian mid-market and enterprise clients to know that “just patch” is almost never enough for a Lazarus-grade adversary. Here is the 72-hour plan I would run for a client hit by this news today:

1. Patch — and prove it patched

• Deploy the August 2026 cumulative update to every supported build of Windows 10, 11, Server 2019, 2022 and 2025. No exceptions for “legacy jump box” or “vendor-managed VM”.
• Verify the KB version through your endpoint tool, not through WSUS reports. WSUS lies. Query Get-HotFix or your XDR patch state feed to confirm.
• Reboot. afd.sys is loaded at boot; without a reboot, the vulnerable driver stays resident even after the file is replaced.

2. Hunt for the pre-patch window

• Search endpoints for unsigned or oddly-signed PDF viewers (SecurityPDF, look-alike Foxit/Adobe binaries). Trigger on child processes spawned by any PDF reader.
• Detect VerifiedAndReputablePolicyState registry writes — that is the FudModule 3.1 tell.
• Alert on outbound HTTPS to obscure WordPress, SharePoint and Roundcube domains; Lazarus is fond of compromised low-reputation infrastructure.
• Hunt for parent-child anomalies where svchost.exe or lsass.exe spawn shell primitives — the Troy backdoor’s normal signature.

3. Reset the blast radius under zero-trust rules

• Rotate credentials, service accounts and Kerberos tickets on any host that was unpatched between 7 July and 11 August 2026. Assume tokens were harvested.
• Push every defence-, aerospace- or aviation-adjacent workload behind a FortiGate ZTNA policy that enforces device posture — Smart App Control state, patch level, EDR heartbeat — before a session is granted.
• Segment finance, HR and R&D VLANs even further; Lazarus loves lateral movement into IP-rich subnets.

4. Update user education — Dream Job is not dead

• Warn engineering, R&D and defence-project staff about LinkedIn recruiter outreach that pivots to WhatsApp, Telegram or personal Gmail and ends in an “assessment PDF”.
• Enable Attack Surface Reduction rule “Block Office applications from creating executable content”, and enforce Windows Smart App Control on managed devices.

The broader trend: modest CVSS, catastrophic reality

CVE-2026-68820 is the fourth time Lazarus has abused afd.sys since 2022. That is not coincidence — it is a mature offensive research pipeline that keeps mining a driver Microsoft has never fully hardened. Combined with the SharePoint CVE-2026-33824 IKEv2 exploitation from last week and the ongoing VMware vCenter APT campaign, August 2026 is shaping up to be the busiest month for state-sponsored kernel-level activity since the Kaseya wave of 2021.

The lesson for Indian CISOs is that vendor-issued CVSS scores are a starting point, not a final risk decision. A “7.0” that Lazarus is actively weaponising in your sector is not the same as a “7.0” sitting on a Patch Tuesday advisory. Your risk register needs to distinguish “theoretically important” from “your adversary is running this today”.

Frequently Asked Questions

Is CVE-2026-68820 exploitable remotely without authentication?

No — it is a local privilege escalation. But that is cold comfort. Lazarus is chaining it with phishing that gives the attacker a low-privilege user session first. Any RCE exploited on Windows becomes a full-SYSTEM compromise via this bug. Treat it as pre-authentication in your risk model.

Which Windows versions are affected?

All currently supported Windows client and server SKUs are affected. Microsoft’s August 2026 Patch Tuesday covers Windows 10, Windows 11, Windows Server 2019, 2022 and 2025. If you run any unsupported build (Windows 7, Server 2012 R2 without ESU), your only mitigation is aggressive isolation.

Will endpoint protection catch the exploit?

Modern EDR from CrowdStrike, SentinelOne and Microsoft Defender for Endpoint have begun issuing behavioural rules for the FudModule 3.1 pattern and Smart App Control tampering. But signature-based AV alone will miss it. The rootkit specifically neutralises Smart App Control, so do not rely on a single control layer.

My organisation is not in defence — do I still need to hurry?

Yes. Any kernel-privilege-escalation flaw of this quality is quickly re-purposed by ransomware crews within weeks. Even if Lazarus is not interested in you, the criminal ecosystem will be. The CISA KEV listing signals the flaw’s operational value across the threat landscape.

Ready to close the window before ransomware crews catch up?

Lazarus was in defence-sector networks for five weeks with a “7.0” bug. Your ransomware-affiliate adversaries need less than five days to weaponise anything in the KEV catalogue. If you would like a fast, no-nonsense review of your patch cadence, EDR coverage, ZTNA posture and Dream Job-style phishing controls, I run 90-minute strategy calls for Indian CISOs and IT leaders every week.

Book a Cybersecurity Assessment →

Explore related deep-dives on the Windows IKEv2 RCE emergency, the VMware vCenter APT campaign, and the Ray AI framework cryptomining wave.

The post CVE-2026-68820 (CVSS 7.0): Lazarus Weaponises Windows afd.sys Zero-Day Against Indian Aerospace and Defence — CISA Patch Deadline Today appeared first on Sanjay Seth — Cybersecurity & Network Consultant.