LockBit does not need a new trick to beat a SIEM. It beats deployments missing key log sources, that never translate raw events into rules for how ransomware behaves on a host, and that produce so much noise the one alert that mattered gets closed as a false positive. Fix those gaps and a LockBit intrusion becomes loud and slow, not invisible.
- Most SIEM gaps against LockBit are visibility gaps: EDR telemetry, PowerShell logging, and VPN logs that never reach the SIEM.
- The defense evasion step, clearing event logs, stopping security services, deleting shadow copies, is itself detectable and often the last chance to stop encryption.
- Rules built around encryption behaviour and lateral movement tooling catch LockBit earlier than rules that fire only once files carry a ransom extension.
- Alert fatigue, not missing data, is the usual reason a SIEM that technically saw the intrusion still failed to stop it.
How a LockBit intrusion actually unfolds
LockBit runs as a ransomware-as-a-service programme: the encryptor and leak site belong to one group, affiliates run the intrusions, and payouts are split. The early stage varies by affiliate; the later stages, where a SIEM has its best chance, are fairly consistent. Initial access usually comes through exposed RDP, a vulnerable VPN appliance, a bought credential, or a phishing loader. From there the affiliate harvests credentials, escalates privileges, and moves laterally with tools such as PsExec, WMI, or PowerShell remoting, then disables defenses, deletes backups and shadow copies, and triggers mass encryption, usually timed for a weekend or after hours.
Every middle stage produces log events. The question is whether the SIEM ingests the right sources and whether anyone wrote a rule for those events outside routine admin work.
Where visibility breaks down before encryption starts
Log sources that never reach the SIEM
The common gap in bank SIEM deployments is not a missing rule, it is a missing log source. EDR alerts get forwarded but raw EDR telemetry (process trees, command lines) often does not. PowerShell script block logging is frequently left off because it is verbose. VPN gateway logs sit in a separate console nobody wired in. Domain controller logs arrive with auditing left at Windows defaults, so events that matter, 4688 with command-line auditing, 4720, 4732, 4624 with logon type detail, never get generated or captured. That is the gap between a SIEM with an opinion on the intrusion and one that finds out after the ransom note appears.
Evasion steps that blind the SIEM directly
Affiliates commonly run a defense evasion sequence just before encryption: clearing the Windows Security and System event logs (itself generating event ID 1102, a strong and underused signal), stopping or uninstalling EDR and AV services, and sometimes using a vulnerable signed driver to kill EDR from kernel level. Without a rule for 1102, for a security service stopping outside a maintenance window, or for an unrecognised driver load, the tool meant to catch the attack gets switched off unnoticed.
Correlation rules most deployments are missing
A SIEM licence does not detect anything by itself. Detection needs rules mapped to behaviour, and most environments lack rules for:
- Mass file rename or extension change across a share, the actual encryption event, not the ransom note that follows it.
- Shadow copy and backup deletion: vssadmin delete shadows, wmic shadowcopy delete, wbadmin delete catalog.
- PsExec, WMI, or scheduled task creation from a host that does not normally run admin tooling, against several servers at once.
- New service creation with a generic or randomised name, a common encryptor deployment pattern.
- Security log clearing (event ID 1102) or the Event Log service stopping outside a change window.
- Outbound connections to known LockBit leak infrastructure, for catching exfiltration ahead of encryption.
Why alert volume hides the one alert that matters
A SIEM tuned only to cut noise, without a parallel effort to keep high-fidelity rules from being buried in it, hides the signal along with everything else. The pattern in most post-incident reviews is not "the SIEM had no visibility." It is "the SIEM alerted on the lateral movement step, and it sat behind hundreds of lower-priority alerts because nobody had put ransomware precursor behaviour in its own severity tier." The fix is fewer, better-prioritised rules tied to kill-chain stages, paged immediately rather than queued.
SIEM and SOAR: cutting the time between alert and containment
Detection without a fast response path still lets encryption finish. Wiring the SIEM into a SOAR platform to automate first response, isolating the endpoint, disabling the account, blocking the destination IP, removes the manual steps between an alert firing and someone acting on it. For a fast-moving LockBit deployment that gap is the difference between an incident contained on a handful of hosts and encryption across a file server estate.
What UAE regulators and assessors actually check
CBUAE and NESA-aligned assessments rarely ask whether you own a SIEM. They ask for evidence: log retention periods, use cases mapped to a framework such as MITRE ATT&CK, tested playbooks, and proof alerts get triaged within a defined SLA rather than sitting on an unwatched dashboard. A SIEM that passes a licensing audit but has never faced a simulated ransomware scenario is a paperwork control.
A short list for your next SIEM review
- Is PowerShell logging, command-line auditing, and VPN gateway logging actually flowing into the SIEM, not just planned?
- Is there a standalone, high-severity rule for event ID 1102 and for shadow copy deletion commands?
- Are lateral movement tools baselined so abnormal use pages someone immediately?
- Is there a tested SOAR playbook that isolates a host and disables an account without manual approval?
- When did someone last try to make your SIEM miss a simulated ransomware run, not just review its dashboard?
