DeadLock is useful to defenders not because it introduces a single perfect indicator, but because its encryptor performs several disruptive actions before file encryption becomes the visible problem. Microsoft Threat Intelligence describes privilege preparation, termination of selected services, broad event-log suppression and a resource-aware encryption mechanism. Those behaviors create a sequence that a SOC can correlate.
Defender decision: a privileged process that disrupts recovery services and suppresses logging should be handled as potential destructive activity. Do not wait for a ransom note to begin triage.
The path before encryption
Microsoft reports that the encryptor decrypts an embedded configuration, attempts elevation and enables privileges needed for high-impact operations. It then targets selected Windows services, including security, backup, database, virtualization and Active Directory-related services. The same analysis documents three complementary methods used to clear event logs, stop future collection and restrict access to the channels.
These are not merely cleanup details. Together they describe intent: reduce prevention, weaken recovery and remove the evidence needed to reconstruct execution. The encryption stage then uses resource-aware throttling, which can keep the host responsive while damage progresses. A workstation that is still interactive is therefore not evidence that impact has stopped.
Telemetry that should converge in one case
| Signal | Why it matters | What to correlate |
|---|---|---|
| Privilege and elevation activity | Prepares the process for service control and system-wide impact. | Process lineage, token changes, elevation attempts and the originating user/session. |
| Security or recovery service disruption | Can remove controls and impair restoration. | Service configuration changes, stop events, backup failures and endpoint protection health. |
| Event-log clearing or disabling | Indicates evidence suppression, especially when multiple channels are affected. | Administrative process execution, channel state changes and abrupt telemetry gaps. |
| Broad file modification | Confirms impact is underway but may arrive late. | File-extension changes, write volume, ransom-note creation and endpoint detections. |
No single row proves DeadLock. The defensive value comes from time-bounded correlation: the same host, process tree or administrative session producing two or more of these signals without an approved change. That approach remains useful if the actor changes a filename, hash or infrastructure endpoint.
A defensible response decision
Investigate
One isolated service stop with an identified administrator, change ticket and expected telemetry.
Contain
Security or backup disruption combined with log tampering, unexplained elevation or rapid file changes.
Escalate to IR
Multiple hosts, evidence of data theft, recovery impairment or signs that preservation conflicts with immediate patching or rebuilding.
Limits and evidence boundary
Service stops and log clearing are not unique to DeadLock, and the absence of a published indicator does not exclude it. Treat this as a behavior-led triage pattern, not an attribution rule. Current product-specific detections and indicators should be taken from the original Microsoft publication and validated against your own telemetry retention and response authority.
Primary source: Microsoft Threat Intelligence — DeadLock ransomware technical analysis.