How can organisations defend against LAPSUS$?

How LAPSUS$ defence actually works in practice

LAPSUS$ is best defended against as an identity-led intrusion pattern, not just a malware problem. The group’s campaigns have repeatedly relied on stolen credentials, MFA fatigue, help-desk social engineering, and access to high-value consoles, so the most effective controls are the ones that harden authentication, reset workflows, and privilege boundaries rather than only endpoint tooling.

That means organisations should treat sign-in flows, recovery flows, and privileged access paths as the primary attack surface. If an attacker can reset a factor, coerce a help desk, or reuse a stolen session, they may not need to “break in” in the traditional sense.

Controls that reduce takeover paths

Start with phishing-resistant MFA for administrators, developers, and anyone with access to cloud, identity, or source-code systems. Then make account recovery and factor changes harder to abuse by requiring stronger verification for resets, alerting on factor enrolment changes, and separating help-desk approval from the person requesting the change.

Least privilege matters most where a compromise can pivot quickly, especially in identity providers, source control, collaboration platforms, and cloud management planes. Access should be narrow, time-bound where possible, and reviewed for standing privilege that is broader than the job requires.

Use the Threat Actor Groups Guide to anchor LAPSUS$ in the wider criminal-group landscape and to compare its techniques with other identity-abuse campaigns. For a concrete case study, the Uber breach 2022 shows how contractor access, MFA fatigue, and privileged system exposure can combine into a larger compromise.

Detection, containment, and recovery signals to watch

Good detection here is less about one noisy alert and more about a pattern of small anomalies that line up. Monitor for SIM swap indicators, unfamiliar sign-in geography, new device enrolment, repeated MFA prompts, suspicious use of help-desk reset channels, and bursts of access to sensitive repositories or admin consoles.

Once a takeover is suspected, containment should focus on removing the attacker’s ability to authenticate and persist. That often means revoking active sessions, rotating credentials or tokens, revalidating recovery contacts, and checking whether the attacker has created new factors, added forwarding rules, or changed privileged group membership.

Risk and Threat Considerations

LAPSUS$-style activity is dangerous because it converts ordinary support processes and trust relationships into an entry point. A weak reset process, MFA fatigue, or overprivileged access can let an attacker move from one account to many systems without needing exploit code.

Failure mechanism: The attacker abuses human-facing recovery and authentication flows, then uses the resulting access to reach email, source code, cloud consoles, and other sensitive platforms where trust is already established.

Impact: Organisations can lose control of identities, expose data at scale, and face broad operational disruption because the attacker is operating through legitimate sessions and approved tools.

Practitioner Guidance

What to prioritise: Protect the accounts that can change identities, factors, or privilege. If a role can reset access for others or administer a cloud or source-code platform, it needs stronger verification than standard user access.

What to verify: Confirm that help-desk staff, recovery workflows, and admin approval paths cannot be satisfied by the same weak signals an attacker can socially engineer. Also verify that monitoring covers factor enrolment, reset events, and mass-access behaviour, not just failed logins.

Common mistake: Treating LAPSUS$ as a single threat actor problem instead of a repeatable access-path problem. The real lesson is that exposed recovery channels and excess privilege are often the shortest route to breach.

Practitioner takeaway: If you can make account recovery, factor changes, and privileged access both harder to abuse and easier to detect, you remove the pathways LAPSUS$ typically exploits.

Related resources from NHI Mgmt Group

• How should organisations defend against attack-as-a-service identity fraud?
• How should organisations defend biometric authentication against spoofing attacks?
• How should organisations defend against business email compromise when attackers use real conversations?
• How can organisations defend against AI-generated phishing and impersonation?