โŒ

Normal view

Email hijacking via OAuth | Kaspersky official blog

17 July 2026 at 18:18

When targeting an organization to steal information, maintaining a low profile is critical for attackers. They typically aim for long-term persistence, which requires avoiding security alerts while preserving access in case theyโ€™re detected and the organization initiates incident response or routine password resets. Malware such as infostealers or ostensibly legitimate remote monitoring and management (RMM) tools fail the first requirement: their use triggers EDR and generates suspicious events in SIEM consoles. Relying on stolen credentials conflicts with the second requirement: the moment the security team suspects a compromise, passwords can be changed immediately โ€” terminating access. If attackers attempt to steal browser cookies instead of passwords, they face a different challenge: many online services now correlate device characteristics with the expected session cookie and block access if the cookie is used on an unrecognized device. Furthermore, cookie theft protection mechanisms implemented in Chromium-based browsers (such as Chrome, Edge, and Opera) this year have made this approach significantly more difficult.

To address this persistence challenge, the ToddyCat APTย โ€” whose main game is spyingย โ€” developed a novel technique. Kaspersky experts discovered this method during an incident investigation and named it Shadow Token via Remote Debug (STRD). This technique allows the attackers to establish reliable, persistent access to a victimโ€™s mailbox and other resources in Google Workspace. With minor adjustments, the same approach could potentially be adapted to target other services that grant third-party application access via OAuth 2.0 authentication.

How an STRD attack works

First, the attackers must compromise the victimโ€™s system with malware. In past campaigns, ToddyCat gained initial access to organizations by exploiting known vulnerabilities in server software and distributing malicious loaders via messaging apps. The specific employee targeted by the attackers might not notice the intrusion at all. This can occur, for example, if the adversary first obtains privileged administrative credentials and uses them to deploy the malware onto targeted machines remotely. Crucially, the deployment and execution of this malware mustnโ€™t trigger immediate security alerts.

Once active, the malware executes an STRD attack, connecting the attackersโ€™ remote service to the victimโ€™s mailbox using the OAuth 2.0 protocol. This process requires no user interaction and shows no visible activity on the screen. To the cloud environment (Google Workspace, in the case at hand), the activity appears as if the user has legitimately authorized a third-party app for email access or data backup.

After that, the malware can terminate its operations and even delete itself from the system. The adversary retains direct access to the mailbox using the acquired OAuth tokenย โ€” and they need no connection to the victimโ€™s endpoint or to the corporate network for that. Depending on the organizationโ€™s Google Workspace configuration, this access can persist for an extended period and survive subsequent password resets.

The core concept of Shadow Token via Remote Debug

At the heart of this attack is a connection to Google Workspace services via OAuth 2.0. This is a legitimate workflow used whenever a third-party application requests access to calendar data, emails, or Google Drive files. For example, to display calendar meetings in Zoom and automatically generate conference links, a user must authorize Zoom to access Google services. Similarly, configuring a third-party email client or calendar app requires granting permission. During this authorization process, the service requesting access opens a new browser window. In this window, Google Workspace first prompts the user to select the appropriate account. Once the account is chosen, the subsequent screen displays the specific permissions requested by the third-party app, allowing the user to either approve or deny access. For this scenario to proceed seamlessly, the user must already be authenticated to Google services in their browserย โ€” which is typically the case in organizations using Google Workspace. If the user isnโ€™t authenticated, additional steps for entering credentials and completing multi-factor authentication are introduced into the sequence.

The ToddyCat hackers developed a malicious tool called Umbrij to facilitate a two-step covert authorization process when the user is already authenticated in Google. First, the malware identifies the browsers installed on the system, and locates the specific folder storing the userโ€™s active profile for each. The attackers target Chrome and Edge, as these are the browsers most likely serving as the primary ones within the organization.

Next, Umbrij copies the entire user profile folder to a different directory on the machine. It then launches an instance of the browser, specifying the path to the duplicated profile via the command line. Because this duplicate profile contains the userโ€™s session cookies, websites with saved credentials wonโ€™t prompt for re-authentication. Furthermore, since this occurs on the exact same computer where the primary browser is running, online services detect no anomalies. The browsing history for this newly launched instance is isolated within the new folder, keeping it hidden from the userโ€™s main account activity.

Crucially, the browser is launched in a dedicated debugging mode typically reserved for web development. The browser window and user interface donโ€™t appear on the screen at all (headless mode). Instead, the browser can be controlled through a debugging port using the DevTools protocol, allowing the malware to issue commands and read the state of the screen. To orchestrate these actions, Umbrij leverages Puppeteer, a legitimate automation library.

After verifying that the debugging browser instance has launched successfully, Umbrij opens a legitimate Google Workspace OAuth screen within it. The request sent to Google is engineered to bypass additional security checks while requesting maximum access privileges. For the application IDย โ€” the identity supposedly requesting these extensive permissionsย โ€” the malware impersonates one of two legitimate tools: Google Workspace Migration for Microsoft Outlook (GWMMO), or Google Workspace Sync for Microsoft Outlook (GWSMO).

When Google opens the window within the headless browser, Umbrij uses debugging tools to programmatically click on the corporate account name and the confirmation buttons. As a result, Google generates an authorization code for the app. Umbrij extracts and saves this code, subsequently forwarding it to the attackersโ€™ command-and-control server. Finally, operating entirely within their own infrastructure rather than on the victimโ€™s computer, the attackers exchange this authorization code for an OAuth access token. This single token is all they need to maintain long-term unrestricted access to the mailbox.

How to protect against OAuth token theft

If a Google Workspace account is compromised, incident response measures must include the following steps after collecting the necessary logs and other forensic data for investigation:

  • Resetting the affected userโ€™s password
  • Terminating all active web sessions for the user
  • Revoking OAuth tokens and third-party app permissions
  • Reviewing and removing access granted through legacy App Passwords

In addition, security and IT teams must systematically audit issued OAuth permissions, revoke unjustifiable access rights, and restrict capabilities that allow excessive or unauthorized permission grants. We covered this topic in detail in our article on blocking unwanted AI assistants.

How to prevent exploitation of Shadow Token via Remote Debug

While Kaspersky users are protected against the Umbrij tool, security teams should proactively implement policies that prevent standard users from launching browsers in debugging mode. This functionality is intended exclusively for website and web app developers. This restriction can be enforced through the DeveloperToolsAvailability group policy (available for both Chrome and Edge).

Additionally, configure monitoring within your SIEM/XDR to track the launch of browser instances with an active debugging port. This event serves as a strong indicator of this specific attack technique.

A Defining Moment in Identity Security

30 June 2026 at 18:28

Artificial intelligence (AI) is changing the enterprise faster than most security models were built to handle. In just a few years, it has become part of everyday enterprise work. And soon, AI agents will do much more than provide assistance. They will act autonomously across applications, workflows, data stores and infrastructure.

This shift is already changing the security conversation โ€“ as it should. When agents can act on behalf of users, systems and business processes, identity is no longer a supporting layer of cybersecurity. It becomes the control plane for deciding who or what can act, what they can access, how much privilege they should have and when that access should be removed. Fragmented tools werenโ€™t built to support this level of real-time visibility and control. It requires a unified identity security platform.

Palo Alto Networks recent acquisition of CyberArk reflects our conviction that identity is a core platform pillar for securing the future of AI. Identity security is now a foundational layer across our portfolio, building on CyberArk's trusted privileged access management (PAM) heritage and extending it to address the complexity of hybrid, cloud-native, and AI-driven environments. It also advances Palo Alto Networks broader platformization strategy, driven by customer demand for integrated, AI-powered security solutions that reduce complexity and close gaps created by disparate point products.

For partners, the launch of Idiraโ„ข, our next-generation identity security platform, represents a significant opportunity to help customers secure access, privilege and identity risk through a more unified platform approach. More than ever, our customers need knowledgeable, trusted advisers to help them rethink how identity connects to the rest of their security architecture across network security, cloud, security operations (SecOps) and the broader AI-enabled enterprise.

Identity Security is No Longer Human-Centered

Research for our 2026 Identity Security Landscape report found that 96% of organizations have human identities operating with access far beyond what is required for their roles. That finding is unsettling enough, but also consider how modern identity security must account for far more than human users and privileged administrators. It includes machine identities and AI agent identities, ranging from service accounts, workloads and APIs to secrets and certificates and to agents operating across multiple systems.

Our recent report on identity security also notes that there are now roughly 109 machine identities for every human identity. Each identity can carry privilege, create risk and expand the attack surface. That scale makes real-time discovery, governance and control of identities essential. Yet many organizations are still managing privilege in ways that werenโ€™t built for the AI era. When identities can act across systems and attacks can move faster, standing privilege (i.e., always-on access rights granted to users or machines) becomes harder to defend.

The premise of Idira is that every identity within an enterprise is privileged. The platform helps enterprises move from the traditional operating model of human-centered identity architectures and static access tools to embrace one platform that secures every identity โ€“ human, machine and AI agent. Idira discovers identities, entitlements and access paths, dynamically applies privileges through just-in-time controls and continuously governs identity lifecycles.

These capabilities become even more crucial as customers work to reduce fragmentation across their security environments. They want better visibility, faster time to value, stronger controls and a simpler way to manage risk across the enterprise. They still need advisory, implementation and managed services expertise, but the conversation is no longer limited to firewalls, privileged access, cloud workloads or SOC operations in isolation. Customers want expert help in connecting these areas into a unified strategy that reflects how their environments actually operate, especially with AI in the mix.

The Identity Security Opportunity for Partners

My message to partners following our launch of Idira is simple but direct: Now is the time to seize this defining moment in identity security. The speed of business is accelerating, as is the speed of attacks. And we know many of our customers around the world are already trying to understand what AI means for their security architecture, operating model and risk posture.

Partners can help lead those conversations with customers. For specialized and regional partners, this might mean expanding the advisory conversation beyond a single domain of cybersecurity. For global systems integrators, it might involve creating a more scalable delivery model by reducing the cost and complexity of stitching together multiple vendor environments. We are also actively welcoming partners into the broader Palo Alto Networks ecosystem, creating new opportunities for identity-focused partners to expand their role across the full platformization strategy.

Across partner types, the identity security opportunity is both strategic and economic. By connecting identity security to the broader Palo Alto Networks platform strategy, partners can expand services offerings, deepen customer relationships and build a stronger model for helping customers reduce complexity, improve visibility, strengthen controls and get to value faster.ย 

But first, sales teams, technical teams, solution consultants and managed service teams need to understand how Idira fits into the Palo Alto Networks platformization strategy and where identity security connects to customer priorities. That means taking full advantage of the sales demos, AI role plays, technical enablement and other active learning resources in Palo Alto Networks newly evolved NextWave program.

I encourage you to move quickly to build your understanding of Idiraโ€™s role in securing human, machine and AI agent identities and the shift from standing privilege to dynamic access. Be prepared to talk with customers about identity security in the context of cloud, network, SASE and SOC transformation, as you can be assured questions will be coming. Also, think about the services and offerings you can build around this opportunity. Identity security assessments, privilege modernization, machine identity protection, AI agent identity readiness and broader platformization road maps can all help customers take practical steps toward strengthening security in the rapidly evolving AI era.

Our partners play a frontline role in driving Palo Alto Networks platformization strategy and enabling our shared success. To help your teams educate customers about AI-related identity risk and how Idira can help them secure every identity in the enterprise, human or not, explore the latest resources, enablement and partner tools available through the NextWave Partner Portal.

Key Takeaways

  • With the launch of Idira, identity security became a core pillar of Palo Alto Networks platformization strategy for the AI era.
  • Idira helps organizations secure every identity โ€“ human, machine and AI agent โ€“ with dynamic access, continuous governance and real-time control.
  • Partners have a timely opportunity to help customers reduce complexity, improve visibility and connect identity security to broader cloud, network, SASE and SecOps priorities.

The post A Defining Moment in Identity Security appeared first on Palo Alto Networks Blog.

โŒ