Notifications
Clear all
Topic starter
18/08/2026 3:00 pm
TL;DR: BQTLock ransomware uses scheduled tasks, privileged account creation, shadow copy deletion, and recovery disabling to lock Windows endpoints before encryption, according to Wazuh. The pattern shows that containment depends on detecting persistence and recovery-inhibition behavior early, not just responding after files are encrypted.
NHIMG editorial — based on content published by Wazuh: BQTLock ransomware detection and response on Windows endpoints
By the numbers:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: What fails first when ransomware disables Windows recovery features?
A: The first failure is usually restore confidence, not encryption.
Q: Why do ransomware gangs create scheduled tasks and local admin accounts?
A: They do it to preserve execution after reboot and to run with higher privileges without needing repeated user interaction.
Q: How do security teams know if ransomware detections are catching the right stage?
A: Look for detections that fire before mass file encryption, especially on account creation, task scheduling, shadow copy deletion, and boot configuration changes.
Practitioner guidance
- Correlate persistence and privilege signals Link scheduled task creation, new local account creation, and elevated execution in one detection path so ransomware is caught before encryption begins.
- Alert on recovery-inhibition commands Treat vssadmin delete shadows and bcdedit recovery-disabled changes as high-priority ransomware precursors because they directly reduce restore options.
- Monitor staging and note-drop behaviour Flag temporary password file creation, multiple ransom note writes, and short-lived executables in Windows Temp as signs of preparatory activity rather than post-impact noise.
What's in the full article
Wazuh's full blog post covers the operational detail this post intentionally leaves for the source:
- Sysmon installation and Windows event forwarding steps for building the detection pipeline
- Custom Wazuh rule syntax for matching BQTLock persistence, recovery inhibition, and encryption behaviour
- CDB list configuration for matching known malware hashes against endpoint file integrity events
- Active Response script deployment for automated remediation on infected Windows endpoints
👉 Read Wazuh's analysis of BQTLock ransomware detection and response →
BQTLock ransomware: what Windows defenders need to catch first?
Explore further
18/08/2026 3:40 pm
Ransomware is increasingly an identity and execution control problem, not just a malware problem. BQTLock depends on privileged execution paths, scheduled tasks, and account manipulation to survive long enough to encrypt. That means the control failure is not only endpoint protection, but also the ability to govern who or what can create persistent, elevated automation on Windows systems. Practitioners should treat local accounts, service accounts, and task automation as part of the ransomware attack surface.
A question worth separating out:
Q: Who is accountable when ransomware suppresses recovery on Windows endpoints?
A: Accountability sits with endpoint, identity, and resilience owners together because the failure crosses multiple control domains. Endpoint teams own telemetry and hardening, identity teams govern elevated accounts and automation, and resilience teams must prove restore paths still work when an attacker tries to destroy them.
👉 Read our full editorial: BQTLock ransomware shows how Windows recovery controls fail
