Lapsus$ breached Microsoft, Okta, NVIDIA, and Samsung without a single piece of custom malware. Some of the people who did it weren't old enough to drive. Here's why their playbook still works, and what it takes to catch an attacker who never technically hacks anything.
Most break-in stories have a weapon in them somewhere. A malicious attachment. An exploit. A payload that antivirus should have caught.
The Lapsus story doesn't.
In early 2022, a group of mostly teenagers walked into some of the best-defended companies on earth, Microsoft, Okta, NVIDIA, Samsung, and walked out with source code, internal tools, and customer access.
In the Okta case, the entry point was the account of a third-party support contractor; hundreds of downstream customers were potentially exposed before anyone understood what had happened.
From NVIDIA and Samsung, the group took source code by the hundreds of gigabytes. And in almost every case, the most unsettling detail is the same: to most of the victim's security tools, nothing unusual happened at all.
There was no malware to detect. The attacker didn't break in. They logged in, with valid credentials, through the front door, and often with a legitimate employee's help.
Lapsus, Microsoft tracks it as DEV-0537 or Strawberry Tempest, is frequently confused with Scattered Spider, and the two are genuinely easy to mix up. But they're best understood as separate crews from the same neighbourhood.
That neighbourhood has a name: The Com, a loose, mostly English-speaking online subculture of young cybercriminals who share techniques, tools, and sometimes members.
Lapsus$ and Scattered Spider both grew out of it, which is why their playbooks rhyme, heavy social engineering, SIM swapping, identity abuse, and public extortion.
In August 2025 the blurring became official: a Telegram brand calling itself Scattered Lapsus$ Hunters surfaced, stitching Lapsus$, Scattered Spider, and a third group, ShinyHunters, into a single extortion operation.
So the point of studying Lapsus$ isn't to memorise one org chart. It's that Lapsus proved a method, and a method outlives any group that gets arrested.
That method is the subject of this piece.
For twenty years, security meant defending a boundary. Keep the bad things out; trust what's inside.
Lapsus exploited the fact that the boundary has quietly moved.
Your data isn't behind a firewall anymore, it's in Microsoft 365, in Okta, in AWS, in GitHub, in Snowflake, in Slack.
What decides who reaches it isn't a network cable.
It's an identity: a login, a session, a token. The perimeter is now whoever can prove they're an authorised user.
Which changes the cheapest way in. You don't need an exploit to get past an identity, you need a credential. And credentials can be phished, bought, or simply purchased from the employee who already has one.
Lapsus was notorious for the last of these, openly advertising on Telegram to recruit insiders at telecoms and software firms who would sell their corporate access.
Follow that thread and the whole attack becomes clear. If the attacker is a valid user, no malware needs to run. No exploit trips a sensor. Antivirus stays quiet, the firewall waves the login through, and the identity provider does exactly what it was built to do: let an authenticated user in. The attacker doesn't defeat your controls. They inherit them.
You can't stop this by looking for bad software. You can only stop it by noticing when a legitimate identity starts behaving like an intruder, across seven distinct moves.
To make those moves concrete, follow one account. Call him Daniel, a support contractor with a login into your environment, the same kind of account that opened the door at Okta.
Daniel is real, trusted, and unremarkable.
That's exactly why the attacker wants to be him. Here's each move, and where the Invinsense platform breaks it.
What the attacker does. They obtain Daniel's login. Maybe they phoned the helpdesk pretending to be him and asked for an MFA reset, vishing.
Maybe they spammed his phone with approval prompts at 11 p.m. until he tapped one to make it stop, MFA push bombing.
Maybe they bought his active session straight off a criminal marketplace, or paid him for it. However it happened, the attacker is now Daniel, and Daniel's login has never looked more legitimate.
Where Invinsense steps in. Daniel logs in from home in Manchester every morning. Tonight, "Daniel" signs in from a data-centre IP in another country, twenty minutes after a genuine login from his real laptop. The SIEM, the system that pools sign-in logs from Entra ID, Okta, VPN and Citrix into one place, hands that to UEBA (User and Entity Behaviour Analytics, a learned baseline of how each person normally behaves), which flags it for what it is: impossible travel (nobody gets from Manchester to that IP in twenty minutes), a login through an anonymising proxy, a fresh device registered on an account that hasn't changed devices in a year.
Threat Intelligence adds the context that the source IP already appears on a marketplace watchlist.
None of it depends on catching malware, because there isn't any. And the instant the picture is clear, SOAR, the automation layer, disables the account, kills its sessions, forces a reset, and opens a priority-one incident, without waiting for an analyst to be awake at 11 p.m.
What the attacker does. Assume the login slipped through. Now the attacker's first instinct is to make sure that resetting Daniel's password won't evict them.
So they enroll their own phone as a second MFA device on his account, now they have their own key, independent of his. They add a quiet inbox rule that auto-deletes any email containing the word "security," so Daniel never sees the alerts.
They nudge his account into a privileged role it never had. Each action is one Daniel is technically allowed to take. None is one he would ever actually do.
Where Invinsense steps in. This is the platform's strongest ground. A new MFA device on Daniel's account, eleven minutes after the reset, from a phone that's never touched your tenant, the SIEM flags it. The inbox rule that quietly deletes security mail, flagged. The sudden jump to Global Administrator on a contractor account, flagged.
EDR (endpoint detection and response) and NDR (its network equivalent) catch the remote-control tools, AnyDesk, ScreenConnect, LogMeIn, the attacker drops in to hold the session hands-on.
And Deception plants decoy accounts and systems that no real employee has any reason to touch; the real Daniel never goes near them, so the moment "Daniel" probes one, it raises a silent, near-zero-false-positive alarm.
SOAR revokes the rogue device, deletes the rule, strips the role, and isolates the endpoint.
What the attacker does. Wearing Daniel's identity, they start looking around, mapping users, groups, and machines to find the privileged accounts and sensitive repositories worth stealing.
The tools leave fingerprints: built-in commands like whoami and net group, the mapping tool BloodHound, and attempts to steal credentials from LSASS (the Windows process that holds live passwords in memory, the thing Mimikatz is built to rob).
Where Invinsense steps in. Daniel is a support contractor. He has never, in eighteen months, run a directory-enumeration command. Tonight his account fires off forty of them in ten minutes. EDR reads the endpoint telemetry for exactly these signatures, the reconnaissance commands, BloodHound execution, and any non-security process reaching into LSASS memory (Sysmon Event ID 10).
UEBA supplies the judgment that makes it damning: this account doing this, at this volume, is so far outside Daniel's baseline that it can only be someone else driving. A correlation rule ties it to what came before, recon from an account that just escalated its own privileges is a chain, not a coincidence.
What the attacker does. Daniel's stolen account is useful, but the real prize is the cloud itself. So they pivot to the control plane, granting Global Administrator, creating a service principal (a non-human identity that software uses to act on its own, an app's own login), minting API tokens, and registering a malicious app they then consent into rights like "read all mail" or "read the whole directory." Because these live above any single password, they'd survive even if you reset Daniel ten times.
Where Invinsense steps in. CIEM (Cloud Infrastructure Entitlement Management, the discipline of tracking who and what can do what across your cloud) and CNAPP join the SIEM to watch the control plane: the contractor account that just escalated itself to Global Admin, the service principal created at midnight, the consent grant to an app registered four minutes ago, an API token minted from that same foreign IP.
On their own, each is an event an administrator might generate on a busy day.
Chained to Daniel's impossible-travel login from Phase 1, they read as exactly what they are.
SOAR's cloud playbook revokes the consent, deletes the rogue app, removes the service principal, kills the tokens, and enforces Conditional Access.
What the attacker does. Now they go shopping. With broad access, they hunt for what's worth extorting, crawling Slack, Teams, and Confluence for secrets, cloning source-code repositories in bulk from GitHub and GitLab, and searching cloud storage for the strings that unlock everything else: password, API_KEY, AWS_SECRET.
Where Invinsense steps in. Somewhere in your engineering org, a developer, lets call her Aisha, normally clones three or four repositories a week. Tonight her account clones two hundred in an afternoon.
UEBA baselines normal data access per person, so that spike is unmissable: the platform flags repository cloning above roughly ten an hour, mass SharePoint and OneDrive downloads, abnormal Snowflake reads, and searches for secret-like terms.
Aisha isn't doing her job tonight. Someone using her token is doing theirs. SOAR revokes the token, disables the account, and cuts the active SaaS sessions.
What the attacker does. Everything Aisha's token touched now has to leave. They move it to storage they control, typically with Rclone (a legitimate command-line tool for syncing files between clouds, heavily abused for exfiltration) or by uploading to anonymous hosts like MEGA.
They compress and stage first, then push it out, often over encrypted channels to blend with ordinary traffic.
Where Invinsense steps in. EDR catches rclone.exe (and renamed copies of it) and megacmd.exe executing on the endpoint; NDR catches the outbound connections to MEGA and Anonfiles.
UEBA flags the volume, an account moving out gigabytes when it normally moves megabytes. And a correlation rule finally reads the whole story end to end: the impossible travel login that was Daniel, the privilege grab, Aisha's two hundred repositories, and now a bulk transfer to an anonymous host. That's not a backup job. That's the exfiltration, in progress. SOAR terminates the sync, blocks the destination, and isolates the endpoint mid transfer.
What the attacker does. This is where Lapsus$ diverged from classic ransomware, and got nastier.
Rather than encrypting your files and selling you the key, they steal the data, then delete the infrastructure: wiping cloud resources, tearing down virtual machines, destroying backups so you can't recover.
Then they threaten to publish everything on Telegram unless you pay.
Destruction without encryption.
Public shaming as leverage.
Where Invinsense steps in. The same Global Admin rights the attacker took through Daniel's account can now delete your environment. The SIEM watches cloud audit logs (Azure Activity, AWS CloudTrail, vCenter) for bulk resource-deletion, backup-tampering, and storage-policy changes, and correlates them straight back to the Phase 4 escalation, so a teardown reads as the final act of a known chain, not a mysterious outage at 3 a.m.
NDR flags the DDoS that sometimes accompanies it.
And a Dark Web monitoring service watches the leak sites and Telegram channels for your name and your data appearing, turning the extortion threat into an early warning instead of an ambush.
SOAR moves to preserve what's left: freezing infrastructure changes, revoking the account's API keys and sessions, and triggering backup-protection and recovery controls.
Notice the shape. Not one of these seven moves is, on its own, obviously an attack.
Daniel logs in. A device gets added. Some directory queries run. A role changes. Aisha's repos get cloned.
A file sync starts. A resource gets deleted. Every one of those is something a real employee does on a normal day, which is precisely why a tool that judges events one at a time waves each of them through.
Invinsense doesn't try to catch the attacker on any single one. It watches identity, endpoint, network, and cloud at once, so the sequence, Daniel's impossible login, then the new admin role, then Aisha's two hundred repositories, then the MEGA upload, assembles into one story while there is still time to end it.
The attacker's whole advantage was that no individual step looked wrong. Correlation across the chain is what takes that advantage away.
Two honest limits, and they're specific to this playbook.
The first, the source names itself: SIM swapping is invisible to a SIEM. When an attacker hijacks an employee's phone number at the mobile carrier, that theft happens on the telecom's network, not yours. The platform can catch the suspicious login the stolen code enables, but it cannot see the swap. Phishing-resistant MFA that doesn't rely on SMS codes at all is the real fix, and that's a decision your identity team makes, not a rule a product writes.
The second is harder still: the insider. Go back to Daniel, but this time imagine he wasn't tricked. Imagine he was paid, and handed over his access willingly. Now there is no impossible travel login to catch, no anomaly at the door, because the login really is his, from his laptop, at his usual hour.
Behavioral analytics will still catch what the account does next, the escalation, the bulk clone, the exfiltration, but the initial access looks exactly like Daniel doing his job, because for one transaction, it was. Closing that gap is culture, vetting, and least-privilege access, not telemetry.
Any vendor who tells you a product alone stops Lapsus$ has misread how Lapsus$ won.
The most important lesson from Lapsus$ isn't about a group of teenagers, most of whom have since been arrested. It's that they were right about where security actually lives now.
The perimeter is no longer your network. It's your identities, every login, token, and session that can reach your cloud.
And an attacker holding a valid one doesn't need malware, doesn't need an exploit, and doesn't need to break anything. They just need you to keep assuming that authenticated means trusted.
So the question was never "is our network locked down?"
It's "when a legitimate identity starts behaving like a stranger, logging in from nowhere, granting itself power, cloning everything, deleting the rest, would we see the story before it reaches the leak site?"
Discover complete cybersecurity expertise you can trust and prove you made the right choice!
