When One Alert Tells You Everything — and Nothing (Detecting v17 Lumma Stealer)
- 9 hours ago
- 8 min read
The Attacker Almost Won
On a quiet Tuesday morning in June 2026, an employee at a mid-size organization pressed Win+R, pasted a command they found on a website, and hit Enter. By the time SentinelOne surfaced its first alert, Lumma Stealer had already spent over five minutes inside the machine — reading browser memory, querying the Windows credential database, capturing keystrokes, and probing the network for other machines to move to.
The user had no idea. They spent the next hour and a half opening documents, reading email, and responding to messages on Slack — completely unaware that an attacker was sitting inside their session.
What stopped the attacker from walking away clean was not a single magic detection. It was twelve behavioural indicators, spread across Multiple detection engines, woven together by SentinelOne's Storyline correlation engine. And the only reason we were able to understand the full scope of the compromise was a deep investigation inside Deep Visibility — because the alert alone, taken at face value, told us only a fraction of the story.
This article walks through that investigation:
what happened, what SentinelOne caught, what it nearly missed, and why looking beyond the alert is not optional — it is the difference between a full containment and a repeat breach.
Background: ClickFix and Lumma Stealer
ClickFix is a social engineering technique that has surged in 2025 and 2026. The victim is presented with a fake browser error, CAPTCHA, or 'verification' page that instructs them to open the Windows Run dialog (Win+R) and paste a command. The command is already in the clipboard — the victim just has to press Ctrl+V and Enter.
No downloads, no suspicious file attachments, no executable to double-click.
Lumma Stealer (also tracked as LummaC2) is a commercial infostealer sold as a service on criminal forums. It specialises in extracting browser-stored credentials, cookies, active session tokens, cryptocurrency wallet files, and system information — all in memory, leaving no binary on disk.
Version 17 added direct system call capabilities to bypass EDR user-mode hooks, making it one of the more technically capable commodity stealers available in 2026.
The combination is extremely effective. The human is the delivery mechanism, the malware never touches disk, and the exfiltration looks like normal HTTPS traffic. Organisations that rely purely on signature-based detection or file-based scanning will see nothing.
Incident Timeline — What Happened (All times UTC, anonymised)
Phase 1 — Initial Execution (09:31 UTC)
The victim, a user on a corporate Windows 11 laptop (referred to as CORP-LT-2847), opened the Windows Run dialog and pasted the following command:
This single line initiated a chain of events that would persist for over ninety minutes.
The script downloaded Lumma Stealer v17.19 (4.85 MB) entirely into memory and executed it.
No file was written to disk. SentinelOne registered the payload download as an outbound connection — status: SUCCESS.
-------------------------------------------------------------------------------------------------------
Phase 2 — Evasion (09:31–09:36 UTC)
Before Lumma could steal anything, it needed to blind the tools watching it. Two evasion techniques were observed:
Windows Defender (AMSI) Bypass
— Lumma loaded a legitimate, signed security DLL and used it to disable AMSI's scanning hooks — exploiting trust in signed code to remove the very inspection layer designed to catch malicious scripts.
Direct Kernel Calls — EDR Hook Bypass
— At 09:36:46, SentinelOne logged a critical evasion event:
[09:36:46 UTC]
*** KernelCallbackDirectSyscallNonNt *** [Evasion]
process : WindowsTerminal.exe
storyline: [STORYLINE-ID]Lumma v17 bypasses EDR user-mode hooks entirely by calling the Windows kernel directly — skipping the layer where SentinelOne monitors. The call executes before SentinelOne can inspect or block it. The fact that SentinelOne logged this at all is significant: the evasion was detected even if it could not be blocked in the moment.
One second later, SentinelOne's logged another a critical evasion event:
[09:36:47 UTC]
*** LummaStealerPowerShellStager *** [Execution]
process : powershell.exe
storyline: [STORYLINE-ID]Both events share the same Storyline ID — SentinelOne's mechanism for grouping causally related events into a single attack chain.
Without this, two separate events in Deep visibility with no apparent connection. With it, one coherent kill chain.
-------------------------------------------------------------------------------------------------------
Phase 3 — Active Credential Theft (09:33–09:36 UTC)
With evasion in place, Lumma began its primary mission.
09:33:51 — SAM Database Queried
— The Security Account Manager (SAM) is Windows' local credential store. It holds NTLM password hashes for every local account on the machine. These can be cracked offline or used in pass-the-hash attacks to authenticate to other systems without knowing the actual password.
09:33:52 — Chrome Browser Memory Read (First)
— Lumma read the memory of the running Chrome process and extracted saved passwords, session cookies, and active session tokens. This is not a Chrome exploit — Chrome stores credentials in memory while it runs. Lumma reads that memory directly.
09:33:59 — Session Token Captured
— A specific SSO authentication token for the organisation's internal workspace was observed in the telemetry. This token allows full workspace access — reading messages, downloading files, accessing private channels — without any username or password. It does not expire until explicitly revoked.
09:34:06 — SentinelOne Registry Tamper Attempted — BLOCKED
— Lumma attempted to modify a protected SentinelOne registry key to disable the agent. SentinelOne's self-protection mechanism blocked this attempt.
09:35:04 — ETW (Event Tracing for Windows) Tampered
— Windows' native forensic logging framework was partially disrupted. An anti-forensics technique to reduce evidence available to investigators.
09:35:26 — Reconnaissance via svchost.exe
— A trusted Windows system process (svchost.exe) showed 771 infostealer indicators and 393 reconnaissance indicators accumulated across its lifetime — signs of Lumma injecting activity into a signed Windows binary to enumerate processes, network shares, and USB devices.
Because svchost is a trusted binary, this activity is harder to detect via process-based rules alone.
09:35:58 — Chrome Browser Memory Read (Second)
— A second pass to ensure full extraction of session data from browser memory.
-------------------------------------------------------------------------------------------------------
Phase 4 — Keylogger + Lateral Movement (09:34+ UTC)
A keylogger was installed at 09:34:06, capturing all keystrokes from this point forward — including passwords typed, search terms, messages sent, and any sensitive content entered into forms.
At approximately the same time, Lumma invoked WinRM (Windows Remote Management) to attempt lateral movement — probing whether it could authenticate to and execute commands on other machines on the same network segment, using the credentials it had already harvested.
-------------------------------------------------------------------------------------------------------
Phase 5 — Shadow Copy Abuse (09:52–10:52 UTC)
This phase is the one most often missed by teams that stop at the alert.
Three separate accesses to Volume Shadow Copy Service (VSS) snapshots were observed:
09:52:27 — Shadow copy accessed (first)
10:12:45 — Shadow copy accessed (second)
10:52:27 — Shadow copy accessed (third)
Why VSS?
When Windows locks a file that is in use — like the SAM database or a browser's credential store — you cannot read it normally. VSS snapshots are point-in-time backups of the file system, and files in a snapshot are not 'in use,' so they can be read freely. Lumma used VSS to read locked credential files that would otherwise have been inaccessible. Three accesses across a one-hour window indicates repeated, deliberate attempts to extract different credential stores from backup copies.
-------------------------------------------------------------------------------------------------------
Phase 6 — User Works Normally, Unaware (10:02–11:06 UTC)
During this window, the user opened documents, received and read Mail messages, and received and read notifications. The keylogger was confirmed still running at 10:03:10 — 32 minutes after infection. The user had no indication anything was wrong. No pop-up, no slowdown, no ransom note. The machine looked and behaved completely normally.
-------------------------------------------------------------------------------------------------------
Phase 7 — Chrome Process Injection Detected (11:06 UTC)
SentinelOne raised a PreloadInjection behavioural indicator on Chrome — one of the most
revealing signals in the entire investigation:
indicator.name : PreloadInjection
indicator.category: Evasion
MITRE : T1055.012 (Process Hollowing)
TargetProcess : chrome.exe (renderer)
RootProcess : chrome.exe (main browser process)
Active Content : UNSIGNEDLumma injected malicious code into Chrome renderer subprocesses during their initialization — before the process's own code had finished loading. The injected renderer ran with Chrome's identity and permissions, meaning its memory reads were attributed to a trusted, signed Google process.
The flag activeContent.signedStatus: unsigned on a signed Chrome binary is the fingerprint of injected foreign code. This indicator fired twice in quick succession against two different Chrome child processes — Lumma was still actively operating inside Chrome 90 minutes after initial execution.
-------------------------------------------------------------------------------------------------------
Phase 8 — SentinelOne Surfaces 12 Behavioural Indicators (09:36:44 UTC)
SentinelOne surfaced all 12 accumulated behavioural indicators together, linked under a single Storyline. This is the 'alert' that an analyst would have seen first. The indicators fired across five detection categories:
Execution: LummaStealerPowerShellStager — named signature match
Evasion: KernelCallbackDirectSyscallNonNt — direct kernel call bypass
Evasion: PreloadInjection — process hollowing in Chrome renderer (T1055.012)
Credential Access: SAM database query; Chrome memory read (x2)
Defence Evasion: AMSI bypass; ETW tampering; SentinelOne registry tamper attempt (blocked)
Twelve signals. One Storyline.
Phase 9 — Last Telemetry (11:10 UTC)
The last event in available telemetry was logged at 11:10:05 UTC. The attacker remained active — the keylogger and any persistence mechanisms were still installed for the duration of the available window. Before we disconnected device from Internet
What SentinelOne Got Right: Multiple Engines, One Signal
Lumma Stealer deliberately tried to be invisible.
It never wrote a file to disk.
It bypassed AMSI.
It used direct kernel calls to skip EDR hooks.
It injected into trusted processes.
It attempted to disable SentinelOne.
It tampered with Windows event logging.
And yet SentinelOne still detected it — not because of one rule,
but because of layered detection architecture:
The key lesson:
no single engine caught the full picture. Lumma successfully bypassed AMSI. It used direct kernel calls before SentinelOne could block them. But it could not bypass every engine simultaneously. Evading one layer does not mean evading all layers.
What the Alert Alone Did NOT Tell Us
If an analyst had looked at intial alert and stopped there, they wouldn't have known a known stealer ran, it bypassed AMSI, it read Chrome memory, and it queried SAM.
They would NOT have known:
The keylogger was still active 32 minutes after the alert fired
Three VSS shadow copy accesses occurred over a one-hour window — repeated, deliberate credential extraction from backup snapshots
A specific SSO token was confirmed captured in telemetry
Chrome PreloadInjection at 11:06 — Lumma still injecting into Chrome renderers 90 minutes after execution
WinRM lateral movement was attempted — other machines may have been targeted
User was working normally for 90+ minutes with an active keylogger running
Every one of these findings came from Deep Visibility. None of them were in the alert.
Why Deep Visibility Is Not Optional
EDR alerts are designed to be actionable at scale.
But for any alert involving a known infostealer, evidence of credential access, a session token captured in telemetry, or a machine not immediately isolated — stopping at the alert is a containment failure.
Deep Visibility in SentinelOne is where the investigation begins, not ends. The alert told us the attacker entered the building. Deep Visibility told us which rooms they visited, what they took, and whether they were still inside when we showed up.
In this investigation, the DV data changed the response entirely:
Chrome memory read → Lumma still injecting into Chrome 90 minutes later
SAM queried → SAM accessed three times via VSS snapshots over 60 minutes
Session tokens at risk → Specific SSO token confirmed captured
Attacker executed and left → Attacker still active at time of log collection
Standard credential reset → Full rebuild + revoke all sessions on all platforms
SentinelOne Detection Names
The following detection names were raised by SentinelOne during this incident:
LummaStealerPowerShellStager [Execution]
KernelCallbackDirectSyscallNonNt [Evasion]
PreloadInjection [Evasion — T1055.012 Process Hollowing]
Key Takeaways
Final Thought
This attacker built a technically sophisticated tool. They bypassed AMSI, evaded user-mode EDR hooks, injected into trusted processes, accessed credentials through backup snapshots, and left the machine looking completely normal for ninety minutes.
They nearly got everything they came for.
What caught them was not one thing. It was the depth of a platform that kept watching even after individual evasion techniques succeeded — and an investigation that went beyond the alert to read what the telemetry was actually saying.
SentinelOne did not prevent every evasion. But it recorded everything. And in endpoint security, the ability to reconstruct what happened with precision is often what separates a contained incident from a breach that goes undetected for months.
Comments