Sessions, Privileges, and the Access Attackers Didn't Earn

A quick roundup of what's making waves in security this week: a phishing campaign hijacking Microsoft 365 sessions to set up payroll fraud, a public exploit for a critical SharePoint authentication bypass already under attack, a new Microsoft Defender bypass called ShieldBreak that grants SYSTEM privileges even on patched systems, a Sandworm-linked group using fake job interviews to plant trojanized VPN software on IT professionals, and an actively exploited Cisco ASA/FTD flaw that can knock remote-access VPNs offline. Here's what you need to know about each.

Payroll Pirates: The Phishing Campaign That Steals Sessions, Not Just Passwords

A campaign called Payroll Pirates is targeting Microsoft 365 users across multiple industries, with a specific focus on payroll, HR, finance, and accounts payable functions.

What You Need to Know

Payroll Pirates uses fake voicemail notifications to lure Microsoft 365 users into an adversary-in-the-middle (AiTM) attack that can defeat MFA. Attackers don't just steal credentials, they hijack authenticated sessions, then quietly comb through mailboxes for payroll, banking, and financial workflows to exploit later. The campaign has already hit organizations in healthcare, education, manufacturing, government, and professional services.

How the Attack Works

The phishing emails impersonate voicemail alerts, complete with Microsoft branding, fabricated caller information, a message duration, and a reference number designed to look legitimate. Clicking the embedded link routes the victim through several trusted online services before landing on a fraudulent Microsoft sign-in page, a multi-stage path that makes the malicious destination harder for email security tools and users to catch.

Because the technique relies on AiTM, the fake login page sits between the victim and the real Microsoft authentication flow. A victim can enter their password and complete MFA normally, but the attacker captures the resulting authenticated session, gaining account access even though MFA was in place.

Once inside, the attackers tend to avoid obvious red flags. Rather than firing off phishing emails or resetting passwords right away, they search the mailbox and organizational data for anything tied to payroll, HR, benefits, invoices, banking, and payments. Some create inbox rules that mark messages as read or move them to Deleted Items, cutting down the odds that the victim spots security alerts or financial correspondence in time. The apparent end goal is a later business email compromise, such as redirecting a direct deposit, altering payment details, or impersonating a trusted employee in a financial transaction.

Why This Matters

This isn't a simple credential-theft scheme. Because the attacker captures a live authenticated session, standard MFA doesn't stop it, and the quiet, patient follow-through means a compromised account can sit unnoticed while attackers position themselves for a financial hit. Organizations that assume MFA alone covers them are exposed to exactly this kind of attack.

What to Do

Treat unexpected voicemail notifications and unsolicited Microsoft sign-in prompts as potential phishing, especially any that push for immediate action. Users should reach Microsoft 365 through approved bookmarks or known company portals rather than clicking email links. Security teams should audit Microsoft 365 sign-in and mailbox activity for unfamiliar devices, unusual locations, repeated session activity, suspicious inbox rules, and unusual access to payroll or finance-related messages. If a compromise is suspected, revoke sessions, reset passwords, re-register MFA, review mailbox rules, and validate any payroll or financial changes made during the exposure window. Longer term, phishing-resistant MFA, managed-device access policies, strong email filtering, and clear verification steps for payroll and banking changes go a long way toward reducing exposure to this kind of campaign.

CVE-2026-55040: Public Exploit Puts Unpatched SharePoint Servers at Immediate Risk

A critical authentication bypass in on-premises SharePoint now has a public exploit, and attackers are already using it against exposed servers.

What You Need to Know

CVE-2026-55040 lets an attacker skip authentication entirely and act as a legitimate SharePoint user or administrator. Microsoft patched the flaw in its July 2026 security updates, but a newly published technical write-up and proof-of-concept have pushed active exploitation into the wild. Organizations still running unpatched on-premises SharePoint Enterprise Server 2016 or SharePoint Server 2019, especially internet-facing instances, should treat this as an urgent patching and threat-hunting priority. SharePoint Online in Microsoft 365 is not affected.

What's Vulnerable

The flaw lives in how SharePoint validates JSON Web Tokens, the mechanism used to confirm a user's identity and access rights. Because that validation process can be bypassed, an attacker doesn't need valid credentials to impersonate a user or administrator and reach functionality that should be gated behind authentication. Successful exploitation lets an unauthenticated attacker view or modify SharePoint content as if they were an authorized user. The vulnerability doesn't take SharePoint offline, but unauthorized access to sensitive files and the ability to alter data can still produce serious operational and security fallout.

Threat intelligence researchers have already spotted exploit attempts hitting SharePoint honeypots, showing that attackers moved quickly to fold the public PoC into active operations. Internet-exposed SharePoint servers are particularly at risk since they can be found and targeted through routine automated scanning, no manual reconnaissance required.

Why This Matters

Once public exploit code exists for an authentication bypass, the window between disclosure and mass exploitation shrinks fast, and the honeypot activity shows that window has already closed for this flaw. Any organization that hasn't patched is effectively leaving an unlocked door open to automated scanning, with an attacker able to read or tamper with SharePoint content without ever proving who they are.

What to Do

Identify every on-premises SharePoint server in the environment and confirm the July 2026 Microsoft security updates are applied, prioritizing internet-exposed systems first and then checking for any unsupported or overlooked instances. Review SharePoint and web-server logs for unusual requests, unfamiliar source addresses, unexpected authentication activity, suspicious file access, or unexplained content changes. Restrict access to on-premises SharePoint to approved users and networks wherever possible, and make sure administrative accounts carry MFA and strong access controls. Because active exploitation is already confirmed, patching alone isn't enough. Pair it with targeted threat hunting to check whether an exposed server was compromised before remediation went in.

ShieldBreak: A Public 0-Day That Turns Standard Access Into SYSTEM Privileges

A newly disclosed exploit called ShieldBreak lets attackers escalate to SYSTEM-level access on fully patched Windows systems running Microsoft Defender.

What You Need to Know

ShieldBreak is a publicly released 0-day that bypasses CVE-2026-50656, a Defender vulnerability known as RoguePlanet that Microsoft patched in July 2026. It's already been tested against Windows 11 and Windows Server 2025, with Windows 10 and its server counterparts likely vulnerable even though the current PoC doesn't target them. This isn't an initial-access technique. An attacker still needs a foothold on the device first, but once they have one, ShieldBreak can hand them the highest level of access on the machine.

What's Vulnerable

ShieldBreak was disclosed shortly after Microsoft's August 2026 security updates and functions specifically when Microsoft Defender is active, effectively defeating one of the update from July. Independent reporting confirms the exploit works against systems that already received the CVE-2026-50656 fix, meaning patching that flaw alone doesn't close the door. An attacker who has already run code on a device, whether through a malicious attachment, a compromised account, an unauthorized remote-access tool, or malware delivered via another vulnerability, can use ShieldBreak to move from standard user permissions to SYSTEM. That level of access lets an attacker disable security controls, reach protected information, install persistent malware, create or modify accounts, and push deeper into a network. Because the PoC is public, there's an elevated chance the technique gets folded into malware, ransomware, or hands-on-keyboard intrusions in the near term.

Why This Matters

ShieldBreak is a reminder that a patched CVE doesn't always mean a closed door, since this technique specifically works against systems that already applied the July fix. It also raises the stakes of any successful initial-access attempt. What might have stayed a limited foothold can now escalate quickly to full SYSTEM control, giving an attacker room to disable defenses and entrench themselves before anyone notices.

What to Do

Focus first on keeping attackers from getting a foothold at all: strong email filtering, MFA, application controls, timely OS updates, and solid endpoint detection coverage. Identify every Windows system running Microsoft Defender and confirm Defender itself, Windows security updates, and endpoint telemetry are current, but don't treat patching as sufficient on its own given that ShieldBreak affects already-patched systems. Watch for unexpected SYSTEM-level processes, suspicious child processes tied to Defender activity, unexplained changes to security settings, unusual local account creation, and any behavior suggesting security tools are being disabled or tampered with. Limit local administrator privileges, restrict execution of unapproved software, and investigate malware alerts promptly. Keep an incident-response process ready that covers isolating affected systems, preserving endpoint evidence, resetting exposed credentials, and checking for lateral movement or persistence.

Sandworm's Fake Job Interviews Are Delivering Trojanized VPN Malware to IT Pros

A Sandworm-linked threat cluster is using fraudulent job interviews to trick system administrators and IT professionals into installing a backdoored VPN client.

What You Need to Know

The cluster, tracked as UAC-0145, has been running this campaign since at least May 2026, targeting IT staff who post resumes on employment sites. Posing as recruiters, the attackers move candidates into a fake technical interview process that ends with them installing a trojanized WireGuard VPN client called SopraVPN. Because the campaign specifically targets people likely to hold privileged access to corporate systems, a successful compromise can hand attackers a foothold well beyond one person's workstation.

How the Campaign Works

Attackers find targets through resumes posted on job sites, then reach out posing as recruiters or representatives of an IT company, moving the conversation to Telegram and Zoom for what appears to be a legitimate technical interview. In observed activity, the attackers impersonated the international IT firm Sopra Steria, using lookalike email addresses and a fraudulent website built to look authentic.

As part of the interview, candidates are given a mock technical assignment requiring them to connect to a supposed corporate network through a WireGuard VPN. The configuration files provided are designed to fail, which gives the fake recruiter an opening to recommend SopraVPN, a custom client that looks like standard WireGuard software but is actually trojanized. Once installed and used with the attacker's configuration file, the application decrypts and executes hidden commands. On Windows, this can create a scheduled task and pull down additional payloads from attacker infrastructure. On Linux, it can retrieve and execute a separate malicious file through the VPN connection itself.

Why This Matters

This campaign works because it exploits a hiring process people already expect to be a little unusual, a technical assessment, a VPN connection to a "test environment," and instructions from someone posing as a company representative. Combine that believable pretext with a target pool of system administrators and IT professionals, and a single successful compromise can translate directly into privileged access to corporate systems.

What to Do

Remind technical staff that recruitment-themed social engineering is a real and credible threat, especially when unsolicited contact asks them to install software, use a custom VPN client, or connect to a test environment. Employees should verify recruiters and prospective employers independently, using contact information from official company websites rather than details supplied in messages, email signatures, or interview invitations. VPN clients should only come from trusted vendors, and configuration files from unknown parties shouldn't be imported without review. Security teams should limit access to corporate resources to managed, continuously monitored devices with EDR enabled, and investigate suspicious scheduled tasks, unapproved VPN software, unexpected PowerShell activity, unusual downloads, and access attempts from unmanaged endpoints. Having a clear process for employees to report suspicious recruitment outreach gives security teams a chance to catch this kind of activity before any malware gets installed.

Actively Exploited Cisco Flaw Can Crash ASA and FTD Firewalls Remotely

Cisco has confirmed active exploitation of a high-severity flaw that lets an unauthenticated attacker force a reload on affected ASA and FTD firewalls.

What You Need to Know

CVE-2026-20349 carries a CVSS score of 8.6 and affects Cisco Secure Firewall ASA and FTD software running specific remote-access services. An unauthenticated attacker can send a crafted request that forces the device to reload, cutting off active VPN sessions and interrupting connectivity for remote workers and site-to-site links. Cisco has confirmed exploitation in the wild but hasn't shared indicators of compromise, so organizations need to move on exposure and patching now rather than wait for threat intelligence to catch up.

What's Vulnerable

The flaw stems from insufficient error checking during HTTP request processing and affects devices running SSL VPN, IKEv2 Remote Access VPN with client services, or Zero Trust Network Access on FTD systems. Cisco Secure Firewall Management Center is not affected. An attacker can trigger the vulnerability by sending a specially crafted request to the Remote Access SSL VPN service, with no valid credentials or user interaction required. Any device exposed to the internet with the affected service enabled may be susceptible.

Repeated exploitation can force a firewall into a reload cycle, turning a single denial-of-service event into an extended outage for remote workers, site-to-site connectivity, and anything else that depends on the device. Cisco has released fixed software and hot fixes for ASA releases 9.16, 9.18, 9.20, 9.22, 9.23, and 9.24, and FTD releases 7.0, 7.2, 7.4, 7.6, 7.7, and 10.0. No workaround exists, so upgrading to a fixed release is the only complete fix.

Why This Matters

This isn't a data-theft vulnerability, it's an availability one, and that makes it just as disruptive in a different way. A firewall stuck in a reload loop can knock out remote access for an entire workforce, and because Cisco hasn't released indicators of compromise, organizations can't simply scan logs for known attack patterns. The only reliable path forward is confirming exposure and patching directly.

What to Do

Identify every Cisco ASA and FTD device in the environment and check whether Remote Access SSL VPN or related services are enabled, prioritizing internet-facing systems first. Since no workaround is available, upgrading to a fixed release is the only way to fully address the vulnerability. Review device logs for unexpected reloads, repeated VPN-service failures, unusual HTTP requests, and unexplained connection interruptions. Keep current backups of firewall configurations, make sure logging is forwarded to a centralized monitoring platform, and confirm incident-response procedures account for availability attacks against network devices, not just data-focused breaches.