implementing-ransomware-kill-switch-detection
Analyzes ransomware kill switch mechanisms, including mutex-based execution guards, domain-based kill switches (e.g. WannaCry-style), and registry termination checks, then implements mutex vaccination and kill switch domain monitoring to stop ransomware before it runs. Use when analyzing a sample's execution guards or deploying vaccination/monitoring as a defensive control.
- License 许可
- Apache-2.0
- 最近更新
- 2026-08-31
- Stars
- ★ 3.6w
- Forks
- 4.4k
01 前言 Front Matter
- name
- implementing-ransomware-kill-switch-detection
- tags
- [ "ransomware", "kill-switch", "mutex", "detection", "WannaCry", "malware-analysis" ]
- author
- mahipal
- domain
- cybersecurity
- license
- Apache-2.0
- version
- 1.0.0
- mitre_f3
- { "tactics": [ "positioning", "monetization" ], "version": "1.1", "techniques": [ { "id": "T1219", "name": "Remote Access Tools", "source": "attack", "tactic": "positioning" }, { "id": "F1018", "name": "Convert to Cryptocurrency", "source": "f3", "tactic": "monetization" }, { "id": "F1017", "name": "Conversion to Physical Monetary Instruments", "source": "f3", "tactic": "monetization" }, { "id": "F1047", "name": "Transfer of funds", "source": "f3", "tactic": "monetization" } ] }
- nist_csf
- [ "PR.DS-11", "RS.MA-01", "RC.RP-01", "PR.IR-01" ]
- subdomain
- ransomware-defense
- description
- Analyzes ransomware kill switch mechanisms, including mutex-based execution guards, domain-based kill switches (e.g. WannaCry-style), and registry termination checks, then implements mutex vaccination and kill switch domain monitoring to stop ransomware before it runs. Use when analyzing a sample's execution guards or deploying vaccination/monitoring as a defensive control.
- mitre_attack
- [ "T1078", "T1190", "T1059", "T1486", "T1490" ]
02 资源文件 6
- 参考文档examples/architecture-examples.md4.9 KB
- 许可证LICENSE11.0 KB
- 参考文档references/api-reference.md3.7 KB
- 脚本scripts/agent.py12.0 KB
- 参考文档template.md28.0 KB
- 参考文档validation.md4.2 KB
03 SKILL.md 正文
Implementing Ransomware Kill Switch Detection
When to Use
- Analyzing a ransomware sample to determine if it contains a kill switch mechanism (mutex, domain, registry)
- Deploying proactive mutex vaccination across endpoints to prevent known ransomware families from executing
- Monitoring DNS for kill switch domain lookups that indicate ransomware attempting to check before encrypting
- During incident response to quickly determine if a ransomware variant can be stopped by activating its kill switch
- Building detection signatures for ransomware mutex creation events using Sysmon or EDR telemetry
Do not use kill switch vaccination as a primary defense. Not all ransomware families implement kill switches, and those that do may remove them in newer versions. This is a supplementary detection and prevention layer.
Prerequisites
- Python 3.8+ with
ctypes(Windows) for mutex creation and enumeration - Sysmon installed with Event ID 1 (process creation) and Event ID 17/18 (pipe/mutex events) configured
- Access to malware analysis sandbox for identifying kill switch mechanisms in samples
- DNS monitoring capability for detecting kill switch domain resolution attempts
- Familiarity with Windows internals: mutexes (mutants), kernel objects, named pipes
- Reference database of known ransomware mutexes (github.com/albertzsigovits/malware-mutex)
Workflow
Step 1: Identify Kill Switch Mechanisms in Ransomware
Analyze samples for common kill switch patterns:
Kill Switch Types Found in Ransomware:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. MUTEX-BASED (most common):
- Ransomware creates a named mutex at startup
- If mutex already exists → another instance is running → exit
- Defense: Pre-create the mutex to prevent execution
- Examples:
WannaCry: Global\MsWinZonesCacheCounterMutexA
Conti: kasKDJSAFJauisiudUASIIQWUA82
REvil: Global\{GUID-based-on-machine}
Ryuk: Global\YOURPRODUCT_MUTEX
2. DOMAIN-BASED:
- Ransomware resolves a hardcoded domain before executing
- If domain resolves → security sandbox detected → exit
- Defense: Register/sinkhole the domain to activate kill switch
- Examples:
WannaCry v1: iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com
WannaCry v1: fferfsodp9ifjaposdfjhgosurijfaewrwergwea.com
3. REGISTRY-BASED:
- Check for specific registry key/value before executing
- If key exists → exit (anti-analysis or kill switch)
- Defense: Create the registry key proactively
4. FILE-BASED:
- Check for existence of specific file or directory
- If marker file exists → exit
- Defense: Create the marker file on all endpoints
5. LANGUAGE-BASED:
- Check system language/keyboard layout
- Exit if Russian/CIS country keyboard detected
- Common in Eastern European ransomware groups
Step 2: Deploy Mutex Vaccination
Pre-create known ransomware mutexes on endpoints to prevent execution:
# Windows mutex vaccination using ctypes
import ctypes
from ctypes import wintypes
kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)
def create_mutex(name):
"""Create a named mutex to vaccinate against ransomware."""
handle = kernel32.CreateMutexW(None, False, name)
error = ctypes.get_last_error()
if handle == 0:
return False, f"Failed to create mutex: error {error}"
if error == 183: # ERROR_ALREADY_EXISTS
return True, f"Mutex already exists (already vaccinated): {name}"
return True, f"Mutex created successfully: {name}"
KNOWN_RANSOMWARE_MUTEXES = [
"Global\\MsWinZonesCacheCounterMutexA", # WannaCry
"Global\\kasKDJSAFJauisiudUASIIQWUA82", # Conti
"Global\\YOURPRODUCT_MUTEX", # Ryuk variant
"Global\\JhbGjhBsSQjz", # Maze
"Global\\sdjfhksjdhfsd", # Generic ransomware
]
Step 3: Monitor for Mutex Creation Events
Use Sysmon to detect when ransomware creates its characteristic mutexes:
<!-- Sysmon configuration for mutex monitoring -->
<Sysmon schemaversion="4.90">
<EventFiltering>
<!-- Event ID 1: Process creation with mutex indicators -->
<ProcessCreate onmatch="include">
<CommandLine condition="contains">mutex</CommandLine>
<CommandLine condition="contains">CreateMutex</CommandLine>
</ProcessCreate>
</EventFiltering>
</Sysmon>
Detection via Event Logs:
━━━━━━━━━━━━━━━━━━━━━━━━
Windows Security Log:
Event ID 4688: Process creation (enable command line logging)
Sysmon:
Event ID 1: Process create (includes command line and hashes)
Event ID 17: Pipe created (named pipes, similar to mutexes)
PowerShell detection:
Event ID 4104: Script block logging (detect mutex creation in scripts)
Velociraptor artifact:
Windows.Detection.Mutants - Enumerates all named mutant objects
Step 4: Monitor DNS for Kill Switch Domains
Detect ransomware domain-based kill switch resolution attempts:
DNS Monitoring for Kill Switch Domains:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. Monitor DNS queries for known kill switch domains
2. High-entropy domain names (>4.0 entropy in domain label) may indicate
ransomware kill switch domains or DGA-generated C2 domains
3. Queries to newly registered domains from endpoints that typically
only access well-established domains
Indicators:
- Domain with no prior resolution history
- Domain registered in last 24-72 hours
- High character entropy in domain name
- Resolution attempt followed by either mass encryption (kill switch failed)
or process termination (kill switch activated)
Step 5: Enumerate Active Mutexes for Incident Response
During an active incident, scan endpoints for ransomware-associated mutexes:
# PowerShell: List all named mutant objects using Sysinternals Handle
# handle.exe -a -p <PID> | findstr "Mutant"
# Velociraptor query for mutex hunting:
# SELECT * FROM glob(globs="\\BaseNamedObjects\\*") WHERE Name =~ "mutex_pattern"
# Python-based enumeration (requires pywin32):
# import win32event
# handle = win32event.OpenMutex(0x00100000, False, "Global\\MutexName")
Verification
- Verify mutex vaccination by attempting to create the same mutex (should get ERROR_ALREADY_EXISTS)
- Test that vaccinated mutexes survive system reboot (they do not; re-apply at startup via scheduled task)
- Confirm DNS monitoring detects test queries for known kill switch domains
- Validate Sysmon event generation for mutex creation by running a test script
- Check that vaccination does not interfere with legitimate applications using similar mutex names
- Test against actual ransomware samples in an isolated sandbox to confirm kill switch activation
Key Concepts
| Term | Definition |
|---|---|
| Mutex (Mutant) | A Windows kernel synchronization object used to ensure only one instance of a program runs; ransomware uses named mutexes to prevent re-infection |
| Kill Switch | A mechanism in ransomware that causes it to terminate without encrypting if a specific condition is met (mutex exists, domain resolves, file present) |
| Mutex Vaccination | Proactively creating named mutexes on endpoints that match known ransomware mutex names, preventing the ransomware from executing |
| Domain Sinkhole | Registering or redirecting a malicious domain to a controlled server; used to activate domain-based kill switches |
| DGA (Domain Generation Algorithm) | Algorithm used by malware to generate pseudo-random domain names for C2 communication, sometimes incorporating kill switch checks |
Tools & Systems
- Sysmon: Microsoft system monitor providing Event ID 17/18 for named pipe and mutex creation monitoring
- Velociraptor: Endpoint visibility tool with built-in artifacts for enumerating mutant (mutex) objects on Windows
- Sysinternals Handle: Command-line tool for listing open handles including named mutexes per process
- malware-mutex (GitHub): Community-maintained database of mutexes used by known malware families
- ANY.RUN: Interactive malware sandbox that reports mutex creation during dynamic analysis
- PassiveDNS: DNS monitoring infrastructure for detecting kill switch domain resolution attempts
04 同仓库更多 Skills
verifying-build-provenance-with-slsa-sigstore
Verifies artifact signatures and SLSA provenance using Sigstore's cosign (verify, verify-attestation, verify-blob-attestation) and slsa-verifier (verify-artifact), enforcing keyless OIDC builder identity and source repo against SLSA Build levels. Use in CI/CD before deploying artifacts, when consuming third-party attestations, establishing a SLSA Build L3 pipeline, or confirming provenance during incident response or admission control.
validating-tpm-measured-boot-attestation
Verifies TPM 2.0 measured-boot integrity and remote attestation with tpm2-tools -- reading PCRs (tpm2_pcrread), replaying the boot event log, generating and checking signed quotes (tpm2_quote/tpm2_checkquote), and sealing secrets to a PCR policy. Use to confirm a system booted trusted firmware/kernel for Zero Trust device posture, detect boot-chain tampering via PCR drift, or build a golden-value baseline for fleet attestation.
validating-backup-integrity-for-recovery
Validates backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to confirm backups are reliable for disaster recovery and ransomware response. Use before relying on backups for recovery, when building post-backup validation pipelines, auditing backup infrastructure for compliance, or checking immutable/air-gapped backups for silent corruption or tampering.
triaging-windows-with-kape
Runs KAPE (Kroll Artifact Parser and Extractor) to collect targeted forensic artifacts (registry hives, $MFT, event logs, prefetch, browser data) via Targets and parse them with Modules wrapping Eric Zimmerman's EZ Tools (PECmd, MFTECmd, RECmd). Use during early incident containment/triage when full disk imaging is impractical but a defensible, parseable Windows artifact set is needed quickly, including at-scale remote collection.
triaging-vulnerabilities-with-ssvc-framework
Triages and prioritizes vulnerabilities with CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree, weighing exploitation status (via the CISA KEV catalog and FIRST EPSS API), technical impact, automatability, and mission prevalence to output Track/Track*/Attend/Act decisions. Use when prioritizing vulnerability scan results (OpenVAS, Nessus, Qualys) for remediation planning beyond raw CVSS scores.
triaging-security-incident
Performs initial triage of security incidents using the NIST SP 800-61r3 and SANS PICERL frameworks, classifying incident type, assigning priority by business impact, and routing to the appropriate response team. Use when a SIEM/EDR alert needs human classification, concurrent alerts must be prioritized, or a user report or threat-intel IOC match requires initial incident categorization.