security-tools/sigma-rules
1
0
Fork 0
Code Issues Pull Requests Actions 3 Packages Projects Releases Wiki Activity

[Rule Tuning] Windows High-Severity Rules Revamp - 6 (#6010)

Browse Source 
* [Rule Tuning] Windows High-Severity Rules Revamp - 6

* ++
This commit is contained in:
Jonhnathan
2026-05-01 16:14:44 -03:00
committed by GitHub
parent 2cb5e1860a
commit 771be70c38
10 changed files with 1446 additions and 652 deletions
Download Patch File Download Diff File Expand all files Collapse all files
rules/windows/credential_access_shadow_credentials.toml
+134 -58
View File
@@ -2,7 +2,7 @@
creation_date = "2022/01/26"
integration = ["system", "windows"]
maturity = "production"
updated_date = "2026/03/24"
updated_date = "2026/04/27"
[rule]
author = ["Elastic"]
@@ -13,8 +13,8 @@ persistent and stealthy access to the target user or computer object.
"""
false_positives = [
"""
Modifications in the msDS-KeyCredentialLink attribute can be done legitimately by the Azure AD Connect
synchronization account or the ADFS service account. These accounts can be added as Exceptions.
Azure AD Connect or ADFS provisioning can legitimately modify msDS-KeyCredentialLink when the writer account,
source, object class, target DN, bounded change set, and post-change authentication all match an expected workflow.
""",
]
from = "now-9m"
@@ -22,37 +22,6 @@ index = ["winlogbeat-*", "logs-system.security*", "logs-windows.forwarded*"]
language = "kuery"
license = "Elastic License v2"
name = "Potential Shadow Credentials added to AD Object"
note = """## Triage and analysis
### Investigating Potential Shadow Credentials added to AD Object
The msDS-KeyCredentialLink is an Active Directory (AD) attribute that links cryptographic certificates to a user or computer for domain authentication.
Attackers with write privileges on this attribute over an object can abuse it to gain access to the object or maintain persistence. This means they can authenticate and perform actions on behalf of the exploited identity, and they can use Shadow Credentials to request Ticket Granting Tickets (TGTs) on behalf of the identity.
#### Possible investigation steps
- Identify whether Windows Hello for Business (WHfB) and/or Azure AD is used in the environment.
- Review the event ID 4624 for logon events involving the subject identity (`winlog.event_data.SubjectUserName`).
- Check whether the `source.ip` is the server running Azure AD Connect.
- Contact the account and system owners and confirm whether they are aware of this activity.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Review the event IDs 4768 and 4769 for suspicious ticket requests involving the modified identity (`winlog.event_data.ObjectDN`).
- Extract the source IP addresses from these events and use them as indicators of compromise (IoCs) to investigate whether the host is compromised and to scope the attacker's access to the environment.
### False positive analysis
- Administrators might use custom accounts on Azure AD Connect. If this is the case, make sure the account is properly secured. You can also create an exception for the account if expected activity makes too much noise in your environment.
### Response and remediation
- Initiate the incident response process based on the outcome of the triage.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- Remove the Shadow Credentials from the object.
- Investigate how the attacker escalated privileges and identify systems they used to conduct lateral movement. Use this information to determine ways the attacker could regain access to the environment.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
"""
references = [
"https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab",
"https://www.thehacker.recipes/ad/movement/kerberos/shadow-credentials",
@@ -61,29 +30,6 @@ references = [
]
risk_score = 73
rule_id = "79f97b31-480e-4e63-a7f4-ede42bf2c6de"
setup = """## Setup
The 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).
Steps to implement the logging policy with Advanced Audit Configuration:
```
Computer Configuration >
Policies >
Windows Settings >
Security Settings >
Advanced Audit Policies Configuration >
Audit Policies >
DS Access >
Audit Directory Service Changes (Success,Failure)
```
The above policy does not cover User objects, so we need to set up an AuditRule using https://github.com/OTRF/Set-AuditRule.
As this specifies the msDS-KeyCredentialLink Attribute GUID, it is expected to be low noise.
```
Set-AuditRule -AdObjectPath 'AD:\\CN=Users,DC=Domain,DC=com' -WellKnownSidType WorldSid -Rights WriteProperty -InheritanceFlags Children -AttributeGUID 5b47d60f-6090-40b2-9f37-2a4de88f3063 -AuditFlags Success
```
"""
severity = "high"
tags = [
"Domain: Endpoint",
@@ -101,9 +47,139 @@ type = "query"
query = '''
event.code:"5136" and host.os.type:"windows" and winlog.event_data.AttributeLDAPDisplayName:"msDS-KeyCredentialLink" and
winlog.event_data.AttributeValue :B\:828* and
not winlog.event_data.SubjectUserName: MSOL_*
not winlog.event_data.SubjectUserName: MSOL_* and
not winlog.event_data.ObjectClass: "msDS-Device"
'''
note = """## Triage and analysis
### Investigating Potential Shadow Credentials added to AD Object
#### Possible investigation steps
- What object received the key-trust change?
- Focus: `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectGUID`, `winlog.event_data.ObjectClass`, `winlog.event_data.OperationType`, and `winlog.event_data.AttributeValue`.
- Implication: escalate when a sensitive user or computer receives an added or replaced key-trust value outside recognized enrollment; lower suspicion only when the object class, DN, and operation fit the same identity-registration workflow.
- Which account and logon session wrote the value?
- Focus: `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectLogonId`, recovered `source.ip`, and `winlog.logon.type`. $investigate_0
- Hint: match alert `winlog.event_data.SubjectLogonId` to same `host.id` authentication events with `winlog.event_data.TargetLogonId`; if no 4624 matches, keep the session unresolved.
- Implication: escalate for an unexpected user, admin, service, or machine writer, or source/logon type outside the object's enrollment path; lower suspicion when writer and session match recognized provisioning or device registration.
- Does the writer/object pair fit a recognized ADFS or Azure AD Connect-style path?
- Why: the abuse path writes authentication material, so service-looking writers still need source and change-set validation.
- Focus: compare `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.ObjectClass`, `winlog.event_data.ObjectDN`, and `source.ip` to the expected service account, object type, and enrollment source.
- Implication: lower suspicion when recognized provisioning updates the expected object from the expected source; escalate when the writer is ad hoc, interactive, non-provisioning, object-class mismatched, or unexplained by source.
- Was the logical change limited to this key credential?
- Focus: use same-operation 5136 events grouped by `winlog.event_data.OpCorrelationID`; compare `winlog.event_data.ObjectGUID`, `winlog.event_data.AttributeLDAPDisplayName`, `winlog.event_data.OperationType`, and `winlog.event_data.AttributeValue`. $investigate_1
- Implication: escalate when the operation touches unrelated objects, adds other authentication or delegation material, or removes cleanup evidence; lower suspicion when bounded to the expected object and enrollment attributes.
- Did the modified identity authenticate after the change?
- Why: post-change authentication shows whether the new key material may already be in use.
- Focus: derive the principal from `winlog.event_data.ObjectDN`; review authentication events for `winlog.event_data.TargetUserName`, `winlog.event_data.TargetDomainName`, `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`.
- Hint: search after `@timestamp` for Target-side fields matching the derived principal; if `source.ip` is empty, lower origin confidence instead of treating absence as benign.
- Implication: escalate when the identity authenticates from a new source, unexpected logon type, or authentication path after the change; absence of follow-on use reduces urgency only when earlier evidence proves recognized provisioning.
- Do related alerts change the scope beyond this object?
- Focus: recent alerts for the modifying account using `user.id` or `winlog.event_data.SubjectUserSid`. $investigate_2
- Hint: compare with alerts scoped to the modified object's `winlog.event_data.ObjectGUID`. $investigate_3
- Implication: broaden response when either scope shows privilege abuse, directory tampering, relay activity, or lateral movement; keep local when related alerts are quiet and local evidence resolves to one recognized workflow.
- Escalate on the key-trust change plus any suspicious or unresolved object, writer session, `winlog.event_data.OpCorrelationID` scope, post-change authentication, or related-alert finding; close only when all evidence binds to one recognized provisioning workflow; preserve and escalate when evidence is mixed, incomplete, or uncorroborated.
### False positive analysis
- AutoPilot or WHfB device enrollment can cause a computer to write its own key credential. Confirm `winlog.event_data.SubjectUserName` matches the CN in `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectClass` is "computer", `winlog.event_data.OpCorrelationID` is bounded, and no unexpected follow-on authentication occurs.
- ADFS or Azure AD Connect provisioning can update key credentials on user or computer objects. Confirm `winlog.event_data.SubjectUserSid`, `winlog.event_data.ObjectDN`, recovered `source.ip`, bounded `winlog.event_data.OpCorrelationID`, and post-change authentication align with one named workflow. Keep open when ownership is unresolved.
- Build exceptions from stable writer SID, object class or GUID, `host.id`, recovered source, and enrollment path across prior alerts. Avoid exceptions on "msDS-KeyCredentialLink", `user.name`, or host alone.
### Response and remediation
- Preserve a case export of the triggering 5136, recovered writer-session authentication events, `winlog.event_data.AttributeValue`, `winlog.event_data.ObjectGUID`, and `winlog.event_data.OpCorrelationID` before containment, reversal, or cleanup.
- If confirmed benign, reverse temporary containment and document the exact workflow evidence: writer SID, object GUID/class, domain naming context, recovered source, bounded change set, and post-change authentication pattern. Keep any exception narrow and only for the recurring workflow.
- If suspicious but unconfirmed, apply reversible controls to the writer first, such as heightened monitoring or temporary access review; restrict the modified identity only when object sensitivity or follow-on authentication shows active risk.
- If confirmed malicious, contain the writer account or source system using `winlog.event_data.SubjectLogonId`, `source.ip`, `host.id`, and follow-on authentication evidence. Disable the writer first when its session performed unauthorized changes; disable or rotate the modified identity only when post-change authentication or object sensitivity shows active risk.
- After containment, remove only the unauthorized key-trust value and verify rollback. Reset or rotate the modified identity according to `winlog.event_data.ObjectClass`: reset user passwords, rotate service credentials, or re-establish the expected computer trust path. Review the same `winlog.event_data.OpCorrelationID` or session for additional unauthorized changes.
- Post-incident hardening: restrict write access to "msDS-KeyCredentialLink" to dedicated identity-management accounts, retain 5136 auditing on domain controllers, and record the confirmed provisioning workflow or abuse pattern for future triage.
"""
setup = """## Setup
Audit Directory Service Changes must be enabled to generate the events used by this rule.
Setup instructions: https://ela.st/audit-directory-service-changes
"""
[rule.investigation_fields]
field_names = [
"@timestamp",
"user.id",
"winlog.event_data.SubjectUserSid",
"winlog.event_data.SubjectUserName",
"winlog.event_data.SubjectDomainName",
"winlog.event_data.SubjectLogonId",
"winlog.event_data.ObjectDN",
"winlog.event_data.ObjectGUID",
"winlog.event_data.ObjectClass",
"winlog.event_data.AttributeLDAPDisplayName",
"winlog.event_data.AttributeValue",
"winlog.event_data.OperationType",
"winlog.event_data.OpCorrelationID",
"host.name",
"host.id",
]
[transform]
[[transform.investigate]]
label = "Successful logon for the modifying session"
description = ""
providers = [
[
{ excluded = false, field = "event.code", queryType = "phrase", value = "4624", valueType = "string" },
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "winlog.event_data.TargetLogonId", queryType = "phrase", value = "{{winlog.event_data.SubjectLogonId}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[transform.investigate]]
label = "Directory changes in the same operation"
description = ""
providers = [
[
{ excluded = false, field = "event.code", queryType = "phrase", value = "5136", valueType = "string" },
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "winlog.event_data.OpCorrelationID", queryType = "phrase", value = "{{winlog.event_data.OpCorrelationID}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[transform.investigate]]
label = "Alerts associated with the modifying account"
description = ""
providers = [
[
{ excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
{ excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[transform.investigate]]
label = "Alerts associated with the modified object"
description = ""
providers = [
[
{ excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
{ excluded = false, field = "winlog.event_data.ObjectGUID", queryType = "phrase", value = "{{winlog.event_data.ObjectGUID}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[rule.threat]]
framework = "MITRE ATT&CK"
rules/windows/credential_access_suspicious_comsvcs_imageload.toml
+130 -97
View File
@@ -2,33 +2,7 @@
creation_date = "2021/10/17"
integration = ["windows"]
maturity = "production"
updated_date = "2026/04/10"
[transform]
[[transform.osquery]]
label = "Osquery - Retrieve DNS Cache"
query = "SELECT * FROM dns_cache"
[[transform.osquery]]
label = "Osquery - Retrieve All Services"
query = "SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"
[[transform.osquery]]
label = "Osquery - Retrieve Services Running on User Accounts"
query = """
SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE
NOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR
user_account == null)
"""
[[transform.osquery]]
label = "Osquery - Retrieve Service Unsigned Executables with Virustotal Link"
query = """
SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,
services.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =
authenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'
"""
updated_date = "2026/04/27"
[rule]
author = ["Elastic"]
@@ -42,76 +16,9 @@ index = ["winlogbeat-*", "logs-windows.sysmon_operational-*"]
language = "eql"
license = "Elastic License v2"
name = "Potential Credential Access via Renamed COM+ Services DLL"
note = """## Triage and analysis
### Investigating Potential Credential Access via Renamed COM+ Services DLL
COMSVCS.DLL is a Windows library that exports the MiniDump function, which can be used to dump a process memory. Adversaries may attempt to dump LSASS memory using a renamed COMSVCS.DLL to bypass command-line based detection and gain unauthorized access to credentials.
This rule identifies suspicious instances of rundll32.exe loading a renamed COMSVCS.DLL image, which can indicate potential abuse of the MiniDump function for credential theft.
> **Note**:
> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.
### Possible investigation steps
- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
- Investigate any abnormal behavior by the subject process, such as network connections, registry or file modifications, and any spawned child processes.
- Identify the process that created the DLL using file creation events.
- Inspect the file for useful metadata, such as file size and creation or modification time.
- Examine the host for derived artifacts that indicate suspicious activities:
- Analyze the process executable and DLL using a private sandboxed analysis system.
- Observe and collect information about the following activities in both the sandbox and the alert subject host:
- Attempts to contact external domains and addresses.
- Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process's `process.entity_id`.
- Examine the DNS cache for suspicious or anomalous entries.
- $osquery_0
- Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.
- Examine the host services for suspicious or anomalous entries.
- $osquery_1
- $osquery_2
- $osquery_3
- Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.
- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.
- Look for the presence of relevant artifacts on other systems. Identify commonalities and differences between potentially compromised systems.
### False positive analysis
- False positives may include legitimate instances of rundll32.exe loading a renamed COMSVCS.DLL image for non-malicious purposes, such as during software development, testing, or troubleshooting.
### Related Rules
- Potential Credential Access via LSASS Memory Dump - 9960432d-9b26-409f-972b-839a959e79e2
- Suspicious Module Loaded by LSASS - 3a6001a0-0939-4bbe-86f4-47d8faeb7b97
- Suspicious Lsass Process Access - 128468bf-cab1-4637-99ea-fdf3780a4609
- LSASS Process Access via Windows API - ff4599cb-409f-4910-a239-52e4e6f532ff
### Response and Remediation
- Initiate the incident response process based on the outcome of the triage.
- If malicious activity is confirmed, perform a broader investigation to identify the scope of the compromise and determine the appropriate remediation steps.
- Implement Elastic Endpoint Security to detect and prevent further post exploitation activities in the environment.
- Contain the affected system by isolating it from the network to prevent further spread of the attack.
- If the triage identified malware, search the environment for additional compromised hosts.
- Implement temporary network rules, procedures, and segmentation to contain the malware.
- Stop suspicious processes.
- Immediately block the identified indicators of compromise (IoCs).
- Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
- Remove and block malicious artifacts identified during triage.
- Restore the affected system to its operational state by applying any necessary patches, updates, or configuration changes.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
"""
references = ["https://modexp.wordpress.com/2019/08/30/minidumpwritedump-via-com-services-dll/"]
risk_score = 73
rule_id = "c5c9f591-d111-4cf8-baec-c26a39bc31ef"
setup = """## Setup
You will need to enable logging of ImageLoads in your Sysmon configuration to include COMSVCS.DLL by Imphash or Original
File Name.
"""
severity = "high"
tags = [
"Domain: Endpoint",
@@ -126,14 +33,140 @@ type = "eql"
query = '''
sequence by process.entity_id with maxspan=1m
[process where host.os.type == "windows" and event.category == "process" and
process.name : "rundll32.exe"]
[process where host.os.type == "windows" and event.category == "process" and data_stream.dataset : "windows.sysmon_operational" and event.code == "7" and
[process where host.os.type == "windows" and event.type == "start" and process.name : "rundll32.exe"]
[process where host.os.type == "windows" and event.code == "7" and
(file.pe.original_file_name : "COMSVCS.DLL" or file.pe.imphash : "EADBCCBB324829ACB5F2BBE87E5549A8") and
/* renamed COMSVCS */
not file.name : "COMSVCS.DLL"]
'''
note = """## Triage and analysis
### Investigating Potential Credential Access via Renamed COM+ Services DLL
#### Possible investigation steps
- What did the sequence source events prove about the loader and renamed COMSVCS image?
- Why: Timeline source events are required for grouped meaning; renamed COMSVCS can bypass command-line-only checks, so image-load PE identity matters.
- Focus: recover source events, confirm shared `process.entity_id`, and review the rundll32.exe start plus image-load `file.path`, `file.name`, `file.pe.original_file_name`, and `file.pe.imphash`.
- Implication: escalate when the same rundll32.exe instance loaded a renamed image whose original name or imphash maps to COMSVCS; lower suspicion only when source events and renamed path fit an authorized lab or debugging reproduction on the same `host.id` and `user.id`.
- Does the rundll32 command line and launch context show MiniDump intent?
- Focus: recovered process-start `process.command_line`, `process.parent.executable`, `process.parent.command_line`, and `user.id`.
- Implication: escalate when the command line invokes MiniDump or MiniDumpW with target PID, dump path, and full, or the parent is an unexpected script, shell, archive, or remote tool; lower suspicion only when parent, user, and host match the authorized test context.
- Was the renamed COMSVCS DLL staged or renamed immediately before rundll32 loaded it?
- Focus: loaded `file.path`, endpoint file telemetry on `host.id` and recovered `process.entity_id`, plus `process.executable`, `file.Ext.original.path`, and `file.Ext.original.name`. $investigate_0
- Hint: missing file-create or rename telemetry leaves provenance unresolved, not benign; bound findings to observed timing and lineage.
- Implication: escalate when a different suspicious process copied or renamed COMSVCS into a user-writable, temporary, or deceptive path shortly before the load; lower suspicion only when a lab or debugging tool created the same controlled artifact in an expected test path.
- Did the same process produce dump artifacts or credential-staging evidence?
- Focus: child-process events where `process.parent.entity_id` matches the alerting `process.entity_id`, child `process.command_line`, and endpoint file telemetry when available for `file.path`, `file.extension`, and `file.size` dump, archive, or staging output. $investigate_1
- Implication: escalate when the process or descendants write dump-like files, archives, or credential-access artifacts after MiniDump parameters; keep unresolved when telemetry is missing, and lower suspicion only when output stays confined to the authorized test target and path.
- If local evidence is suspicious or incomplete, do related alerts expand the scope?
- Focus: recent alerts for `user.id`. $investigate_2
- Hint: compare with recent alerts for `host.id` to distinguish user-linked activity from host-local spread. $investigate_3
- Implication: expand response scope when the same user or host has related dumping, defense-evasion, or intrusion alerts; keep scope local only when related alerts are absent and the recovered loader evidence is fully resolved.
- Escalate when source-event identity, MiniDump intent, parent lineage, provenance, artifacts, or related alerts support abuse; close only when recovered source events, available file evidence, and outside confirmation bind one exact authorized lab or debugging workflow; preserve and escalate when evidence is mixed or incomplete.
### False positive analysis
- Renaming COMSVCS for rundll32.exe loading is an operational anti-pattern. Close as benign only for authorized malware research, internal detonation, or debugging reproduction where source events, launcher parent, `user.id`, `host.id`, recovered renamed-DLL identity, and any dump output all align with the same test case. Without lab records, recurrence of the same loader chain, controlled artifact identity, host or user scope, and bounded follow-on pattern can support a candidate exception, but not closure. Do not close if any anchor diverges.
- Build exceptions only from the minimum confirmed workflow: parent process, controlled renamed-DLL artifact identity, `host.id`, `user.id`, and bounded output path. Avoid exceptions on rundll32.exe, COMSVCS identity, or the imphash alone because those values also describe the abuse technique.
### Response and remediation
- If confirmed benign, reverse any temporary containment and document the parent process, controlled renamed-DLL artifact identity, output path, `host.id`, and `user.id` that proved the authorized test. Keep exceptions narrow and require recurrence of the same workflow.
- If suspicious but unconfirmed, preserve the Timeline source events, recovered process identifiers, command line, parent context, renamed-DLL artifact details, staging evidence, and any dump or archive artifacts before containment. Apply reversible containment such as host isolation with criticality review or heightened monitoring on the affected `host.id`; avoid process termination or file deletion until evidence is preserved.
- If confirmed malicious, isolate the affected `host.id` after preserving source events, process context, renamed DLL, dump artifacts, and related-alert evidence. If direct response is unavailable, escalate with the preserved evidence set to the team that can act.
- Eradicate only the renamed DLL, dump files, archives, and staged artifacts identified during the investigation, then search the same host and related-alert scope for additional credential-dumping components. Reset or rotate credentials when dump artifacts, LSASS targeting, or privileged-host context indicate likely exposure.
- Post-incident hardening: restrict COMSVCS dump testing to controlled lab hosts, retain Sysmon image-load and file-create telemetry where it limited the case, and document the confirmed workflow or malicious artifact set for future triage.
"""
setup = """## Setup
This rule requires Sysmon telemetry to be enabled and ingested.
Setup instructions: https://ela.st/sysmon-event-7-setup
"""
[rule.investigation_fields]
field_names = [
"@timestamp",
"host.name",
"host.id",
"user.name",
"user.id",
"process.entity_id",
"process.pid",
"process.executable",
"process.command_line",
"process.parent.executable",
"process.parent.command_line",
"file.path",
"file.name",
"file.pe.original_file_name",
"file.pe.imphash",
]
[transform]
[[transform.investigate]]
label = "File activity for the alerting process and children"
description = ""
providers = [
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
{ excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" }
],
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
{ excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "Child processes of the alerting process"
description = ""
providers = [
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
{ excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "Alerts associated with the user"
description = ""
providers = [
[
{ excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
{ excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[transform.investigate]]
label = "Alerts associated with the host"
description = ""
providers = [
[
{ excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[rule.threat]]
framework = "MITRE ATT&CK"
rules/windows/credential_access_suspicious_lsass_access_memdump.toml
+164 -52
View File
@@ -2,7 +2,7 @@
creation_date = "2021/10/07"
integration = ["windows"]
maturity = "production"
updated_date = "2025/03/20"
updated_date = "2026/04/27"
[rule]
author = ["Elastic"]
@@ -15,41 +15,6 @@ index = ["winlogbeat-*", "logs-windows.sysmon_operational-*"]
language = "eql"
license = "Elastic License v2"
name = "Potential Credential Access via LSASS Memory Dump"
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Potential Credential Access via LSASS Memory Dump
LSASS (Local Security Authority Subsystem Service) is crucial for managing Windows security policies and storing sensitive data like user credentials. Adversaries exploit this by using tools that leverage MiniDumpWriteDump from libraries like DBGHelp.dll to extract credentials. The detection rule identifies suspicious LSASS access by monitoring for these libraries in call traces, excluding legitimate crash handlers, thus flagging potential credential theft attempts.
### Possible investigation steps
- Review the process details associated with the alert, focusing on the process name, executable path, and parent process to determine if the process accessing LSASS is legitimate or suspicious.
- Examine the call trace details to confirm the presence of DBGHelp.dll or DBGCore.dll, which are indicative of potential credential dumping attempts.
- Check for any recent crash reports or legitimate use of WerFault.exe, WerFaultSecure.exe, or similar processes that might explain the LSASS access as a non-malicious event.
- Investigate the user account context under which the suspicious process is running to assess if it aligns with expected behavior or if it indicates potential compromise.
- Correlate the event with other security logs or alerts to identify any related suspicious activities, such as unauthorized access attempts or lateral movement within the network.
- Assess the risk and impact by determining if any sensitive credentials could have been exposed, and consider isolating the affected system to prevent further compromise.
### False positive analysis
- Legitimate crash handlers like WerFault.exe may access LSASS during system crashes. To prevent these from being flagged, ensure that the rule excludes processes such as WerFault.exe, WerFaultSecure.exe, and their SysWOW64 counterparts.
- Debugging tools used by developers or IT administrators might trigger this rule if they access LSASS for legitimate purposes. Consider creating exceptions for known and trusted debugging tools within your environment.
- Security software or endpoint protection solutions may perform similar actions as part of their normal operations. Verify with your security vendor and exclude these processes if they are confirmed to be benign.
- Automated system diagnostics or maintenance scripts that interact with LSASS for health checks could be misidentified. Review and whitelist these scripts if they are part of routine system management tasks.
- Ensure that any custom or third-party applications that require access to LSASS for legitimate reasons are documented and excluded from the rule to avoid unnecessary alerts.
### Response and remediation
- Immediately isolate the affected system from the network to prevent further credential access or lateral movement by the adversary.
- Terminate any suspicious processes that are accessing the LSASS memory, especially those involving DBGHelp.dll or DBGCore.dll, to stop the credential dumping activity.
- Conduct a thorough review of the affected system's security logs to identify any unauthorized access or changes, focusing on event code "10" and call traces involving LSASS.
- Change passwords for all accounts that were active on the affected system, prioritizing high-privilege accounts, to mitigate the risk of compromised credentials being used.
- Restore the affected system from a known good backup to ensure that any malicious changes or tools are removed.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems may be affected.
- Implement enhanced monitoring and alerting for similar suspicious activities, focusing on LSASS access and the use of MiniDumpWriteDump, to improve detection and response capabilities."""
references = [
"https://www.ired.team/offensive-security/credential-access-and-credential-dumping/dump-credentials-from-lsass-process-without-mimikatz",
"https://www.elastic.co/security-labs/detect-credential-access",
@@ -57,21 +22,12 @@ references = [
]
risk_score = 73
rule_id = "9960432d-9b26-409f-972b-839a959e79e2"
setup = """## Setup
If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2,
events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2.
Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate
`event.ingested` to @timestamp.
For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html
"""
severity = "high"
tags = [
"Domain: Endpoint",
"OS: Windows",
"Use Case: Threat Detection",
"Tactic: Credential Access",
"Tactic:Execution",
"Data Source: Sysmon",
"Resources: Investigation Guide",
]
@@ -82,10 +38,10 @@ query = '''
process where host.os.type == "windows" and event.code == "10" and
winlog.event_data.TargetImage : "?:\\WINDOWS\\system32\\lsass.exe" and
/* DLLs exporting MiniDumpWriteDump API to create an lsass mdmp*/
winlog.event_data.CallTrace : ("*dbghelp*", "*dbgcore*") and
/* dbgcore.dll hosts MiniDumpWriteDump on modern Windows; dbghelp-only traces are non-dump usage */
winlog.event_data.CallTrace : "*dbgcore*" and
/* case of lsass crashing */
/* crash handlers */
not process.executable : (
"?:\\Windows\\System32\\WerFault.exe",
"?:\\Windows\\SysWOW64\\WerFault.exe",
@@ -93,6 +49,166 @@ process where host.os.type == "windows" and event.code == "10" and
)
'''
note = """## Triage and analysis
### Investigating Potential Credential Access via LSASS Memory Dump
#### Possible investigation steps
- What did the process-access event prove?
- Focus: `winlog.event_data.SourceImage`, `winlog.event_data.SourceProcessGUID`, `winlog.event_data.TargetImage`, `winlog.event_data.GrantedAccess`, and `winlog.event_data.CallTrace`.
- Implication: escalate on a non-WerFault source touching LSASS with dbgcore in the call trace plus any corroborator; lower concern only when the tuple matches a stable EDR, crash-analysis, support, or authorized-test workflow on that `host.id`.
- Does the source process match a recognized diagnostic tool?
- Focus: recover the process start on the same `host.id` using `winlog.event_data.SourceProcessGUID` or `process.entity_id`, then review `process.executable`, `process.command_line`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. $investigate_0
- Hint: if the source lacks `winlog.event_data.SourceProcessGUID`, fall back to `winlog.event_data.SourceImage`, `host.id`, and a tight window around `@timestamp`; if PE or signature metadata is absent, keep identity unresolved rather than inferring trust from path.
- Implication: escalate when the recovered source is unsigned, renamed, user-writable, or uses MiniDumpWriteDump-adjacent arguments such as ProcDump-style switches or rundll32 with comsvcs.dll; if process-start telemetry is unavailable, treat identity as unresolved and do not close on `winlog.event_data.SourceImage` alone.
- Does the recovered launch chain explain why this process would touch LSASS?
- Focus: `process.command_line`, `process.parent.executable`, `process.parent.command_line`, `process.Ext.authentication_id`, and `user.id`; use `process.Ext.ancestry` when parent context is incomplete.
- Implication: escalate when shells, script hosts, Office, browsers, archive tools, or remote-admin launchers start the accessor, or when `user.id` does not fit recognized troubleshooting; record `process.Ext.authentication_id` only as a later session bridge, and treat missing lineage as unresolved rather than benign.
- Do same-source file events show dump creation, rename, or staging?
- Focus: same-host file events for recovered `process.entity_id`, or `host.id` plus `process.pid` in a tight alert window; read `file.path`, `file.name`, `file.Ext.original.path`, and `file.size`. $investigate_1
- Implication: escalate when the accessor writes dump output to temp, public, user-writable, or share paths, or renames it into archives or deceptive extensions; missing file telemetry is unresolved, not benign.
- Do surrounding process events show dump handling, archive, copy, or cleanup?
- Focus: child process starts from the recovered accessor on the same `host.id`, especially `process.parent.entity_id`, `process.executable`, `process.command_line`, and `@timestamp`. $investigate_2
- Hint: sibling process review remains a manual expansion from the recovered parent/session context.
- Implication: escalate when archivers, copy tools, PowerShell, rundll32, or cleanup commands appear immediately before or after the access; if process telemetry is sparse, preserve the gap and rely on the access tuple plus other corroborators.
- Do authentication events suggest the account pivoted after the access?
- Why: MiniDumpWriteDump-style LSASS access is usually a precursor step; later credential use matters more than the access alone.
- Focus: after process recovery, use `process.Ext.authentication_id` and `host.id` to review authentication events via `winlog.event_data.TargetLogonId`; search `winlog.event_data.SubjectLogonId` separately for "4648" explicit-credential context.
- Hint: if the process does not preserve `process.Ext.authentication_id`, skip the auth bridge and record the gap.
- Implication: escalate when the linked session or `user.id` shows unexpected remote logons, explicit-credential use, or admin-share access soon after; missing authentication telemetry is unresolved, not benign.
- If source identity, artifacts, or follow-on activity remain suspicious, do related alerts widen scope?
- Focus: related `user.id` alerts for credential access, lateral movement, privilege escalation, or suspicious authentication. $investigate_3
- Hint: compare `host.id` alerts to separate account reuse from host-local dump staging. $investigate_4
- Implication: broaden when the same user or host also triggers dumping, suspicious logon, lateral movement, or exfiltration findings; keep local when related alerts are absent.
- Escalate when LSASS access plus one meaningful corroborator points to unauthorized dump preparation or credential use; close only when identity, access tuple, launch, artifacts, authentication, and scope align with one recognized benign workflow; preserve and escalate if mixed or incomplete.
### False positive analysis
- Recognized EDR, crash-analysis, vendor-support, or authorized testing tooling can legitimately touch LSASS through dbgcore. Close only when the alert tuple, recovered source identity, parent context, `user.id`, and `host.id` all point to that same workflow, with no contradictory dump artifact or post-access authentication evidence. Case records, inventories, and owner confirmation can corroborate but not replace the telemetry match.
- Before exceptioning, validate recurrence for the same recovered tool identity, signer, parent context, `winlog.event_data.SourceImage`, `user.id`, and `host.id`. Avoid exceptions on `winlog.event_data.CallTrace`, `winlog.event_data.TargetImage`, or LSASS access alone.
### Response and remediation
- If confirmed benign, reverse temporary containment and document the alert tuple, recovered source identity, parent context, `user.id`, `host.id`, and absence of contradictory dump or post-access authentication evidence. Create an exception only if the same stable workflow recurs.
- If suspicious but unconfirmed, preserve the full alert event, recovered source process event, dump artifacts, linked authentication records, `user.id`, and `host.id` before containment. Apply reversible containment first, such as heightened monitoring or temporary restrictions on the affected `host.id`; weigh host criticality before isolating domain controllers or other privileged systems, and escalate to isolation only when dump artifacts or linked authentication evidence indicates likely credential exposure.
- If confirmed malicious, preserve the alert tuple, source process identifiers, command line, parent context, dump artifact paths, and linked authentication evidence before terminating processes or deleting files. Then isolate the endpoint; if direct response is unavailable, escalate with the preserved artifact set. Restrict affected share paths when share-staged dumps were identified.
- On servers, jump hosts, or privileged admin systems, scope which local, cached, service, or administrative credentials may have been exposed, then reset or rotate affected credentials according to their role and exposure.
- Before eradication, review related hosts and users for the same source image, dump path pattern, or transfer target. Then remove dump utilities, scripts, archives, copied dumps, persistence mechanisms, and remediate the privilege path or initial access route that enabled the LSASS access.
- Post-incident hardening: retain Sysmon Event ID 10 plus supporting process, file, and authentication telemetry, and document adjacent LSASS dump paths such as ProcDump-style switches or rundll32 with comsvcs.dll for the detection engineering team.
"""
setup = """## Setup
This rule requires Sysmon telemetry to be enabled and ingested.
Setup instructions: https://ela.st/sysmon-event-10-setup
"""
[rule.investigation_fields]
field_names = [
"@timestamp",
"host.name",
"host.id",
"user.name",
"user.id",
"process.entity_id",
"process.pid",
"process.executable",
"process.command_line",
"winlog.event_data.SourceProcessGUID",
"winlog.event_data.SourceImage",
"winlog.event_data.TargetImage",
"winlog.event_data.GrantedAccess",
"winlog.event_data.CallTrace",
]
[transform]
[[transform.investigate]]
label = "Source process events by GUID"
description = ""
providers = [
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{winlog.event_data.SourceProcessGUID}}", valueType = "string" },
{ excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }
],
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
{ excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "File activity for the source process"
description = ""
providers = [
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{winlog.event_data.SourceProcessGUID}}", valueType = "string" },
{ excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" }
],
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
{ excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "Child process events for the source process"
description = ""
providers = [
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{winlog.event_data.SourceProcessGUID}}", valueType = "string" },
{ excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }
],
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
{ excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "Alerts associated with the user"
description = ""
providers = [
[
{ excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
{ excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[transform.investigate]]
label = "Alerts associated with the host"
description = ""
providers = [
[
{ excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[rule.threat]]
framework = "MITRE ATT&CK"
@@ -105,8 +221,6 @@ id = "T1003.001"
name = "LSASS Memory"
reference = "https://attack.mitre.org/techniques/T1003/001/"
[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
@@ -118,9 +232,7 @@ id = "T1106"
name = "Native API"
reference = "https://attack.mitre.org/techniques/T1106/"
[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
rules/windows/credential_access_suspicious_lsass_access_via_snapshot.toml
+130 -44
View File
@@ -2,7 +2,7 @@
creation_date = "2021/10/14"
integration = ["windows"]
maturity = "production"
updated_date = "2025/03/20"
updated_date = "2026/04/27"
[rule]
author = ["Elastic"]
@@ -16,51 +16,12 @@ index = ["winlogbeat-*", "logs-windows.sysmon_operational-*"]
language = "kuery"
license = "Elastic License v2"
name = "Potential LSASS Memory Dump via PssCaptureSnapShot"
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Potential LSASS Memory Dump via PssCaptureSnapShot
PssCaptureSnapShot is a Windows feature used for capturing process snapshots, aiding in diagnostics and debugging. Adversaries exploit this to access LSASS memory, aiming to extract credentials. The detection rule identifies suspicious behavior by monitoring for repeated access to LSASS by the same process, targeting different instances, which may indicate an evasion attempt to dump credentials stealthily.
### Possible investigation steps
- Review the event logs for the specific event code 10 to gather details about the process that accessed the LSASS handle, including the process name, process ID, and the time of access.
- Check the process execution history on the host to determine if the process accessing LSASS is legitimate or potentially malicious. Look for any unusual or unexpected processes that might have been executed around the time of the alert.
- Investigate the parent process of the suspicious process to understand how it was initiated and whether it was spawned by a legitimate application or a known malicious process.
- Analyze the network activity of the host around the time of the alert to identify any suspicious outbound connections that might indicate data exfiltration attempts.
- Correlate the alert with other security events or alerts from the same host or user account to identify any patterns or additional indicators of compromise.
- Verify the integrity and security posture of the host by checking for any unauthorized changes to system files or configurations, especially those related to security settings.
### False positive analysis
- Legitimate diagnostic tools or software that utilize PssCaptureSnapShot for debugging purposes may trigger this rule. Users should identify and whitelist these trusted applications to prevent false positives.
- System administrators or security tools performing regular health checks on LSASS might access LSASS memory in a non-malicious manner. Exclude these known processes by creating exceptions based on their process names or hashes.
- Automated scripts or maintenance tasks that interact with LSASS for legitimate reasons could be flagged. Review and document these tasks, then configure the rule to ignore these specific activities.
- Security software updates or patches that temporarily access LSASS for validation or configuration purposes may cause alerts. Monitor update schedules and adjust the rule to accommodate these temporary accesses.
### Response and remediation
- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
- Terminate any suspicious processes identified as accessing LSASS memory using PssCaptureSnapShot to halt potential credential dumping activities.
- Conduct a thorough review of the affected system's event logs, focusing on event code 10, to identify any additional instances of suspicious LSASS access and determine the scope of the compromise.
- Change all potentially compromised credentials, especially those with administrative privileges, to mitigate the risk of unauthorized access using dumped credentials.
- Apply the latest security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
- Enhance monitoring and detection capabilities by ensuring that similar suspicious activities are logged and alerted on, using the specific query fields and threat indicators identified in this alert."""
references = [
"https://www.matteomalvica.com/blog/2019/12/02/win-defender-atp-cred-bypass/",
"https://twitter.com/sbousseaden/status/1280619931516747777?lang=en",
]
risk_score = 73
rule_id = "0f93cb9a-1931-48c2-8cd0-f173fd3e5283"
setup = """## Setup
This is meant to run only on datasources using Elastic Agent 7.14+ since versions prior to that will be missing the threshold
rule cardinality feature.
"""
severity = "high"
tags = [
"Domain: Endpoint",
@@ -80,6 +41,134 @@ event.category:process and host.os.type:windows and event.code:10 and
"c:\\Windows\\System32\\lsass.exe")
'''
note = """## Triage and analysis
### Investigating Potential LSASS Memory Dump via PssCaptureSnapShot
#### Possible investigation steps
- What do the threshold summary and recovered members prove about the LSASS access pattern?
- Why: grouped threshold alerts require member recovery before the count proves a snapshot or repeated-access pattern.
- Focus: `process.entity_id`, `kibana.alert.threshold_result.count`, and Sysmon Event 10 members for `winlog.event_data.TargetProcessId`, `winlog.event_data.GrantedAccess`, and `winlog.event_data.CallTrace`. $investigate_0
- Implication: escalate when one process entity touched two distinct LSASS target PIDs and access or call-trace evidence fits snapshot or dump collection; lower concern only when members form one recognized debugger, EDR, or IR memory-acquisition pattern. If members cannot be recovered, the grouped alert stays unresolved, not benign.
- Which caller and stack evidence identify the snapshot or dump path?
- Focus: caller path, access mask, and call trace from recovered members on the same `host.id`.
- Implication: escalate when the caller is user-writable, renamed, unrelated to endpoint security, or the stack shows PssCaptureSnapshot, PssNtCaptureSnapshot, dbghelp, or MiniDumpWriteDump-style dumping; lower concern when caller, access mask, and stack match a recognized EDR, debugger, or forensic collector.
- Does the user-host context fit deliberate LSASS memory acquisition?
- Focus: `host.id`, `user.id`, `user.name`, and recovered caller.
- Implication: escalate when activity runs under a normal user, service account, workstation, domain controller, or jump host with no matching IR or security-collection purpose; lower concern only when the same host, user, and caller map to one recognized memory-acquisition workflow.
- If Windows Security logs are available, did authentication or source evidence show credential use after the LSASS access?
- Why: PssCaptureSnapshot-based LSASS access commonly precedes credential dumping, so post-access identity use changes urgency.
- Focus: `host.id` and `user.id`; if Windows Security logs exist for this host/window, recover authentication records before interpretation and use `source.*` only from those records, especially `event.code`, `winlog.event_data.TargetLogonId`, and `source.ip`.
- Implication: escalate when the same user or host shows new 4624 logons, 4648 explicit-credential use, rare `source.ip`, or remote access after LSASS events; use `winlog.event_data.TargetLogonId` to group logon records, not claim process-session continuity. Missing authentication telemetry is unresolved, not benign.
- If local evidence remains suspicious or unresolved, do related alerts change scope?
- Focus: credential-access, archive, lateral-movement, or clone-related alerts for the same `process.entity_id`, `user.id`, or `host.id`. $investigate_1 $investigate_2 $investigate_3
- Implication: broaden response when the same process entity also shows dumping, archive staging, suspicious authentication, lateral movement, or clone-related alerts; keep scope local when related alerts are absent, but do not use alert absence to clear recovered LSASS access evidence.
- Escalate when member pattern, caller or stack evidence, user-host context, authentication/source evidence, or related-alert scope supports unauthorized LSASS access or credential use; close only when member events and host/user context bind the alert to one recognized debugger, EDR, forensic, IR, or lab workflow with no contradictory evidence; preserve evidence and escalate when recovery is incomplete or findings conflict.
### False positive analysis
- Authorized debugger, EDR, forensic, IR memory-acquisition, or lab validation tooling can trigger this rule. Confirm from telemetry first: member-event pattern, caller or stack, `host.id`, and `user.id` must converge on the same workflow. Use case records or tool inventory only to corroborate that telemetry-bound workflow. If members are unavailable or any anchor contradicts it, do not close as benign.
- Before creating an exception, validate that the same stable caller, recovered target-PID/access/call-trace pattern, `host.id`, and `user.id` recur across prior alerts from this rule. Build the exception from that minimum confirmed workflow pattern. Avoid exceptions on `process.entity_id`, `kibana.alert.threshold_result.count`, or LSASS targeting alone.
### Response and remediation
- If confirmed benign, reverse temporary containment and document the alert summary, grouped `process.entity_id`, recovered member-event pattern, caller or stack evidence, `host.id`, `user.id`, and the corroborating case, tool, or lab record. Create an exception only for the recurring workflow pattern.
- If suspicious but unconfirmed, preserve the alert, Timeline member records, target-PID/access/call-trace evidence, recovered caller, `process.entity_id`, `host.id`, `user.id`, and any recovered authentication or source records before containment.
- If suspicious but unconfirmed, apply reversible containment first, such as heightened monitoring or temporary network isolation for the affected `host.id`; weigh host criticality before isolating domain controllers, jump hosts, or production servers.
- If confirmed malicious, isolate the affected host when recovered member events and caller or stack evidence confirm unauthorized LSASS access. Disable or reset accounts only when recovered authentication or source evidence indicates credential use or likely exposure.
- If confirmed malicious, collect the suspicious binary, dump outputs, scripts, archives, and memory-acquisition tooling identified during investigation before terminating processes or deleting files.
- If confirmed malicious, block confirmed remote sources or transfer paths identified during investigation, then eradicate the collected dump tooling and remediate the execution or privilege path that enabled LSASS access.
- Post-incident hardening: restrict LSASS snapshot and dump tooling to controlled security workflows, enable LSASS protection controls where compatible, retain Sysmon Event 10 and Windows Security logs, and document PssCaptureSnapshot or clone-based variants surfaced during triage.
"""
setup = """## Setup
This rule requires Sysmon telemetry to be enabled and ingested.
Setup instructions: https://ela.st/sysmon-event-10-setup
"""
[rule.investigation_fields]
field_names = [
"@timestamp",
"host.name",
"host.id",
"user.name",
"user.id",
"user.domain",
"process.entity_id",
"kibana.alert.threshold_result.count",
]
[transform]
[[transform.investigate]]
label = "Sysmon process access events for the grouped process entity"
description = ""
providers = [
[
{ excluded = false, field = "event.code", queryType = "phrase", value = "10", valueType = "string" },
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
{ excluded = false, field = "winlog.event_data.TargetImage", queryType = "phrase", value = "C:\\Windows\\system32\\lsass.exe", valueType = "string" }
],
[
{ excluded = false, field = "event.code", queryType = "phrase", value = "10", valueType = "string" },
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
{ excluded = false, field = "winlog.event_data.TargetImage", queryType = "phrase", value = "c:\\Windows\\system32\\lsass.exe", valueType = "string" }
],
[
{ excluded = false, field = "event.code", queryType = "phrase", value = "10", valueType = "string" },
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
{ excluded = false, field = "winlog.event_data.TargetImage", queryType = "phrase", value = "C:\\Windows\\System32\\lsass.exe", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "Alerts associated with the grouped process entity"
description = ""
providers = [
[
{ excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
{ excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[transform.investigate]]
label = "Alerts associated with the user"
description = ""
providers = [
[
{ excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
{ excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[transform.investigate]]
label = "Alerts associated with the host"
description = ""
providers = [
[
{ excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[rule.threat]]
framework = "MITRE ATT&CK"
@@ -92,8 +181,6 @@ id = "T1003.001"
name = "LSASS Memory"
reference = "https://attack.mitre.org/techniques/T1003/001/"
[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
@@ -102,8 +189,7 @@ reference = "https://attack.mitre.org/tactics/TA0006/"
[rule.threshold]
field = ["process.entity_id"]
value = 2
[[rule.threshold.cardinality]]
field = "winlog.event_data.TargetProcessId"
value = 2
rules/windows/credential_access_via_snapshot_lsass_clone_creation.toml
+141 -40
View File
@@ -2,7 +2,7 @@
creation_date = "2021/11/27"
integration = ["windows", "system"]
maturity = "production"
updated_date = "2025/03/20"
updated_date = "2026/04/27"
[rule]
author = ["Elastic"]
@@ -15,41 +15,6 @@ index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
language = "eql"
license = "Elastic License v2"
name = "Potential LSASS Clone Creation via PssCaptureSnapShot"
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Potential LSASS Clone Creation via PssCaptureSnapShot
PssCaptureSnapShot is a Windows API used for creating snapshots of processes, often for debugging. Adversaries exploit this to clone the LSASS process, aiming to extract credentials without detection. The detection rule identifies suspicious LSASS clones by monitoring process creation events where both the process and its parent are LSASS, signaling potential credential dumping attempts.
### Possible investigation steps
- Review the process creation event logs for the specific event code 4688 to confirm the creation of an LSASS process clone. Verify that both the process and its parent have the executable path "?:\\Windows\\System32\\lsass.exe".
- Check the timeline of events to determine if there are any preceding or subsequent suspicious activities related to the LSASS process, such as unusual access patterns or modifications.
- Investigate the user account and privileges associated with the process creation event to assess if the account has legitimate reasons to interact with LSASS or if it might be compromised.
- Analyze network activity from the host to identify any potential data exfiltration attempts or connections to known malicious IP addresses following the LSASS clone creation.
- Correlate this event with other security alerts or logs from the same host to identify if this is part of a broader attack pattern or isolated incident.
- Examine the host for any signs of malware or tools commonly used for credential dumping, such as Mimikatz, that might have been used in conjunction with the LSASS clone creation.
### False positive analysis
- Legitimate security software or system management tools may create LSASS process snapshots for monitoring or debugging purposes. Identify these tools and create exceptions for their process creation events to avoid false positives.
- System administrators or IT personnel might use authorized scripts or tools that interact with LSASS for legitimate reasons. Verify these activities and whitelist the associated processes to prevent unnecessary alerts.
- During system updates or patches, certain processes might temporarily mimic suspicious behavior. Monitor these updates and temporarily adjust detection rules to accommodate expected changes in process behavior.
- Some enterprise environments may have custom applications that interact with LSASS for performance monitoring. Document these applications and exclude their process creation events from triggering alerts.
- Regularly review and update the list of known benign processes and tools that interact with LSASS to ensure that the detection rule remains effective without generating excessive false positives.
### Response and remediation
- Immediately isolate the affected host from the network to prevent further credential access or lateral movement by the adversary.
- Terminate any suspicious LSASS clone processes identified by the detection rule to halt ongoing credential dumping activities.
- Conduct a thorough memory analysis of the affected system to identify any additional malicious activities or tools used by the adversary.
- Change all potentially compromised credentials, especially those with administrative privileges, to mitigate the risk of unauthorized access.
- Review and enhance endpoint security configurations to ensure that LSASS process memory is protected from unauthorized access, such as enabling Credential Guard if applicable.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.
- Implement additional monitoring and alerting for similar suspicious activities, focusing on process creation events involving LSASS, to improve early detection of future attempts."""
references = [
"https://www.matteomalvica.com/blog/2019/12/02/win-defender-atp-cred-bypass/",
"https://medium.com/@Achilles8284/the-birth-of-a-process-part-2-97c6fb9c42a2",
@@ -62,7 +27,6 @@ tags = [
"OS: Windows",
"Use Case: Threat Detection",
"Tactic: Credential Access",
"Data Source: Sysmon",
"Data Source: Windows Security Event Logs",
"Resources: Investigation Guide",
]
@@ -75,6 +39,146 @@ process where host.os.type == "windows" and event.code:"4688" and
process.parent.executable : "?:\\Windows\\System32\\lsass.exe"
'''
note = """## Triage and analysis
### Investigating Potential LSASS Clone Creation via PssCaptureSnapShot
#### Possible investigation steps
- Does the alert-local 4688 event show the LSASS-clone pattern?
- Focus: `event.code`, `process.executable`, `process.parent.executable`, `host.id`, `@timestamp`.
- Implication: treat the alert as clone creation when both paths resolve to lsass.exe on one host; lower suspicion only when the tuple maps to stable EDR, forensic, or debugging workflow.
- Hint: pivot with `host.id` plus `process.entity_id`; if absent, use `host.id`, `process.pid`, and a tight alert-time window.
- Do surrounding 4688 events reveal the setup or dump-conversion chain?
- Focus: same-host 4688 around `@timestamp`, especially `process.executable`, `process.command_line`, `process.parent.executable`, `user.id`, and terms such as "PssCaptureSnapshot", "MiniDumpWriteDump", "comsvcs", "rundll32", "WerFault", "procdump", "createdump", archive utilities, or cleanup commands. $investigate_0
- Implication: escalate when shells, PowerShell, dump helpers, archive tools, cleanup, or remote-admin launchers appear without the same recognized collection workflow; absence of helpers leaves the clone unresolved, not benign.
- If file telemetry exists, did the clone create dumps, archives, or renamed outputs?
- Focus: same-host file or child-process telemetry for `file.path`, `file.Ext.original.path` matching ".dmp", ".zip", ".7z", or renamed outputs. $investigate_1. If unavailable, use surrounding 4688 commands with output files or archive utilities.
- Implication: escalate when dump paths, archive names, or cleanup commands appear around clone creation. Missing file telemetry is unresolved, not benign.
- Do authentication events show follow-on remote use, explicit credentials, or unusual logons?
- Why: clone creation often precedes credential use; later auth can show post-dump pivoting.
- Focus: same-host 4624, 4648, and 4625 around `@timestamp`, using `winlog.event_data.TargetUserName`, `winlog.logon.type`, and `source.ip`. $investigate_2
- Implication: escalate when the host or user quickly shows new remote-interactive, service, or explicit-credential logons from unusual sources. If auth telemetry is missing, record the gap and keep the finding unresolved.
- Does same-user or same-host activity repeat the evidence pattern?
- Focus: same-user 48h alerts for helper commands, dump/archive names, or post-clone authentication. $investigate_3
- Hint: if user scope is sparse or the host is shared, review same-host alerts for process, output, and authentication evidence. $investigate_4
- Implication: broaden scope when helper-command, output, or authentication patterns repeat around clone windows; no repeat keeps response local but does not clear the clone.
- Escalate for unauthorized LSASS clone creation, dump preparation, post-clone credential use, or clone creation on domain controllers, jump hosts, or privileged admin systems; close only when the alert tuple and recovery evidence bind to one recognized EDR, forensic, or debugging workflow with no conflicting dump-conversion, output, or authentication evidence; preserve artifacts and escalate when answers are mixed or visibility is incomplete.
### False positive analysis
- Recognized EDR/forensic collection or bounded lab validation can create snapshot-based clones. Require the alert tuple, helper command line, `user.id`, `host.id`, dump-output pattern, and no unexpected 4624 or 4648 activity inside that workflow; use records only to corroborate unresolved telemetry.
- Before creating an exception, validate that the same `host.id` and `user.id` cohort repeats the same process identity, helper-command, output-path, and authentication pattern across prior alerts from this rule. Avoid exceptions on "lsass.exe", `event.code`, or `host.id` alone.
### Response and remediation
- If confirmed benign, reverse temporary containment and document the collection workflow identity, launcher path, actor, host scope, dump-output pattern, and follow-on authentication pattern. Create an exception only if that pattern recurs across prior alerts.
- If suspicious but unconfirmed, preserve the alert 4688 event, surrounding helper-process events, command lines, dump/archive paths, rename evidence, affected identities, and post-clone authentication records before containment. Apply reversible containment first, such as heightened monitoring or temporary restrictions on remote admin access; escalate to host isolation only when dump artifacts or post-clone authentication confirm likely credential exposure and the host role can tolerate interruption.
- If confirmed malicious, preserve the alert event, helper-process chain, dump/archive paths, rename evidence, and affected identities before containment. Then isolate the host through endpoint response; if unavailable, escalate with preserved evidence. Block confirmed remote-auth or transfer sources before cleanup.
- On domain controllers, jump hosts, or privileged admin systems, scope which local, cached, service, or domain credentials may have been exposed, then reset or rotate affected credentials before removing collected artifacts.
- Before eradication, review related hosts and users for the same helper-process pattern, dump path, `winlog.logon.type`, or `source.ip` indicators. Then remove dump files, archives, helper tools, and persistence, and remediate the access or privilege path that enabled clone creation.
- Post-incident hardening: restrict memory-acquisition and dump tooling to recognized admin cohorts, retain supplemental file telemetry where its absence limited the case, and document the confirmed workflow or malicious pattern for future triage.
"""
setup = """## Setup
Audit Process Creation and Command Line must be enabled to generate the events used by this rule.
Setup instructions: https://ela.st/audit-process-creation
"""
[rule.investigation_fields]
field_names = [
"@timestamp",
"host.name",
"host.id",
"user.name",
"user.id",
"user.domain",
"process.entity_id",
"process.pid",
"process.executable",
"process.command_line",
"process.parent.entity_id",
"process.parent.pid",
"process.parent.name",
"process.parent.executable",
"process.parent.command_line",
]
[transform]
[[transform.investigate]]
label = "Same-host 4688 process creation events"
description = ""
providers = [
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "event.code", queryType = "phrase", value = "4688", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "File activity on the affected host"
description = ""
providers = [
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "Authentication events on the affected host"
description = ""
providers = [
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "event.code", queryType = "phrase", value = "4624", valueType = "string" }
],
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "event.code", queryType = "phrase", value = "4648", valueType = "string" }
],
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "event.code", queryType = "phrase", value = "4625", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "Alerts associated with the user"
description = ""
providers = [
[
{ excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
{ excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[transform.investigate]]
label = "Alerts associated with the host"
description = ""
providers = [
[
{ excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[rule.threat]]
framework = "MITRE ATT&CK"
@@ -87,10 +191,7 @@ id = "T1003.001"
name = "LSASS Memory"
reference = "https://attack.mitre.org/techniques/T1003/001/"
[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"
rules/windows/credential_access_web_config_file_access.toml
+146 -47
View File
@@ -2,7 +2,7 @@
creation_date = "2025/07/23"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/03/24"
updated_date = "2026/04/27"
[rule]
author = ["Elastic"]
@@ -17,38 +17,6 @@ index = ["logs-endpoint.events.file-*"]
language = "kuery"
license = "Elastic License v2"
name = "Unusual Web Config File Access"
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Unusual Web Config File Access
Web.config files are crucial in Windows environments, storing sensitive data like database credentials and encryption keys. Adversaries target these files to extract information for attacks such as forging malicious requests or accessing databases. The detection rule identifies suspicious access patterns by monitoring file access events in specific directories, helping analysts spot potential credential theft or server exploitation attempts.
### Possible investigation steps
- Investigate the user account associated with the access event to verify if the account has legitimate reasons to access the web.config file or if it might be compromised.
- Analyze recent activity from the same user or IP address to identify any other suspicious behavior or access patterns that could indicate a broader security incident.
- Review system logs and network traffic around the time of the alert to identify any related anomalies or signs of exploitation attempts, such as unusual database queries or web server requests.
### False positive analysis
- Routine administrative tasks by IT personnel may trigger alerts when accessing web.config files for legitimate configuration updates. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
- Automated backup processes that access web.config files can be mistaken for suspicious activity. Identify and exclude these processes by their specific user accounts or service names.
- Web application updates or deployments often involve accessing web.config files. Exclude these activities by correlating them with known deployment tools or scripts.
- Security scanning tools that check web.config files for vulnerabilities might generate false positives. Whitelist these tools by their process names or IP addresses to prevent unnecessary alerts.
- Monitoring or logging solutions that periodically read web.config files for audit purposes can be excluded by identifying their specific access patterns and excluding them from the rule.
### Response and remediation
- Immediately isolate the affected server to prevent further unauthorized access and potential lateral movement within the network.
- Conduct a thorough review of the web.config file to identify any unauthorized changes or access patterns, focusing on exposed credentials and keys.
- Rotate all credentials and keys found within the web.config file, including database connection strings and encryption keys, to mitigate the risk of credential theft.
- Implement additional monitoring and logging for access to web.config files across all servers to detect future unauthorized access attempts.
- Escalate the incident to the security operations center (SOC) for further investigation and correlation with other potential indicators of compromise.
- Review and update firewall rules and access controls to ensure that only authorized users and applications can access sensitive directories containing web.config files.
- Conduct a post-incident analysis to identify gaps in security controls and enhance detection capabilities for similar threats in the future.
"""
references = [
"https://unit42.paloaltonetworks.com/microsoft-sharepoint-cve-2025-49704-cve-2025-49706-cve-2025-53770/",
]
@@ -72,19 +40,158 @@ event.category:file and host.os.type:windows and event.action:open and
not process.executable: (
"C:\Program Files\Microsoft Security Client\MsMpEng.exe" or
"C:\Program Files\Windows Defender Advanced Threat Protection\MsSense.exe" or
"C:\Windows\System32\MRT.exe"
"C:\Windows\System32\MRT.exe" or
"C:\Windows\System32\inetsrv\w3wp.exe"
)
'''
note = """## Triage and analysis
### Investigating Unusual Web Config File Access
#### Possible investigation steps
- What process opened which "web.config" path, and what secrets could it expose?
- Why: IIS, SharePoint, federation, or shared application configs can expose connection strings, MachineKey validation/decryption keys, and OAuth/SAML settings for ViewState forgery or credential pivots.
- Focus: `file.path`, `process.entity_id`, `process.executable`, `user.id`, and `host.id`.
- Implication: escalate when `file.path` points to SharePoint, federation, shared application, database-connected app, or another high-value IIS root; lower suspicion only when asset inventory or owner confirmation verifies a non-sensitive test path and later endpoint evidence stays inside that exact workflow.
- Is the reader a recognized maintenance component or an anomalous binary?
- Focus: `process.executable`, `process.command_line`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.parent.executable`.
- Implication: escalate when the reader is unsigned, user-writable, renamed, or launched by a shell, script host, web worker, or remote-admin chain; lower suspicion when signer, path, command line, and parent match one recognized deployment, backup, scan, or web-maintenance component. Identity alone does not clear the read.
- Do the account and lineage fit application maintenance on this host?
- Focus: `user.id`, `user.name`, `process.parent.executable`, and `process.Ext.ancestry`.
- Implication: escalate when the account lacks a web-admin, service, deployment, backup, or response role, the service identity is unexpected, or the parent is a shell, script host, web worker, or remote-admin tool; lower suspicion when identity, parent, and ancestry match one recognized workflow.
- Did the same process enumerate or stage config secrets beyond one bounded read?
- Focus: same-process file events by `host.id` and `process.entity_id`: `event.action`, `file.path`, and `file.Ext.original.path`; look for sibling "web.config", "applicationHost.config", backup or copied configs, script output, web-shell files, or archives. $investigate_0
- Implication: escalate when the process walks multiple site roots, opens server-wide config, reads backups, or writes collection/web-shell artifacts; lower suspicion when file activity stays inside one expected application path with no copy, archive, or helper-file staging.
- Did direct child process activity show extraction, staging, or attempted use of exposed secrets?
- Why: shell or encoded PowerShell chains can collect config contents, extract MachineKey material, or stage a web shell.
- Focus: direct child process events on `host.id` where `process.parent.entity_id` matches `process.entity_id`: `process.executable`, `process.command_line`, and `process.parent.executable`. $investigate_1
- Hint: expand manually from direct children into deeper descendants or the recovered process tree.
- Implication: escalate when children or descendants include "cmd.exe", PowerShell, archive tools, database clients, web-shell writers, or commands referencing MachineKey, validation keys, decryption keys, config copies, or archive staging; absent child events lower immediate-use concern only if the reader, path, and file pattern are already bounded.
- If local evidence is suspicious or unresolved, does endpoint telemetry show broader config access or staging by the same user or host?
- Focus: same-`user.id` file events with `file.path` values showing additional config reads, copied configs, script output, web-shell files, or archives. $investigate_2
- Hint: if the user identity is shared or sparse, review same-`host.id` and `user.id` process events: `process.executable`, `process.command_line`, and `process.Ext.ancestry`. $investigate_3
- Implication: expand scope when either view shows additional config reads, collection artifacts, staged scripts, or suspicious administration around the read window; keep the case local only when broader endpoint telemetry shows no additional staging and local evidence fits one exact workflow.
- Escalate when path, reader identity, lineage, same-process file behavior, child/descendant behavior, or related alerts indicate unauthorized config access or secret staging; close only when path, process, user/session, lineage, and same-process file evidence bind to one recognized maintenance, deployment, backup, or response workflow and outside confirmation verifies legitimacy telemetry cannot prove; preserve artifacts and escalate when evidence is mixed or incomplete.
### False positive analysis
- AV/EDR products may open web.config during scans. Confirm trusted-signed AV binary, SYSTEM or service account, and no same-process config copy, archive, or staging.
- Deployment, backup, scanning, or IR workflows can open web.config. Confirm `process.executable`, signer, parent, `file.path`, `user.id`, and `host.id` align with one workflow, with no config copy, archive, web-shell, shell descendants, or broader enumeration. Do not close on historical similarity alone.
- Build exceptions from `process.executable`, signer, parent, exact `file.path` root, `user.id`, and `host.id`. Avoid exceptions on "web.config" or host alone. For this new-terms rule, keep first-time cases as candidates until confirmed repeats show the same workflow.
### Response and remediation
- If confirmed benign, reverse temporary containment and document which evidence proved the workflow: reader identity, parent lineage, `file.path`, `user.id`, `host.id`, and same-process file pattern. Create an exception only for the independently confirmed minimum workflow, not for "web.config" broadly.
- If suspicious but unconfirmed, preserve the alert details, process tree, same-process file timeline, targeted config path, suspected copies, archives, script output, web-shell files, and case notes before containment. Apply reversible containment first, such as heightened monitoring, temporary account restrictions, or temporary outbound controls; isolate the host only if copied config, web-shell creation, or secret reuse is confirmed and service impact is acceptable.
- If confirmed malicious, preserve the reader process instance, parent chain, targeted `file.path`, copied or staged config, script output, web-shell files, archives, and case notes before containment. Then contain the affected host or account based on the unauthorized reader, high-value path, enumeration, staged artifacts, or descendant process evidence, and record those identifiers before terminating processes or deleting files.
- Rotate secrets exposed through the targeted `file.path`, including database credentials, MachineKey validation/decryption keys, OAuth/SAML secrets, and shared service-account credentials. Prioritize production, internet-facing, and shared application secrets.
- Eradicate only the webshells, scripts, copied configuration files, archives, persistence mechanisms, and altered application files identified during the investigation; restore affected application configuration from known-good state and remediate the initial access or privilege path that allowed the read.
"""
setup = """## Setup
This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
Setup instructions: https://ela.st/install-elastic-defend
"""
[rule.investigation_fields]
field_names = [
"@timestamp",
"event.action",
"host.name",
"host.id",
"user.name",
"user.id",
"user.domain",
"process.entity_id",
"process.executable",
"process.command_line",
"process.parent.executable",
"process.code_signature.subject_name",
"process.code_signature.trusted",
"file.path",
]
[transform]
[[transform.investigate]]
label = "File events for the same process"
description = ""
providers = [
[
{ excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" },
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "Direct child process events"
description = ""
providers = [
[
{ excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "File events for the same user"
description = ""
providers = [
[
{ excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" },
{ excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[transform.investigate]]
label = "Process events for the same host and user"
description = ""
providers = [
[
{ excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[rule.filters]]
[rule.filters.meta]
negate = true
[rule.filters.query.wildcard."process.executable"]
case_insensitive = true
value = "?:\\\\Program Files\\\\Common Files\\\\microsoft shared\\\\Web Server Extensions\\\\*\\\\BIN\\\\*"
[rule.new_terms]
field = "new_terms_fields"
value = ["process.executable", "user.id"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1003"
name = "OS Credential Dumping"
reference = "https://attack.mitre.org/techniques/T1003/"
[[rule.threat.technique]]
id = "T1552"
name = "Unsecured Credentials"
@@ -112,11 +219,3 @@ reference = "https://attack.mitre.org/techniques/T1005/"
id = "TA0009"
name = "Collection"
reference = "https://attack.mitre.org/tactics/TA0009/"
[rule.new_terms]
field = "new_terms_fields"
value = ["process.executable", "user.id"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"
rules/windows/credential_access_wireless_creds_dumping.toml
+139 -68
View File
@@ -2,33 +2,7 @@
creation_date = "2022/11/01"
integration = ["endpoint", "system", "windows", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/04/07"
[transform]
[[transform.osquery]]
label = "Osquery - Retrieve DNS Cache"
query = "SELECT * FROM dns_cache"
[[transform.osquery]]
label = "Osquery - Retrieve All Services"
query = "SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"
[[transform.osquery]]
label = "Osquery - Retrieve Services Running on User Accounts"
query = """
SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE
NOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR
user_account == null)
"""
[[transform.osquery]]
label = "Osquery - Retrieve Service Unsigned Executables with Virustotal Link"
query = """
SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,
services.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =
authenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'
"""
updated_date = "2026/04/27"
[rule]
author = ["Elastic"]
@@ -48,47 +22,6 @@ index = [
language = "eql"
license = "Elastic License v2"
name = "Wireless Credential Dumping using Netsh Command"
note = """## Triage and analysis
### Investigating Wireless Credential Dumping using Netsh Command
Netsh is a Windows command line tool used for network configuration and troubleshooting. It enables the management of network settings and adapters, wireless network profiles, and other network-related tasks.
This rule looks for patterns used to dump credentials from wireless network profiles using Netsh, which can enable attackers to bring their own devices to the network.
> **Note**:
> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.
#### Possible investigation steps
- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Inspect the host for suspicious or abnormal behavior in the alert timeframe:
- Observe and collect information about the following activities in the alert subject host:
- Attempts to contact external domains and addresses.
- Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.
- Examine the DNS cache for suspicious or anomalous entries.
- $osquery_0
- Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.
- Examine the host services for suspicious or anomalous entries.
- $osquery_1
- $osquery_2
- $osquery_3
### False positive analysis
- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.
### Response and remediation
- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved host to prevent further post-compromise behavior.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- Review the privileges assigned to the user to ensure that the least privilege principle is being followed.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
"""
references = [
"https://learn.microsoft.com/en-us/windows-server/networking/technologies/netsh/netsh-contexts",
"https://www.geeksforgeeks.org/how-to-find-the-wi-fi-password-using-cmd-in-windows/",
@@ -120,6 +53,139 @@ process where host.os.type == "windows" and event.type == "start" and
process.args : "wlan" and process.args : "key*clear"
'''
note = """## Triage and analysis
### Investigating Wireless Credential Dumping using Netsh Command
#### Possible investigation steps
- What did the alert-local netsh command expose or export?
- Focus: `process.command_line`, `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`.
- Implication: escalate when `key=clear` appears with bulk profile listing, `export profile`, omitted profile name, remote `-r`, script-file `-f`, or redirection; lower concern only when one local profile display fits recognized support or recovery. A signed Microsoft binary does not clear credential exposure.
- Does the launcher, session, and user context explain why this account retrieved a wireless key on this host?
- Focus: `process.parent.executable`, `process.parent.command_line`, `process.Ext.session_info.logon_type`, `user.id`, `host.id`.
- Implication: escalate when the parent is a shell, script host, remote-admin chain, document-spawned process, unexpected service identity, or unusual device-support user; lower concern when an interactive support shell or endpoint-management parent on the same host explains the exact command.
- Did the same launcher fan out from one display command into broader wireless-profile collection?
- Why: attackers often enumerate profile names with `wlan show profiles`, then display or export cleartext secrets; same-launcher enumeration without `key=clear` is precursor discovery.
- Focus: related process starts on `host.id` and `process.parent.entity_id`, using `process.executable` and `process.command_line`. $investigate_0
- Implication: escalate when the parent also runs profile enumeration, repeated `show profile`, `export profile`, or export without `name=`; keep review local when activity stays isolated to one profile display.
- Hint: If `process.parent.entity_id` is absent, pivot with `host.id`, `process.parent.pid`, and the alert window.
- Did the launcher or siblings stage recovered wireless material?
- Focus: same-parent process starts on `host.id`, using `process.executable` and `process.command_line`; file events from `host.id` plus `process.entity_id` or weaker `process.pid`, reviewing `file.path`, `file.extension`, and `file.size`. $investigate_1
- Implication: escalate when XML, redirected text, ZIP files, copied profiles, archive tools, copy utilities, cloud-sync clients, shell redirection, or script wrappers stage material for later use or transfer; missing file telemetry is unresolved, not benign. A clean file view lowers concern only when command and lineage also stay limited.
- If local evidence remains suspicious or unresolved, do related alerts change scope or urgency?
- Focus: related alerts for `user.id`, especially credential-access, lateral-movement, staging, remote-access, or persistence findings. $investigate_2
- Implication: broaden response when the same user or host also shows dumping, staging, remote access, or persistence; keep scope local when related alerts are absent and local evidence supports one bounded workflow.
- Hint: If the user view is sparse or the host is shared, review alerts for the same `host.id`. $investigate_3
- Escalate when command intent, lineage, same-launcher collection, staging, file artifacts, or related alerts show bulk credential access or broader compromise; close only when binary identity, command scope, parent workflow, user-host context, and recovery records bind to one recognized support or recovery action; preserve artifacts and escalate when evidence is mixed or incomplete.
### False positive analysis
- Helpdesk, field-support, device-recovery, imaging, hardware replacement, or Wi-Fi profile migration can retrieve one saved wireless key. Confirm signed netsh identity, one local profile display or expected export in `process.command_line`, support-tooling parentage, and no bulk enumeration, archive staging, or transfer; use asset or ticket records only to corroborate that exact action, otherwise require the same executable, parent, command pattern, `user.id`, `host.id`, and quiet surrounding activity across prior alerts from this rule.
- Before creating an exception, validate recurrence of the same `process.executable`, `process.parent.executable`, `process.command_line` pattern, `user.id`, and `host.id` with the same limited scope. Avoid exceptions on `process.name`, `key=clear` alone, the host alone, or all netsh wireless activity.
### Response and remediation
- If confirmed benign, reverse any temporary containment and document which evidence matched the support or recovery workflow: command scope, binary identity, parent workflow, `user.id`, `host.id`, and absence of collection or staging. Create an exception only after the same limited pattern recurs.
- If suspicious but unconfirmed, preserve the alert record, case export, volatile process context, `process.entity_id`, `process.command_line`, `process.parent.command_line`, sibling process starts, staged artifacts when recovered, and affected `user.id` and `host.id`. Start with reversible containment such as temporary wireless or network restrictions; use host isolation only if staging, export, transfer, or broader compromise is evident.
- If confirmed malicious, isolate the endpoint or terminate the offending process through endpoint-response tooling after recording `process.entity_id`, `process.command_line`, parent context, exposed profile names, staged artifacts, and related-alert evidence. If tooling is unavailable, escalate with the preserved evidence set.
- Reset or rotate credentials exposed by the dumped wireless profile. For PSK environments, rotate the affected SSID key; for 802.1X environments, revoke or reissue affected certificates, reset cached credentials, and verify whether the exposed profile could grant broader network access.
- Before deleting artifacts, review other hosts and users for the same `process.command_line`, parent pattern, or exported profile artifacts so scoping finishes before evidence is destroyed.
- Eradicate only scripts, batch files, XML exports, archives, and persistence mechanisms found during the investigation, then remediate the initial access path that allowed the key retrieval.
"""
setup = """## Setup
This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
Setup instructions: https://ela.st/install-elastic-defend
### Additional data sources
This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
- [CrowdStrike](https://ela.st/crowdstrike-integration)
- [Microsoft Defender XDR](https://ela.st/m365-defender)
- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
- [Windows Process Creation Logs](https://ela.st/audit-process-creation)
"""
[rule.investigation_fields]
field_names = [
"@timestamp",
"host.id",
"user.id",
"process.entity_id",
"process.pid",
"process.executable",
"process.command_line",
"process.args",
"process.pe.original_file_name",
"process.parent.entity_id",
"process.parent.pid",
"process.parent.executable",
"process.parent.command_line",
"process.code_signature.subject_name",
"process.code_signature.trusted",
]
[transform]
[[transform.investigate]]
label = "Process starts from the same parent"
description = ""
providers = [
[
{ excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.parent.entity_id}}", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "File activity for the alerting process"
description = ""
providers = [
[
{ excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" },
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "Alerts associated with the user"
description = ""
providers = [
[
{ excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
{ excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[transform.investigate]]
label = "Alerts associated with the host"
description = ""
providers = [
[
{ excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[rule.threat]]
framework = "MITRE ATT&CK"
@@ -157,6 +223,11 @@ id = "T1016"
name = "System Network Configuration Discovery"
reference = "https://attack.mitre.org/techniques/T1016/"
[[rule.threat.technique]]
id = "T1082"
name = "System Information Discovery"
reference = "https://attack.mitre.org/techniques/T1082/"
[rule.threat.tactic]
id = "TA0007"
name = "Discovery"
rules/windows/defense_evasion_amsi_bypass_dllhijack.toml
+154 -79
View File
@@ -2,33 +2,7 @@
creation_date = "2023/01/17"
integration = ["windows", "endpoint", "sentinel_one_cloud_funnel", "m365_defender", "crowdstrike"]
maturity = "production"
updated_date = "2026/04/07"
[transform]
[[transform.osquery]]
label = "Osquery - Retrieve DNS Cache"
query = "SELECT * FROM dns_cache"
[[transform.osquery]]
label = "Osquery - Retrieve All Services"
query = "SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"
[[transform.osquery]]
label = "Osquery - Retrieve Services Running on User Accounts"
query = """
SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE
NOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR
user_account == null)
"""
[[transform.osquery]]
label = "Osquery - Retrieve Service Unsigned Executables with Virustotal Link"
query = """
SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,
services.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =
authenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'
"""
updated_date = "2026/04/27"
[rule]
author = ["Elastic"]
@@ -49,54 +23,6 @@ index = [
language = "eql"
license = "Elastic License v2"
name = "Suspicious Antimalware Scan Interface DLL"
note = """## Triage and analysis
### Investigating Suspicious Antimalware Scan Interface DLL
The Windows Antimalware Scan Interface (AMSI) is a versatile interface standard that allows your applications and services to integrate with any antimalware product on a machine. AMSI integrates with multiple Windows components, ranging from User Account Control (UAC) to VBA macros and PowerShell.
Attackers might copy a rogue AMSI DLL to an unusual location to prevent the process from loading the legitimate module, achieving a bypass to execute malicious code.
> **Note**:
> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.
#### Possible investigation steps
- Identify the process that created the DLL and which account was used.
- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Investigate the execution of scripts and macros after the registry modification.
- Investigate other processes launched from the directory that the DLL was created.
- Inspect the host for suspicious or abnormal behavior in the alert timeframe:
- Observe and collect information about the following activities in the alert subject host:
- Attempts to contact external domains and addresses.
- Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.
- Examine the DNS cache for suspicious or anomalous entries.
- $osquery_0
- Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.
- Examine the host services for suspicious or anomalous entries.
- $osquery_1
- $osquery_2
- $osquery_3
### False positive analysis
- This modification should not happen legitimately. Any potential benign true positive (B-TP) should be mapped and monitored by the security team as these modifications expose the host to malware infections.
### Response and remediation
- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved hosts to prevent further post-compromise behavior.
- If the triage identified malware, search the environment for additional compromised hosts.
- Implement temporary network rules, procedures, and segmentation to contain the malware.
- Stop suspicious processes.
- Immediately block the identified indicators of compromise (IoCs).
- Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
- Remove and block malicious artifacts identified during triage.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
"""
references = ["https://github.com/S3cur3Th1sSh1t/Amsi-Bypass-Powershell"]
risk_score = 73
rule_id = "fa488440-04cc-41d7-9279-539387bf2a17"
@@ -127,6 +53,7 @@ file where host.os.type == "windows" and event.type != "deletion" and file.path
"?:\\Windows\\Syswow64\\amsi.dll",
"?:\\$WINDOWS.~BT\\*\\amsi.dll",
"?:\\Windows\\CbsTemp\\*\\amsi.dll",
"?:\\Windows\\SystemTemp\\*\\amsi.dll",
"?:\\Windows\\SoftwareDistribution\\Download\\*",
"?:\\Windows\\WinSxS\\*\\amsi.dll",
"?:\\Windows\\servicing\\*\\amsi.dll",
@@ -142,10 +69,162 @@ file where host.os.type == "windows" and event.type != "deletion" and file.path
"\\Device\\HarddiskVolume*\\$WINDOWS.~BT\\*\\amsi.dll",
"\\Device\\HarddiskVolume*\\Windows\\SoftwareDistribution\\Download\\*\\amsi.dll",
"\\Device\\HarddiskVolume*\\Windows\\CbsTemp\\*\\amsi.dll",
"\\Device\\HarddiskVolume*\\Windows\\SystemTemp\\*\\amsi.dll",
"\\Device\\HarddiskVolume*\\Windows\\servicing\\*\\amsi.dll"
)
'''
note = """## Triage and analysis
### Investigating Suspicious Antimalware Scan Interface DLL
#### Possible investigation steps
- Does the alert show a rogue AMSI DLL in a path a consumer process could reach?
- Why: AMSI DLL hijack works when amsi.dll is placed where a copied or launched AMSI-aware process searches first; copied PowerShell beside the DLL is a distinctive public-tooling pattern.
- Focus: `file.path`, `event.action`, and `file.size`, checking writable application, archive extraction, temp, user profile, or working directories outside Windows system and servicing paths.
- Implication: escalate when the DLL lands beside or inside a reachable search-order path for PowerShell, pwsh, wscript, cscript, mshta, Office, or another AMSI-aware consumer; lower concern only when the path is a lab or package-test directory unreachable by a copied consumer and content evidence fits that test.
- Did the writer and parent context fit that DLL placement?
- Focus: `process.executable`, `process.command_line`, `process.hash.sha256`, `process.parent.command_line`, `user.id`, and `host.id`.
- Implication: escalate when the writer is user-writable, script- or shell-launched, newly seen by hash, or started through ad hoc remote administration; lower concern only when writer identity, parent command line, account, and host match one recognized validation workflow. Writer identity alone never clears the placement.
- Did the same writer stage the full DLL-hijack pattern?
- Focus: file events on the same `host.id` and `process.entity_id`, especially `file.path`, `event.action`, and `file.size`. $investigate_0
- Implication: escalate when the writer also drops copied powershell.exe, pwsh.exe, a script host, loader script, or renamed DLL beside the new amsi.dll; lower concern only when all artifacts stay inside one controlled validation directory and no consumer starts from it.
- Did a process load or reuse the created DLL path?
- Focus: with library-load telemetry, pivot from `host.id` plus `file.path` to events where `dll.path` equals the created path, then read loader `process.executable`, `process.command_line`, and `@timestamp`; missing library-load telemetry leaves execution unresolved, not benign. $investigate_1
- Hint: with only file telemetry, treat later writes or touches of the same `file.path` as reuse clues, not module-load proof.
- Implication: escalate when PowerShell, pwsh, wscript, cscript, mshta, Office, or another AMSI-aware process loads or reuses the path after creation; unresolved load evidence keeps the case at staging unless other local evidence corroborates abuse.
- Did process execution show use of the hijack directory or another AMSI-bypass path?
- Focus: process starts on the same `host.id` and `user.id`, especially `process.executable`, `process.command_line`, and `process.parent.command_line`. $investigate_2
- Implication: escalate when copied PowerShell or a script host starts from the DLL directory, a consumer process uses that directory as its working directory, or command lines show PowerShell v2 launch; lower concern only when execution stays limited to the same controlled validation workflow.
- If local evidence is suspicious or unresolved, is the scope still limited to this host?
- Focus: related alerts for `host.id`; use `user.id` only when the writer maps to one stable identity, then compare `file.path`, `process.hash.sha256`, and `process.command_line` patterns. $investigate_4
- Hint: use the user-scoped alert view only after the writer identity is stable enough to test account-level spread. $investigate_3
- Implication: broaden response when the same host or user shows additional AMSI, suspicious library-load, script-control, persistence, or payload-staging alerts; keep scope local when this is a single bounded placement with no corroborating chain.
- Escalate when suspicious placement has any meaningful corroborator: copied consumer staging, load or reuse, suspicious lineage, execution from the DLL directory, or related evasion alerts. Close only when placement, writer, staging/load result, execution context, and outside validation all bind to authorized testing; preserve artifacts and escalate when evidence is mixed, missing, or contradictory.
### False positive analysis
- Authorized malware-research, red-team, defensive-validation, or package testing that intentionally exercises AMSI search-order behavior is the credible benign path. Confirm `file.path` stays in a lab-only or test-package location; `process.executable`, `process.command_line`, `process.hash.sha256`, `user.id`, and `host.id` map to that workflow; no copied script host launches outside the test; and available load evidence comes from the expected harness. If schedules or inventories are unavailable, require current telemetry to prove the same lab or test harness; use recurrence only for exception design, not closure. If path, writer, load target, or execution context diverges, do not close as benign.
- Before creating an exception, validate the same `process.executable`, `process.hash.sha256`, parent workflow, `file.path`, `user.id`, and `host.id` recur across prior alerts from this rule. Build the exception from that workflow pattern. Avoid exceptions on amsi.dll alone, a directory fragment alone, or the host alone.
### Response and remediation
- If confirmed benign, reverse temporary containment and record which evidence proved the workflow: `file.path`, writer identity, `process.parent.command_line`, account and host scope, staging pattern, and any available load or harness evidence. Create an exception only after that workflow recurs across prior alerts from this rule.
- If suspicious but unconfirmed, preserve the created `file.path`, writer `process.entity_id`, `process.command_line`, parent lineage, sibling staged files, load or reuse evidence when available, and related-alert context before containment. Apply reversible containment tied to the findings, and avoid deleting the DLL until load or reuse is understood.
- If confirmed malicious, isolate the endpoint or contain the responsible account according to the confirmed writer, copied consumer, and execution evidence. Before termination or cleanup, record the writer process details, DLL path, copied consumer executable, load evidence when available, and sibling scripts or payloads; weigh host criticality before isolation.
- Remove the rogue DLL, copied PowerShell or script-host binaries, loader scripts, and sibling payloads found during the investigation, then restore the affected application or working directory from known-good content and verify the legitimate system AMSI locations remain intact.
- If a target process loaded the rogue DLL, capture module and process evidence before restart or termination, then reverse any companion AMSI weakening found through process command lines or staged scripts.
- After containment, scope the same writer identity, DLL path pattern, copied consumer pattern, parent workflow, and companion AMSI-bypass behavior across other hosts, and retain the supporting file, process, and library-load evidence when available.
"""
setup = """## Setup
This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
Setup instructions: https://ela.st/install-elastic-defend
### Additional data sources
This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
- [CrowdStrike](https://ela.st/crowdstrike-integration)
- [Microsoft Defender XDR](https://ela.st/m365-defender)
- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Event ID 11 - File Create](https://ela.st/sysmon-event-11-setup)
"""
[rule.investigation_fields]
field_names = [
"@timestamp",
"event.action",
"host.name",
"host.id",
"user.name",
"user.id",
"user.domain",
"process.entity_id",
"process.pid",
"process.executable",
"process.command_line",
"file.path",
"file.name",
"file.extension",
"file.size",
]
[transform]
[[transform.investigate]]
label = "File events for the writer process"
description = ""
providers = [
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
{ excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" }
]
]
relativeFrom = "now-24h/h"
relativeTo = "now"
[[transform.investigate]]
label = "Events for the created DLL path"
description = ""
providers = [
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "file.path", queryType = "phrase", value = "{{file.path}}", valueType = "string" }
],
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "dll.path", queryType = "phrase", value = "{{file.path}}", valueType = "string" }
]
]
relativeFrom = "now-24h/h"
relativeTo = "now"
[[transform.investigate]]
label = "Process events for the same host and user"
description = ""
providers = [
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" },
{ excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "Alerts associated with the user"
description = ""
providers = [
[
{ excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
{ excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[transform.investigate]]
label = "Alerts associated with the host"
description = ""
providers = [
[
{ excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[rule.threat]]
framework = "MITRE ATT&CK"
@@ -158,7 +237,6 @@ id = "T1562.001"
name = "Disable or Modify Tools"
reference = "https://attack.mitre.org/techniques/T1562/001/"
[[rule.threat.technique]]
id = "T1574"
name = "Hijack Execution Flow"
@@ -168,10 +246,7 @@ id = "T1574.001"
name = "DLL"
reference = "https://attack.mitre.org/techniques/T1574/001/"
[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
rules/windows/defense_evasion_amsi_bypass_powershell.toml
+139 -92
View File
@@ -2,92 +2,22 @@
creation_date = "2023/01/17"
integration = ["windows"]
maturity = "production"
updated_date = "2026/03/24"
updated_date = "2026/04/27"
[rule]
author = ["Elastic"]
description = """
Detects PowerShell scripts that references Antimalware Scan Interface (AMSI) bypass classes, methods, or known bypass
Detects PowerShell scripts that reference Antimalware Scan Interface (AMSI) bypass classes, methods, or known bypass
strings. Attackers attempt AMSI bypass to disable scanning and run malicious PowerShell content undetected.
"""
from = "now-9m"
index = ["winlogbeat-*", "logs-windows.powershell*"]
index = ["logs-windows.powershell*", "winlogbeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "Potential Antimalware Scan Interface Bypass via PowerShell"
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Potential Antimalware Scan Interface Bypass via PowerShell
This rule detects PowerShell script block content that references Antimalware Scan Interface (AMSI) bypass techniques. This behavior is commonly used to impair PowerShell content scanning and is frequently a precursor to additional PowerShell activity that would otherwise be inspected.
#### Key alert fields to review
- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping.
- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping.
- `powershell.file.script_block_text`: Script block content that matched the detection logic.
- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events.
- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file.
- `powershell.file.script_block_length`: Script block length (size) context.
#### Possible investigation steps
- Validate the intent of the script block:
- Review `powershell.file.script_block_text` and identify which AMSI-related indicators are present (for example, `System.Management.Automation.AmsiUtils`, `amsiInitFailed`, `amsiContext`, `amsiSession`, `AmsiInitialize`, `amsi.dll`).
- Identify bypass techniques suggested by the script content, such as reflection-based field modification (for example, `Assembly.GetType(` and `.SetValue(`) or in-memory modification patterns (for example, `AllocHGlobal`).
- Note explicit bypass helper names in the script text (for example, `Invoke-AmsiBypass`, `Bypass.AMSI`, `FindAmsiFun`, `unloadobfuscated`, `unloadsilent`) and any obfuscation (mixed casing, character-code string construction, normalization, or heavy use of `-replace`).
- Treat this alert as an AMSI bypass attempt; success is not typically confirmed from the matching script block alone, so prioritize follow-on activity review.
- Reconstruct the complete script when content is split across multiple events:
- Pivot on `powershell.file.script_block_id` and collect all related fragments.
- Order fragments by `powershell.sequence` and confirm the expected count with `powershell.total`.
- Re-review the reconstructed text for additional behaviors beyond the bypass attempt (for example, retrieving additional content, decoding staged data, or invoking suspicious functions).
- Determine the likely source of the script content:
- Review `file.path` and `file.name` when present to identify an on-disk script source.
- Assess whether the path and filename align with established administrative tooling for the user/host, or whether it appears in an unexpected or transient location (for example, user profile, Temp, Downloads, or other user-writable locations).
- If `file.path` is not present, treat the source as unknown and prioritize correlation with other telemetry based on `host.name` and `@timestamp`.
- Establish the execution scope and operator context:
- Review `user.name`, `user.domain`, and `user.id` to understand which account generated the script block content and whether it is expected to run PowerShell on `host.name`.
- Review `host.name` and `host.id` to determine whether the activity is isolated to a single endpoint or recurring across multiple systems.
- Identify repeated alerts involving the same `user.id` and/or `host.id` in a short period, which may indicate iterative testing of bypass variants or repeated execution of the same script.
- Hunt for related PowerShell activity on the same endpoint and account:
- Search for additional script blocks on the same `host.id` around `@timestamp` to identify activity immediately before and after the bypass attempt.
- Use distinctive strings from `powershell.file.script_block_text` (function names, variable names, or unique encodings) to identify reuse by the same `user.id` or across other hosts.
- Extract any observable indicators embedded in the script text (for example, domains, IPs, URLs, or file paths) and use them to expand scoping searches.
- Correlate with adjacent telemetry using `host.name`, `user.name`, and the alert time window (if available in your environment):
- Process execution telemetry to identify how PowerShell was launched and the initiating parent process (interactive use vs. another application or automation).
- Network telemetry for outbound connections and DNS activity that align with any remote retrieval or command-and-control behavior implied by the script content.
- File and registry telemetry for artifacts consistent with payload staging or persistence created shortly after the bypass attempt.
- Authentication telemetry to identify unusual or new logon activity for the implicated user on the affected host near the alert time.
### False positive analysis
- Training material or code snippets may be executed verbatim in a console during learning exercises. Confirm the context in `powershell.file.script_block_text` and whether additional suspicious behaviors appear in nearby script blocks from the same user and host.
### Response and remediation
- If the activity is confirmed or strongly suspected to be malicious:
- Contain the affected host to prevent further execution and lateral movement.
- Preserve evidence from the alert: `powershell.file.script_block_text`, `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, `host.name`, `host.id`, `user.name`, `user.domain`, `user.id`, and any associated `file.path`/`file.name`.
- If `file.path` is present, collect the referenced script from disk (if still available) and identify where else it exists in the environment.
- Scope for additional impacted systems by searching for the same bypass strings and distinctive patterns across other hosts and users.
- Investigate and remediate follow-on actions identified in the reconstructed script and adjacent script blocks (for example, retrieval of additional code, credential access attempts, or persistence).
- Reset credentials for involved accounts when warranted and review for further suspicious activity tied to `user.id` across the environment.
- Reduce the likelihood of recurrence:
- Ensure PowerShell logging is appropriately enabled and centrally collected to support reconstruction and scoping.
- Apply least privilege and limit PowerShell usage to approved roles and systems where feasible.
- Review monitoring coverage for repeated AMSI bypass attempts and related PowerShell activity on the same host or by the same user.
"""
references = ["https://github.com/S3cur3Th1sSh1t/Amsi-Bypass-Powershell"]
risk_score = 73
rule_id = "1f0a69c0-3392-4adf-b7d5-6012fd292da8"
setup = """## Setup
PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).
Setup instructions: https://ela.st/powershell-logging-setup
"""
severity = "high"
tags = [
"Domain: Endpoint",
@@ -129,6 +59,142 @@ event.category:"process" and host.os.type:windows and
)
'''
note = """## Triage and analysis
### Investigating Potential Antimalware Scan Interface Bypass via PowerShell
#### Possible investigation steps
- Does the preserved script block show active AMSI bypass behavior or reference-only content?
- Focus: `powershell.file.script_block_text`, source in `file.path` or `file.name`, and whether bypass helpers execute or are only mentioned.
- Hint: treat AmsiUtils, amsiInitFailed, AmsiScanBuffer/AmsiOpenSession patching, ScriptBlockAst smuggling, VirtualProtect/Marshal.Copy, and logging suppression as active-behavior anchors.
- Implication: escalate when content flips AMSI state, patches scan routines, smuggles script blocks, or invokes decoded content; lower suspicion only for inert research text or bounded training with no execution path.
- Does reconstruction add payload execution, download logic, or extra evasion?
- Why: Script Block Logging can split helper functions, decoded strings, and later stages across multiple fragments.
- Focus: reconstruct fragments scoped by `host.id` and `powershell.file.script_block_id`; order with `powershell.sequence`, confirm `powershell.total`, then read `powershell.file.script_block_text`. $investigate_2
- Hint: review surrounding 4104 blocks for the same `host.id` and `process.pid` with different `powershell.file.script_block_id`; keep timestamp comparison tight to avoid PID reuse. $investigate_3
- Hint: if fragments are missing, score visible bypass logic and record the missing sequence range as unresolved, not benign.
- Implication: escalate when reconstruction adds download, decode, in-memory execution, credential access, persistence, Disable Script Logging, or unloadobfuscated/unloadsilent evasion; lower suspicion only when complete fragments remain bounded to authorized lab or training content.
- Can endpoint process telemetry recover how PowerShell was launched?
- Focus: if available, recover the process via `host.id` and `process.pid` before interpreting `process.*` or `process.parent.*`; read `process.command_line`, `process.parent.command_line`, and `process.Ext.session_info.logon_type`, expanding the window if PowerShell started earlier. $investigate_4
- Implication: escalate for encoded commands, PowerShell v2 downgrade, Office/browser parents, remote-administration launchers, or service/network logon that does not fit the user; missing endpoint telemetry leaves launch context unresolved, not benign.
- Do the user, host, and source context fit an authorized test workflow?
- Focus: `user.id`, `host.id`, `host.name`, preserved `file.path` or `file.name`, and recovered launch context.
- Hint: if no source path is preserved, treat the block as interactive, pasted, in-memory, or remotely delivered and require stronger corroboration before benign closure.
- Implication: escalate when standard-user, shared-workstation, production-server, user-writable-source, or fileless-delivery context cannot be tied to one authorized lab, red-team, detection-engineering, or training case; lower suspicion only when all context supports that exact workflow.
- If local evidence remains suspicious or unresolved, does the pattern recur for the same user or host?
- Focus: last-48h related alerts for the same `user.id`, looking for repeated AMSI bypass, delivery, credential access, persistence, or defense evasion. $investigate_0
- Hint: check the same `host.id` before expanding beyond the affected host or user. $investigate_1
- Implication: broaden scope when related alerts show repeated evasion or follow-on abuse; quiet pivots lower scope only and never close active bypass without local evidence proving one exact authorized workflow.
- Escalate on active bypass logic, suspicious provenance, launch abuse, operational follow-on evidence, or partial/mixed visibility; close only when script content, reconstruction, launch, source, and related-alert evidence bind activity to one exact authorized lab, training, or red-team workflow; preserve artifacts and escalate when outside confirmation is needed.
### False positive analysis
- Authorized detection-engineering, red-team, malware-analysis, training, or reference-only course/research use can trigger this rule. Confirm that `powershell.file.script_block_text`, reconstruction, `user.id`, `host.id`, source/session context, and recovered launch context all stay inside the same test case and add no second stage. If records are unavailable, recurrence supports assessment only when the same telemetry pattern proves the exact exercise; do not close on recurrence alone.
- Before creating an exception, validate that the same `user.id`, `host.id`, stable source path, launch context, and reconstructed fragment pattern recur across prior alerts from this rule. Build the exception from that confirmed workflow pattern. Avoid exceptions on AMSI strings alone, on `user.name` alone, or on a host alone.
### Response and remediation
- If confirmed benign, reverse temporary containment and document which evidence proved the authorized workflow: script content, reconstruction, `user.id`, `host.id`, preserved source path, and recovered launch context. Create an exception only if the same workflow pattern recurs and the telemetry still proves the exact exercise.
- If suspicious but unconfirmed, preserve the script block content, fragment IDs and sequence numbers, `process.pid`, recovered launch details, script-named URLs or paths, source files, and related-alert exports before containment. Apply reversible containment first, such as tighter monitoring on the affected `host.id` or `user.id`, temporary restrictions for script-named URLs, or suspend-process actions when the host role can tolerate them. Escalate to isolation only if reconstructed content or recovered launch evidence confirms operational follow-on activity.
- If confirmed malicious, contain the host or account based on the script content, recovered launch chain, source path, script-named indicators, or related-alert evidence that established unauthorized operational use. Record the recovered PowerShell process details, parent chain, script content, downstream commands, and affected `user.id` / `host.id` before terminating processes, deleting files, or purging sessions.
- Block confirmed malicious script-named URLs or hashes, collect referenced source files, and eradicate only the unauthorized scripts, payloads, startup artifacts, scheduled tasks, and security-control changes expressed in reconstruction or recovered launch context.
- Before destructive cleanup, review related hosts and users for the same script fragments, launch chain, downgrade pattern, script-named indicators, or already-running PowerShell reuse so scope is understood before evidence is removed.
- After the incident, retain Script Block Logging plus required endpoint process telemetry, and document PowerShell version 2 downgrade, logging-suppression, or script-block smuggling variants in the case record.
"""
setup = """## Setup
PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).
Setup instructions: https://ela.st/powershell-logging-setup
"""
[rule.investigation_fields]
field_names = [
"@timestamp",
"user.name",
"user.id",
"user.domain",
"powershell.file.script_block_text",
"powershell.file.script_block_id",
"powershell.sequence",
"powershell.total",
"file.path",
"file.directory",
"file.name",
"process.pid",
"host.name",
"host.id",
"powershell.file.script_block_length"
]
[transform]
[[transform.investigate]]
label = "Alerts associated with the user"
description = ""
providers = [
[
{ excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
{ excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[transform.investigate]]
label = "Alerts associated with the host"
description = ""
providers = [
[
{ excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[transform.investigate]]
label = "Script block fragments for the same script"
description = ""
providers = [
[
{ excluded = false, field = "powershell.file.script_block_id", queryType = "phrase", value = "{{powershell.file.script_block_id}}", valueType = "string" },
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "PowerShell script blocks for the same process"
description = ""
providers = [
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" },
{ excluded = false, field = "event.code", queryType = "phrase", value = "4104", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "Process events for the PowerShell instance"
description = ""
providers = [
[
{ excluded = false, field = "process.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" },
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[rule.threat]]
framework = "MITRE ATT&CK"
@@ -175,22 +241,3 @@ reference = "https://attack.mitre.org/techniques/T1059/001/"
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[rule.investigation_fields]
field_names = [
"@timestamp",
"user.name",
"user.id",
"user.domain",
"powershell.file.script_block_text",
"powershell.file.script_block_id",
"powershell.sequence",
"powershell.total",
"file.path",
"file.directory",
"file.name",
"process.pid",
"host.name",
"host.id",
"powershell.file.script_block_length"
]
rules/windows/defense_evasion_amsienable_key_mod.toml
+151 -57
View File
@@ -2,13 +2,13 @@
creation_date = "2021/06/01"
integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/04/07"
updated_date = "2026/04/27"
[rule]
author = ["Elastic"]
description = """
Identifies modifications of the AmsiEnable registry key to 0, which disables the Antimalware Scan Interface (AMSI). An
adversary can modify this key to disable AMSI protections.
Identifies modifications of the AmsiEnable registry key to 0, which disables Windows Script AMSI scanning for the
affected user. Adversaries can modify this key to bypass AMSI protections for Windows Script Host or JScript execution.
"""
from = "now-9m"
index = [
@@ -23,56 +23,6 @@ index = [
language = "eql"
license = "Elastic License v2"
name = "Modification of AmsiEnable Registry Key"
note = """## Triage and analysis
### Investigating Modification of AmsiEnable Registry Key
The Windows Antimalware Scan Interface (AMSI) is a versatile interface standard that allows your applications and services to integrate with any antimalware product on a machine. AMSI integrates with multiple Windows components, ranging from User Account Control (UAC) to VBA macros and PowerShell.
Since AMSI is widely used across security products for increased visibility, attackers can disable it to evade detections that rely on it.
This rule monitors the modifications to the Software\\Microsoft\\Windows Script\\Settings\\AmsiEnable registry key.
#### Possible investigation steps
- Identify the user account that performed the action and whether it should perform this kind of action.
- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Investigate the execution of scripts and macros after the registry modification.
- Retrieve scripts or Microsoft Office files and determine if they are malicious:
- Use a private sandboxed malware analysis system to perform analysis.
- Observe and collect information about the following activities:
- Attempts to contact external domains and addresses.
- File and registry access, modification, and creation activities.
- Service creation and launch activities.
- Scheduled task creation.
- Use the PowerShell Get-FileHash cmdlet to get the files' SHA-256 hash values.
- Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.
- Use process name, command line, and file hash to search for occurrences on other hosts.
### False positive analysis
- This modification should not happen legitimately. Any potential benign true positive (B-TP) should be mapped and monitored by the security team as these modifications expose the host to malware infections.
### Related rules
- Microsoft Windows Defender Tampering - fe794edd-487f-4a90-b285-3ee54f2af2d3
### Response and remediation
- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved hosts to prevent further post-compromise behavior.
- If the triage identified malware, search the environment for additional compromised hosts.
- Implement temporary network rules, procedures, and segmentation to contain the malware.
- Stop suspicious processes.
- Immediately block the identified indicators of compromise (IoCs).
- Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
- Remove and block malicious artifacts identified during triage.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- Delete or set the key to its default value.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
"""
references = [
"https://hackinparis.com/data/slides/2019/talks/HIP2019-Dominic_Chell-Cracking_The_Perimeter_With_Sharpshooter.pdf",
"https://docs.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-portal",
@@ -97,7 +47,7 @@ timestamp_override = "event.ingested"
type = "eql"
query = '''
registry where host.os.type == "windows" and event.type == "change" and
registry where host.os.type == "windows" and event.type in ("creation", "change") and
registry.value : "AmsiEnable" and registry.data.strings: ("0", "0x00000000")
/*
@@ -106,6 +56,153 @@ registry where host.os.type == "windows" and event.type == "change" and
*/
'''
note = """## Triage and analysis
### Investigating Modification of AmsiEnable Registry Key
#### Possible investigation steps
- Does the registry event prove Windows Script AMSI was disabled for a user hive?
- Focus: `registry.path`, `registry.value`, `registry.data.type`, and `registry.data.strings` for "Software\\Microsoft\\Windows Script\\Settings\\AmsiEnable" under "HKEY_USERS\\<SID>".
- Implication: escalate true disablement when `registry.path` resolves to that user-hive value and `registry.data.strings` is "0" or "0x00000000"; lower suspicion only when the path or data does not disable AMSI, or same-host evidence proves controlled validation or image-build deliberately toggled Windows Script AMSI.
- Is the writing process a recognized validation tool or an abuse launcher?
- Focus: writer identity: `process.entity_id`, `process.executable`, `process.command_line`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. $investigate_0
- Hint: reconstruct activity with `host.id` plus `process.entity_id`; if missing, use `host.id`, `process.pid`, and a tight time window.
- Implication: escalate when the writer is unsigned, untrusted, user-writable, renamed, script-launched, or writes "AmsiEnable" outside a recognized validation or image-build command line. Identity alone never clears the registry change.
- Does lineage and session explain the AMSI disablement?
- Focus: `process.parent.executable`, `process.parent.command_line`, `process.Ext.session_info.logon_type`, and `user.id`.
- Implication: escalate when lineage involves Office, a browser, script host, remote shell, scheduled task, unexpected service account, or a standard user context that does not fit script-control testing; lower suspicion only when parent, session, and `user.id` match controlled validation or image-build launch context.
- Did follow-on process activity use the disablement path?
- Focus: post-write process activity in the recovered process scope, especially `process.executable`, `process.command_line`, and `process.parent.command_line`. $investigate_1
- Implication: escalate when the same lineage later launches or reopens "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "mshta.exe", "wmic.exe", "regsvr32.exe", or Office-child script execution. A write followed by a second script open matches SharpShooter-style AMSI-stub behavior; activity confined to recognized validation is lower risk.
- Did the same process change related registry state for evasion, persistence, or cleanup?
- Focus: same-process registry activity in the recovered process scope, with `registry.path`, `registry.value`, and `registry.data.strings`. $investigate_2
- Implication: escalate when the process also weakens script policy, security-control, Run, Startup, COM, or other persistence-relevant keys, or quickly restores `registry.path` after script execution. Risk is narrower when surrounding registry writes stay limited to the Windows Script validation task and return to baseline.
- If local evidence stays suspicious or unresolved, do related alerts broaden scope?
- Focus: related alerts for the same `user.id` that show execution, persistence, delivery, or defense evasion. $investigate_3
- Hint: query related alerts for the same `host.id` to find adjacent script execution, persistence, related registry tampering, or other AMSI-bypass alerts. $investigate_4
- Implication: broaden scope and urgency when either pivot shows related execution, persistence, or defense evasion; quiet related-alert pivots only lower urgency when local registry, process, and user evidence already supports one exact benign workflow.
- Escalate when true AMSI disablement combines with suspicious writer, lineage, script follow-on, related registry weakening, or related alerts; close only when same-host registry and process evidence proves one controlled workflow, with outside confirmation when telemetry cannot prove legitimacy; preserve and escalate mixed or incomplete evidence.
### False positive analysis
- Controlled security validation or golden-image build validation can legitimately toggle AMSI on lab, build, or pre-production assets. Confirm `registry.path`, `registry.value`, and `registry.data.strings` match the intended user hive; `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.command_line`, `process.parent.command_line`, `user.id`, and `host.id` align with that workflow; and surrounding process plus registry activity stays inside the task. Use change records, testing plans, owner confirmation, or toolchain confirmation only to verify telemetry-proven workflow, not override unresolved telemetry.
- Base exceptions on the minimum confirmed workflow pattern: `process.executable`, `process.code_signature.subject_name`, `process.command_line`, `process.parent.executable`, `registry.path`, `user.id`, and `host.id`. Use prior alerts, when available, to validate stability. Avoid exceptions on the AmsiEnable value alone, on `user.name` alone, or on a host alone.
### Response and remediation
- If confirmed benign, reverse any temporary containment and document the exact registry, process, parent, user, and host evidence that justified closure. Create an exception only when that confirmed pattern is specific enough to avoid suppressing lookalike AMSI tampering; use recurrence as supporting evidence when it exists.
- If suspicious but unconfirmed, preserve the registry event, same-host process timeline, parent command line, related registry changes, and affected user and host before containment. Apply reversible containment first, such as heightened monitoring, temporary network restriction, or carefully scoped endpoint isolation based on host role; escalate to account action or stronger host isolation only if follow-on execution, related registry tampering, or broader alert scope is confirmed.
- If confirmed malicious, preserve the registry, process, user, host, and related-alert evidence plus any recovered script or payload identifiers before destructive action. Use endpoint isolation to stop follow-on execution while retaining telemetry, then terminate malicious processes or suspend accounts only after recording the process and user evidence needed for follow-up.
- After scoping related `host.id`, `user.id`, `process.executable`, and `registry.path` evidence across affected assets, restore `registry.value` to the expected baseline and remove only the scripts, binaries, Run keys, COM changes, scheduled tasks, or other persistence artifacts identified during the investigation.
- Post-incident hardening: restrict who can modify the Windows Script settings path, review controls around script hosts and Office macro execution, and retain the registry and process telemetry that proved the case.
"""
setup = """## Setup
This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
Setup instructions: https://ela.st/install-elastic-defend
### Additional data sources
This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
- [CrowdStrike](https://ela.st/crowdstrike-integration)
- [Microsoft Defender XDR](https://ela.st/m365-defender)
- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Registry Events](https://ela.st/sysmon-event-reg-setup)
"""
[rule.investigation_fields]
field_names = [
"@timestamp",
"host.name",
"host.id",
"user.name",
"user.id",
"process.executable",
"process.command_line",
"process.entity_id",
"process.code_signature.subject_name",
"process.code_signature.trusted",
"process.parent.executable",
"process.parent.command_line",
"registry.path",
"registry.value",
"registry.data.strings",
]
[transform]
[[transform.investigate]]
label = "Process events for the writer"
description = ""
providers = [
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
{ excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "Child process events for the writer"
description = ""
providers = [
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
{ excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "Registry events for the writer"
description = ""
providers = [
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
{ excluded = false, field = "event.category", queryType = "phrase", value = "registry", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "Alerts associated with the user"
description = ""
providers = [
[
{ excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
{ excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[transform.investigate]]
label = "Alerts associated with the host"
description = ""
providers = [
[
{ excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[rule.threat]]
framework = "MITRE ATT&CK"
@@ -123,10 +220,7 @@ id = "T1562.001"
name = "Disable or Modify Tools"
reference = "https://attack.mitre.org/techniques/T1562/001/"
[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"