TL;DR: Scattered Lapsus$ Hunters and related crews have repeatedly bypassed endpoint-first defenses by starting with account takeover, then using stolen credentials, social engineering, OAuth abuse, and help desk manipulation to reach SaaS, SSO, and ransomware-impacting systems, according to Push Security. The control problem is not malware resistance but identity governance that still assumes access paths are stable, reviewable, and contained.
At a glance
What this is: This analysis shows how Scattered Lapsus$ Hunters and related crews rely on account takeover, identity abuse, and SaaS pivots rather than endpoint exploits.
Why it matters: It matters because IAM, PAM, NHI, and help desk controls all become part of the attack surface when identity compromise is the entry point.
By the numbers:
- The MGM hack resulted in a 36-hour outage, a $100M hit to its Q3 results, one-time cyber consulting fees in the region of $10M, and a class-action lawsuit later settled for $45M.
- The Marks & Spencer ransomware breach resulted in online shopping services being taken offline, stores running low on products, £300M in lost profits, and almost £1B wiped off the company’s stock market valuation at one stage.
- Attackers claim to have stolen over 1.5 billion records from 1000+ companies across multiple verticals, including heavyweights like Google, Cloudflare, Workday, Adidas, FedEx, Disney, LVMH, and many more.
👉 Read Push Security's analysis of Scattered Lapsus$ Hunters breach patterns
Context
Account takeover is the recurring starting point in the Scattered Lapsus$ Hunters pattern. Instead of breaking perimeter controls or deploying malware first, these crews log in through stolen credentials, social engineering, malicious OAuth grants, or help desk abuse, then move through the business apps that already hold data and privilege. For IAM teams, that means identity is not just a gate to protect. It is the primary path attackers now use.
The article also shows why traditional control models keep missing the real problem. Endpoint and network tools see too little of browser-based and SaaS-led abuse, while identity programmes often treat MFA, SSO, and support workflows as separate controls rather than one attack chain. That is a typical enterprise blind spot, not an edge case.
Key questions
Q: What breaks when attackers use stolen credentials instead of malware to start a breach?
A: When attackers begin with valid credentials, traditional endpoint and perimeter controls lose much of their value because the login looks legitimate. The failure is usually in identity governance, not authentication alone. Organisations need visibility into session behaviour, app consent, and privileged recovery paths so a real account used maliciously can be separated from normal user activity.
Q: Why do stolen sessions and OAuth grants increase breach risk so quickly?
A: Stolen sessions and delegated app grants let an attacker operate inside normal workflows without repeatedly proving identity. That shortens the time from access to data theft because the attacker is already trusted by the application. Security teams should therefore treat session duration, consent scope, and connected-app review as active controls, not administrative housekeeping.
Q: What do security teams get wrong about help desk identity resets?
A: They often treat support resets as routine service rather than privileged security events. In practice, a password reset, MFA reset, or device rebind can become a full account takeover path if the workflow is not strongly verified and separately approved. Support teams need hard limits on what they can change and when escalation is mandatory.
Q: Who is accountable when identity support workflows are abused in a breach?
A: Accountability sits with the organisation that allowed recovery and federation workflows to be too easy to exploit. The relevant control owners are IAM, IAM operations, help desk leadership, and security governance. Frameworks such as NIST CSF and identity governance policies expect high-risk access changes to be controlled, logged, and reviewable.
Technical breakdown
Account takeover as the entry layer for SaaS intrusion
These campaigns begin with identity compromise, not software exploitation. Attackers harvest credentials through phishing, infostealers, session cookie theft, or vendor support scams, then use those identities to enter SaaS or SSO environments. Once inside, the login often looks legitimate because the actor is using valid authentication artefacts rather than malware or a noisy exploit. That is why browser-based and cloud-native attacks are so hard to see with legacy monitoring. The relevant control problem is not just authentication strength. It is whether the organisation can distinguish a valid login from a malicious one when the actor already has access.
Practical implication: treat account takeover detection, conditional access, and support escalation paths as one control plane, not separate programmes.
Why stolen session cookies and malicious OAuth grants persist
Session cookies and OAuth grants bypass many of the assumptions built into password-centric security. A stolen session cookie can preserve authenticated access without re-entering credentials, while a malicious OAuth integration can gain delegated access to data or APIs that the user would never manually exercise at that moment. In both cases, the identity layer is being used exactly as designed, but against the organisation. This is why ghost logins, over-broad app consent, and weak app review become so attractive to attackers. They let the adversary operate inside normal business workflows instead of forcing an obvious intrusion event.
Practical implication: review session lifetime, app consent, and delegated access as attack surfaces, not just administrative conveniences.
Help desk abuse turns identity support into privilege escalation
Help desk social engineering works because many organisations still allow support teams to make high-risk identity changes without strong step-up verification or workflow segregation. Once an attacker convinces support staff to reset MFA, approve a device, or alter federation, they can pivot from a standard user account to privileged access. In several breaches in this pattern, that support-mediated jump was the decisive escalation point. The architectural weakness is not the help desk alone. It is the lack of hard controls around identity recovery, delegation, and high-risk account changes.
Practical implication: impose separate approval paths for privileged identity recovery and device or federation changes.
Threat narrative
Attacker objective: The objective is to convert valid identity access into monetisable control through theft, extortion, and operational disruption.
- Entry occurs through phishing, stolen credentials, session cookies, malicious OAuth consent, or help desk social engineering into SaaS and SSO environments.
- Escalation happens when attackers abuse trusted sessions, delegated app permissions, or support workflows to reach privileged accounts and connected systems.
- Impact follows when the adversary exfiltrates data, deploys ransomware, or pivots from cloud apps into downstream infrastructure and business operations.
Breaches seen in the wild
- Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
- Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Account takeover has become the universal breach primitive for modern SaaS crime. Scattered Lapsus$ Hunters are not succeeding because they are more sophisticated in exploitation. They are succeeding because enterprise identity controls still leave room for valid sessions, delegated apps, and recovery workflows to be turned against the organisation. For IAM leaders, the relevant question is no longer whether identity is part of the attack path. It is whether the programme can detect malicious use of legitimate identity before data movement begins.
Endpoint-first security is structurally incomplete against browser-led identity abuse. The article shows attackers moving around malware and software exploitation to operate directly through cloud apps, SSO, and browser sessions. That means the breach surface now sits inside authentication, federation, and support processes as much as it does inside devices. Organisations that still separate endpoint, cloud, and identity operations will miss the attack chain until the damage is already done. Practitioners need a single view of access, session, and delegated privilege.
Ghost logins are not just a detection problem, they are a governance failure. The pattern recurs because organisations still tolerate stale sessions, over-permissive app grants, and recovery paths that can be socially engineered. Those are not isolated technical defects. They are evidence that access lifecycle, consent governance, and support escalation are not being managed as one discipline. The implication is that identity assurance cannot stop at login success. It must extend through the full privilege lifecycle.
Runtime trust debt: this attack pattern shows how much implicit trust enterprises accumulate in sessions, help desks, and delegated apps. The more business-critical access depends on those transient artefacts, the easier it becomes for criminals to convert ordinary identity operations into breach paths. Practitioners should treat that trust debt as measurable exposure, not background noise.
For NHI and human identity teams, the lesson is the same: standing trust is now an attacker resource. Whether the compromise starts with a service account, an SSO session, or a support agent’s reset authority, the breach outcome depends on which identities can still do too much after initial access is obtained. That should push identity governance toward tighter recovery controls, narrower delegation, and stronger visibility into who can change trust state.
From our research:
- The MGM hack resulted in a 36-hour outage, a $100M hit to its Q3 results, one-time cyber consulting fees in the region of $10M, and a class-action lawsuit later settled for $45M, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- Attackers claim to have stolen over 1.5 billion records from 1000+ companies across multiple verticals, showing how account takeover can scale into industrialised exfiltration.
- From our research: See The 52 NHI breaches Report for linked real-world cases, then compare the identity lifecycle failures in Ultimate Guide to NHIs , Key Challenges and Risks.
What this signals
Runtime trust debt: enterprises are still accumulating trust in sessions, recovery workflows, and delegated apps that attackers can turn into breach paths. As the article shows, the problem is not simply whether authentication succeeds. It is whether identity operations have become so reusable that a single takeover can cascade into cloud data theft, ransomware staging, or downstream compromise.
Teams should expect browser-led identity abuse to keep expanding because it sits in the gap between endpoint tools and classic IAM controls. The practical response is to unify session telemetry, support changes, and app consent review so identity events are investigated as one continuous chain, not as separate admin tasks.
The signals to watch are ghost logins, stale OAuth consents, recovery changes on privileged accounts, and unusually fast movement from login to export activity. Those indicators tell you whether your IAM programme is measuring trust state, or merely recording successful authentication.
For practitioners
- Harden identity recovery paths Require separate verification and approval for MFA resets, device registration, federation changes, and privileged account recovery. Do not allow a help desk workflow to become a unilateral privilege escalation path.
- Audit delegated app access Review OAuth grants, connected apps, and session persistence for excessive scope, stale consent, and ghost logins. Remove dormant integrations and force re-consent where the business owner cannot justify the access.
- Unify cloud and identity monitoring Correlate SaaS login events, browser session signals, support desk changes, and downstream data exports so suspicious legitimate access can be investigated as one chain.
- Segment privileged operations from standard support Put high-risk identity changes behind separate workflows, stronger approvers, and clear break-glass rules. A support ticket should not be enough to alter federation or privileged access.
- Track browser-based attack surface Treat malicious OAuth grants, risky extensions, and session hijacking as first-class identity threats because many of these campaigns happen entirely inside the browser.
Key takeaways
- Scattered Lapsus$ Hunters illustrates a shift from exploit-led intrusion to identity-led access, which changes where defenders need to focus.
- The scale of the damage in recent breaches shows that account takeover can translate into outage, extortion, and board-level cost very quickly.
- The most effective limiters are tighter recovery controls, narrower delegated access, and monitoring that treats identity actions as a single attack chain.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Identity compromise and token abuse are central to this attack pattern. |
| NIST CSF 2.0 | PR.AC-1 | Repeated account takeover shows access control and recovery governance are failing. |
| NIST Zero Trust (SP 800-207) | SP 800-207 | The article shows why trusted sessions cannot be assumed safe after initial authentication. |
Tighten access control and identity recovery processes so privileged changes require explicit verification and logging.
Key terms
- Account Takeover: Account takeover is the unauthorised use of a valid identity to access systems, data, or administrative functions. In modern SaaS environments, it often succeeds without malware because the attacker reuses real credentials, active sessions, or delegated access rather than breaking the authentication system itself.
- Ghost Login: A ghost login is a valid-looking session that should no longer exist or should not be trusted, often created by stolen cookies, stale tokens, or incomplete offboarding. It matters because attackers can blend into legitimate traffic and continue using access long after the original user should have lost it.
- Delegated Access: Delegated access is permission granted to an application or connected service to act on a user or tenant’s behalf. In practice, it can become a high-risk trust channel when the scope is too broad, the consent is poorly reviewed, or the integration is later abused by an attacker.
- Recovery Workflow: A recovery workflow is the process used to restore access after an account lockout, forgotten factor, or device issue. It is a governance control as much as an operational one, because weak verification or overly broad support privileges can turn recovery into a privileged escalation path.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
This post draws on content published by Push Security: Scattered Lapsus$ Hunters breaches and the evolution of identity-led attack TTPs. Read the original.
Published by the NHIMG editorial team on 2025-11-13.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org