Stolen Sessions, Borrowed Privilege: Where Attackers Are Focused Right Now

We cover five stories with a shared thread: attackers getting further by borrowing legitimate authority than by breaking anything outright. A vishing campaign linked to UNC6671 is stealing session cookies from finance firms through fake MFA calls, while a separate AiTM phishing operation is doing the same to Microsoft 365 users in payroll and finance roles. On the technical side, a public exploit for a macOS kernel flaw and a look at XSS-to-RCE chains in CMS platforms both show how a small foothold can turn into much more. And Chrome's latest update closes 41 vulnerabilities, 6 of them critical, a good reminder that patching is still the simplest defense. Details on each below.

Financial Firms in the Crosshairs of a Vishing-Driven Extortion Network

A wave of voice phishing attacks against major hedge funds and private equity firms has been tied to UNC6671, the group behind the BlackFile extortion brand, and it's a reminder that identity, not malware, is the weak point attackers are chasing.

What You Need to Know

Google Threat Intelligence Group and Mandiant have attributed recent vishing intrusion attempts against Point72, Millennium, Two Sigma, Citadel, and several private equity firms to UNC6671, a group tracked as the operator behind the BlackFile, Redact, Pink, Helix, and Falcon extortion brands. Two Sigma says it blocked the attempt with no impact to its systems, while Point72 has told investors its initial review found no client data stolen. The bigger story is what this group does once it gets in: convince an employee over the phone to reset MFA, then use that foothold to walk straight into Microsoft 365 or Okta.

One Group, Five Brands

UNC6671 announced BlackFile's retirement in May 2026, but GTIG has continued tracking the same infrastructure and tactics operating under new names, Redact, Pink, Helix, and Falcon. Analysts assess these are extortion fronts for a single intrusion network rather than separate rivals, based on shared phishing infrastructure, overlapping victim targeting, and identical phishing kit code appearing across domains tied to different brands. Not everyone agrees with that read. The Falcon group has publicly disputed the attribution, stating it operates solely as a Redact affiliate with no shared operators, tooling, or proceeds with Helix, Pink, or any other named group. Whatever the internal org chart looks like, the group's targeting has moved steadily up the value chain, from manufacturing, healthcare, and hospitality earlier in the year to, by July 2026, private equity firms, law firms, and financial rating agencies, the kind of targets sitting on confidential deal and litigation data that raises the price of staying quiet.

How the Break-In Happens

The attack starts with a phone call, not an email. Operators spoof a company's real helpdesk number and call an employee's personal mobile, telling them they need to enroll a passkey or update their MFA settings as part of an urgent security migration. The call directs the victim to a lookalike company domain hosting adversary-in-the-middle phishing infrastructure, which captures both the login credentials and the active session cookie in real time. From there, attackers log into the compromised Microsoft 365 or Okta account and pivot through the SSO dashboard into every connected cloud service tied to it, using automated tools to enumerate and pull data at scale. To buy time, operators also delete password-reset confirmations and security alert emails from the mailbox, so the account owner has no warning that anything changed.

Why This Matters

This campaign works because it targets people, not infrastructure. No firewall or endpoint tool stops an employee who genuinely believes they're talking to their own IT department. And because the entry point is a personal phone call, it sidesteps most of the technical controls organizations already have in place. For financial services and professional services firms specifically, the payoff for attackers is bigger too. GTIG tracked more than $10.6 million in Bitcoin payments to UNC6671-linked wallets between January and May 2026, with initial demands reportedly reaching $3 million and settlements more often landing around $750,000. Firms holding deal documents, client financials, or litigation files are exactly the kind of leverage that supports demands at that scale.

What to Do

Treat any request involving MFA enrollment, passkey setup, or account recovery as something that requires independent verification, especially if it arrives as a phone call to a personal device. That means calling back through a pre-registered number or an established in-app channel, not the number the caller provides. Security teams should prioritize detections for new device fingerprints, sign-ins that follow closely after an MFA or account change, session cookie reuse, mailbox rule changes, and unusual deletion of security notification emails. Since this group is tracked across five different leak-site brands, monitoring should focus on the underlying UNC6671 infrastructure and TTPs rather than any single brand name. Given the dollar amounts involved, it's also worth making sure legal, incident-response, and stakeholder communication plans are ready before a call like this ever comes in, not after.

A Public Exploit Just Raised the Stakes on a macOS Kernel Bug

Apple has patched a kernel vulnerability in macOS's DTrace subsystem, and technical details plus working exploit code are now public, which changes the urgency calculus for anyone managing a macOS fleet.

What You Need to Know

CVE-2026-39868 is a kernel memory corruption flaw in macOS's DTrace tracing subsystem, and a proof-of-concept exploit is now publicly available on GitHub. Apple describes the root cause as improper input validation and has already shipped fixes, but the public PoC means the bar to weaponize this bug has dropped significantly. Organizations running unpatched macOS systems, particularly developer workstations and admin endpoints, should treat this as a priority update.

What's Vulnerable

The flaw lives in how DTrace processes DTrace Object Format (DOF) data. An unprivileged local user can craft malicious DOF data that gets deferred for processing at the kernel level, where insufficient bounds validation and an integer overflow allow out-of-bounds memory access. Apple's advisory doesn't characterize this as arbitrary code execution, but kernel memory corruption on its own is serious, and it can enable local privilege escalation or system instability when paired with other exploit techniques.

Why This Matters

Exploiting this bug requires local code execution, so it's not a way for an attacker to break into a system on its own. But that's rarely the whole story in a real attack. Threat actors routinely get an initial foothold through phishing, malicious downloads, compromised developer tools, or an unrelated application vulnerability, then chain in a local privilege escalation flaw like this one to weaken endpoint controls, reach protected data, disable security tooling, or dig in for persistence. With the exploit now public, less skilled attackers can adapt it for exactly that purpose, which is why this matters most for developer workstations, administrative endpoints, and any device where users can install or run untrusted software.

What to Do

Apple fixed CVE-2026-39868 in macOS Sequoia 15.7.8, macOS Sonoma 14.8.8, and macOS Tahoe 26.5.2. Identify any systems still running below these versions and prioritize updates for high-value users and devices with local administrator access first. Don't rely on deployment status alone. Validate actual installation through endpoint management telemetry. Until every device is patched, limit execution of unsigned or untrusted applications, enforce least privilege, and review any exceptions that grant users administrative rights. Endpoint detection teams should also watch for unusual DTrace-related process activity, unexpected privilege changes, suspicious application launches, and crash patterns that could point to a failed exploitation attempt.

As kernel-level bugs like this one show, local privilege escalation flaws deserve a permanent spot in macOS risk management, especially once the technical details are out in the open for anyone to use.

When a Completed MFA Prompt Doesn't Mean You're Safe

A widespread phishing campaign is hijacking Microsoft 365 accounts by proxying the real login process in real time, and it's specifically hunting for the people who touch payroll, finance, and payments.

What You Need to Know

An active adversary-in-the-middle (AiTM) phishing campaign is targeting Microsoft 365 users to identify personnel involved in payroll and finance workflows. Rather than trying to defeat MFA outright, attackers relay the legitimate Microsoft login process through a proxy, capturing the resulting session token and using it to access the account as the victim. The goal isn't immediate disruption. It's quiet reconnaissance to set up more convincing fraud down the line, which makes this a serious risk for anyone handling money movement or sensitive financial communication.

How the Attack Works

The campaign starts with voicemail-themed phishing emails that route victims through a multi-stage redirection chain, leaning on legitimate services and cloud-hosted infrastructure to slip past reputation-based email filters. That chain ends at a proxy-based phishing page that mirrors Microsoft's real authentication flow, capturing credentials, MFA responses, and, critically, the authenticated session token itself. Because the attackers are relaying a genuine login rather than forging one, a completed MFA challenge gives no real assurance that the session is safe.

What Attackers Do With Access

Once inside, the operators favor patience over speed. They route malicious sign-ins through residential proxies so the traffic looks like ordinary consumer activity, and they refresh compromised sessions on an approximately eight-hour cycle to stay under the radar. From there, they read mailboxes, map organizational roles, and study communication patterns to identify finance personnel, payment processes, and vendor relationships. That intelligence sets up more convincing business email compromise, invoice fraud, payroll diversion, or targeted social engineering later on.

Why This Matters

This campaign is a clear example of why email filtering and standard MFA aren't enough on their own. If an attacker can proxy a real authentication session and walk off with the token, they've bypassed both controls without needing to break either one. And because the post-compromise activity is deliberately quiet, reconnaissance instead of immediate account takeover, it's built to avoid the kind of behavior that typically trips detection.

What to Do

Prioritize phishing-resistant authentication where it's operationally practical: FIDO2 security keys, passkeys, or certificate-based authentication. Layer in Conditional Access policies that account for managed-device status, sign-in risk, location, and application sensitivity, and use session controls to cut down on token replay opportunities. Security teams should watch for Microsoft 365 sign-ins from residential proxy infrastructure, unusual geographies, unfamiliar devices, or unexpected user agents, especially when they're followed by rapid mailbox searches, Microsoft Graph activity, or access to finance-related mailboxes. If you suspect an AiTM compromise, a password reset alone isn't enough. Revoke active sessions and refresh tokens, review OAuth consent grants, inspect mailbox forwarding and inbox rules, validate recent MFA method changes, and check email activity for signs of payment-related reconnaissance.

Defending against this kind of attack means treating identity sessions themselves as something worth protecting, not just assuming that a completed login proves the session is trustworthy.

Six Critical Flaws Anchor This Month's Chrome Patch

Google has shipped a Chrome update fixing 41 security vulnerabilities, and six of them are critical memory-safety bugs worth prioritizing across your fleet.

What You Need to Know

Google's latest Chrome Stable Channel update addresses 41 vulnerabilities spanning graphics, rendering, JavaScript, media, UI, and authentication components. Six of those are rated critical, and all six are memory-safety issues in components that process untrusted web content, meaning a malicious or compromised website could trigger them without any unusual user action. The update brings Chrome to version 151.0.7922.108 on Windows and Linux, and to 151.0.7922.108/.109 on macOS.

What's Vulnerable

The critical flaws include use-after-free conditions in WebGL, Aura, Skia, and Views, along with an out-of-bounds write in ANGLE, Chrome's graphics translation layer. Two of the WebGL bugs, CVE-2026-19137 and CVE-2026-19170, are both critical use-after-free issues, and CVE-2026-19172 is a critical use-after-free in the Views UI framework. These vulnerability classes can cause browser crashes, corrupt memory, or, in some cases, lead to arbitrary code execution when an attacker convinces a user to load specially crafted web content. The remaining critical issues sit in graphics and rendering components that handle complex web content and interact directly with the operating system's graphics capabilities.

Why This Matters

Browsers are a constant target because they're built to process content from sources you don't control: websites, ads, documents, and embedded applications. A successful exploit can hand an attacker code execution in the context of the signed-in user, which opens the door to accessing locally stored data, dropping additional malware, or chaining the bug with a sandbox escape or local privilege escalation for deeper access. That risk is highest for users with administrative rights, access to sensitive business systems, or responsibilities tied to finance and technology operations.

What to Do

Treat this update as a priority endpoint-management task. Enterprise administrators should confirm that managed Windows and macOS devices have reached version 151.0.7922.108/.109 and that Linux systems are on 151.0.7922.108 or later. Because Chrome can download an update automatically but won't apply it until the browser restarts, patch reporting should distinguish between downloaded and installed versions rather than treating them as the same thing. Security teams should also watch for browser processes spawning unusual child processes, unexpected downloads, suspicious extension activity, or other signs of attempted exploitation in web traffic. No active exploitation has been publicly reported for these specific flaws, but with six critical memory-safety bugs in one release, fast patch deployment is the most effective way to close the window.

When a Browser Bug Becomes a Server Problem

Cross-site scripting gets treated as a browser-only issue, but in the wrong environment, it's a straight path to server-side code execution. Here's why the difference in privilege matters more than the vulnerability class itself.

What You Need to Know

XSS is usually associated with session theft or page defacement, contained to whatever the victim's browser can do. But in content management platforms like WordPress and Joomla, a successful XSS attack against a privileged administrator can escalate all the way to server-side code execution, provided the admin account has access to file modification, plugin management, template editing, or configuration changes. The vulnerability itself doesn't run commands on the server. What matters is whose authority the attacker's JavaScript inherits, and what that authority is allowed to do.

How XSS Becomes a Server-Side Problem

The critical distinction is that XSS doesn't execute anything on the server directly. It lets an attacker's script act with the authority of whoever is logged in when it runs. If that's a low-privileged user, the blast radius is small. If it's an administrator who routinely reviews untrusted content, and the platform hands administrators powerful controls like direct file writes or plugin installation, the same vulnerability class becomes a path to full compromise. The attacker's script simply uses the trusted application features already available to that account to place or invoke malicious server-side code.

Where to Look in Your Own Environment

Severity isn't fixed to the vulnerability type. It depends on context, so security teams should be asking specific questions about their own CMS deployments: which roles can trigger injected content, whether sensitive actions require reauthentication, whether administrative interfaces allow direct file writes, and whether web-server permissions let application-owned files execute. An XSS finding that looks minor in isolation can look very different once you map out what the affected account is actually allowed to do.

Why This Matters

This is why vulnerability severity needs to be assessed in context rather than by class alone. The same technical flaw can be a nuisance in one environment and a critical incident in another, depending entirely on what privilege level it reaches and what that privilege level is permitted to touch. Treating XSS as a potential privilege-escalation pathway, rather than a narrow client-side defect, changes how it should be prioritized and defended against.

What to Do

Defense-in-depth is the right approach here. Enforce context-specific output encoding, sanitize rich-text input with proven libraries, implement restrictive content security policies, and use the HttpOnly and SameSite cookie attributes to cut down on session abuse. Administrative sessions deserve extra protection: require MFA and keep admin activity separated from day-to-day browsing. On the CMS side, limit what a compromised administrator account can actually do. Disable built-in file editors where feasible, restrict plugin and theme installation to controlled deployment processes, and make sure web services can't write executable content into publicly accessible directories. File-integrity monitoring can catch unexpected changes to plugin, template, and administrative paths, while endpoint and web telemetry can help flag anomalous administrator actions, newly created files, or unusual outbound connections from web servers.