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

[Rule Tuning] Windows High-Severity Rules Revamp - 3 (#5969)

Browse Source
This commit is contained in:
Jonhnathan
2026-05-01 18:23:53 -03:00
committed by GitHub
parent 250ad4a8eb
commit ab7f9d7296
10 changed files with 1589 additions and 522 deletions
Download Patch File Download Diff File Expand all files Collapse all files
rules/windows/credential_access_adidns_wildcard.toml
+138 -63
View File
@@ -2,7 +2,7 @@
creation_date = "2024/03/26"
integration = ["system", "windows"]
maturity = "production"
updated_date = "2025/03/20"
updated_date = "2026/04/22"
[rule]
author = ["Elastic"]
@@ -10,78 +10,21 @@ description = """
Active Directory Integrated DNS (ADIDNS) is one of the core components of AD DS, leveraging AD's access control and
replication to maintain domain consistency. It stores DNS zones as AD objects, a feature that, while robust, introduces
some security issues, such as wildcard records, mainly because of the default permission (Any authenticated users) to
create DNS-named records. Attackers can create wildcard records to redirect traffic that doesn't explicitly match
records contained in the zone, becoming the Man-in-the-Middle and being able to abuse DNS similarly to LLMNR/NBNS
spoofing.
create DNS-named records. Attackers can create wildcard records to redirect traffic for names that do not explicitly
match records in the zone, positioning themselves as an adversary-in-the-middle and enabling credential interception or
relay through ADIDNS manipulation similar in outcome to LLMNR/NBNS spoofing.
"""
from = "now-9m"
index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
language = "eql"
license = "Elastic License v2"
name = "Potential ADIDNS Poisoning via Wildcard Record Creation"
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 ADIDNS Poisoning via Wildcard Record Creation
Active Directory Integrated DNS (ADIDNS) is crucial for maintaining domain consistency by storing DNS zones as AD objects. However, its default permissions allow authenticated users to create DNS records, which adversaries can exploit by adding wildcard records. This enables them to redirect traffic and perform Man-in-the-Middle attacks. The detection rule identifies such abuse by monitoring specific directory service changes indicative of wildcard record creation.
### Possible investigation steps
- Review the event logs on the affected Windows host to confirm the presence of event code 5137, which indicates a directory service object modification.
- Examine the ObjectDN field in the event data to identify the specific DNS zone where the wildcard record was created, ensuring it starts with "DC=*," to confirm the wildcard nature.
- Check the user account associated with the event to determine if it is a legitimate account or potentially compromised, focusing on any unusual or unauthorized activity.
- Investigate recent changes in the DNS zone to identify any other suspicious modifications or patterns that could indicate further malicious activity.
- Correlate the event with network traffic logs to detect any unusual or redirected traffic patterns that could suggest a Man-in-the-Middle attack.
- Assess the permissions and access controls on the DNS zones to ensure they are appropriately configured and restrict unnecessary modifications by authenticated users.
### False positive analysis
- Routine administrative changes to DNS records by IT staff can trigger alerts. To manage this, create exceptions for known administrative accounts or specific ObjectDN patterns that correspond to legitimate changes.
- Automated systems or scripts that update DNS records as part of regular maintenance may cause false positives. Identify these systems and exclude their activity from triggering alerts by filtering based on their unique identifiers or event sources.
- Software installations or updates that modify DNS settings might be flagged. Monitor and document these activities, and consider excluding them if they are part of a recognized and secure process.
- Changes made by trusted third-party services that integrate with ADIDNS could be misinterpreted as threats. Verify these services and whitelist their actions to prevent unnecessary alerts.
- Temporary testing environments that mimic production settings might generate alerts. Ensure these environments are clearly documented and excluded from monitoring if they are known to perform non-threatening wildcard record creations.
### Response and remediation
- Immediately isolate the affected system from the network to prevent further exploitation or data exfiltration.
- Revoke any potentially compromised credentials associated with the affected system or user accounts involved in the alert.
- Conduct a thorough review of DNS records in the affected zone to identify and remove any unauthorized wildcard entries.
- Implement stricter access controls on DNS record creation, limiting permissions to only necessary administrative accounts.
- Monitor network traffic for signs of Man-in-the-Middle activity, focusing on unusual DNS queries or redirections.
- Escalate the incident to the security operations center (SOC) for further investigation and to assess the potential impact on other systems.
- Update detection mechanisms to include additional indicators of compromise related to ADIDNS abuse, enhancing future threat detection capabilities."""
references = [
"https://www.netspi.com/blog/technical/network-penetration-testing/exploiting-adidns/",
"https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications/adidns-spoofing",
]
risk_score = 73
rule_id = "8f242ffb-b191-4803-90ec-0f19942e17fd"
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 the target object by default (we still need it to be configured to generate events), so we need to set up an AuditRule using https://github.com/OTRF/Set-AuditRule.
```
Set-AuditRule -AdObjectPath 'AD:\\CN=MicrosoftDNS,DC=DomainDNSZones,DC=Domain,DC=com' -WellKnownSidType WorldSid -Rights CreateChild -InheritanceFlags Descendents -AttributeGUID e0fa1e8c-9b45-11d0-afdd-00c04fd930c9 -AuditFlags Success
```
"""
severity = "high"
tags = [
"Domain: Endpoint",
@@ -101,6 +44,140 @@ any where host.os.type == "windows" and event.code == "5137" and
startsWith(winlog.event_data.ObjectDN, "DC=*,")
'''
note = """## Triage and analysis
### Investigating Potential ADIDNS Poisoning via Wildcard Record Creation
#### Possible investigation steps
- What wildcard object did the alert create, and which ADIDNS scope can it affect?
- Why: a leading `DC=*` object can answer otherwise unresolved names across that ADIDNS zone, so the zone and partition define the first impact boundary.
- Focus: `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectGUID`, `winlog.event_data.DSName`, and `winlog.computer_name`.
- Hint: parse `winlog.event_data.ObjectDN` from left to right. In `DC=*,DC=example.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=example,DC=com`, `DC=*` is the wildcard node, `DC=example.com` is the DNS zone, and `DC=DomainDnsZones,...` identifies the AD DNS partition.
- Implication: escalate faster when the object is a wildcard dnsNode in a production domain or forest DNS partition; lower concern only when the same object, zone, and domain controller align with a defensive sinkhole or contained test candidate, then continue to session and change evidence before closure.
- Which account created the wildcard?
- Focus: `user.name`, `user.id`, and `winlog.event_data.SubjectLogonId`.
- Implication: escalate when the creator is not a recognized zone-management, defensive sinkhole, or test identity for this object and zone; keep investigating when the account fits a known role because identity alone does not clear wildcard creation.
- Where did the creating session originate?
- Focus: 4624 events on the same `host.id` where `winlog.event_data.TargetLogonId` matches `winlog.event_data.SubjectLogonId`; review `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`.
- $investigate_2
- Implication: escalate when the source, logon type, or authentication method is unexpected for DC-side ADIDNS changes; missing 4624 origin data is unresolved, not benign.
- What DNS attributes or neighboring objects changed in the same operation?
- Focus: same-session 5136/5137 records keyed by `winlog.event_data.OpCorrelationID` or `winlog.event_data.SubjectLogonId`, then grouped by `winlog.event_data.ObjectGUID`; inspect `winlog.event_data.AttributeLDAPDisplayName` and `winlog.event_data.AttributeValue`.
- Hint: query the same domain controller and alert window for matching directory-service changes. Treat `winlog.event_data.AttributeValue` for `dnsRecord` as a lead because Security logs may encode or truncate record data. If the target is unclear, retrieve the current ADIDNS object or DNS record and compare it to `ObjectDN`, `ObjectGUID`, and the event timeline because current state may differ from event-time state. Missing DNS record data is unresolved, not benign. Windows Security alone does not prove tool identity or client redirection.
- $investigate_3
- Implication: escalate when 5136 data shows a dnsRecord target or adjacent ADIDNS changes not tied to the same verified sinkhole or test object; if `winlog.event_data.AttributeValue` is opaque or absent, the target remains unresolved.
- Did clients use the wildcard or authenticate to the recovered target?
- Focus: DNS/client telemetry for names in the affected zone and downstream network or authentication events to the recovered target; compare `dns.question.name`, `dns.resolved_ip`, `source.ip`, and `destination.ip`.
- Implication: escalate impact when clients query unresolved names that resolve to the wildcard target, then connect or authenticate to that target; missing DNS, network, or authentication telemetry is unresolved, not benign.
- If object, session, or change-set evidence stays suspicious, do related alerts suggest broader AD abuse?
- Focus: related alerts for `user.id` and `host.id` involving repeated directory-service changes, ADIDNS abuse, or credential access.
- $investigate_0
- $investigate_1
- Implication: broaden scope when the same actor or domain controller shows related AD, relay, or credential-access activity; keep scope local only when related alerts are absent and object, session, and change-set evidence fit a recognized sinkhole or test.
- Escalate when production wildcard scope, unrecognized creator/session, suspicious dnsRecord target, client-impact evidence, adjacent ADIDNS changes, or related AD-abuse alerts point to unrecognized wildcard creation; close only when all evidence fits the exact defensive sinkhole or contained test object; if mixed or incomplete, preserve and escalate.
### False positive analysis
- Wildcard records in AD-integrated DNS zones are an anti-pattern because they can replace NXDOMAIN behavior and redirect unresolved names. The plausible benign paths are narrow: an administrator-controlled defensive sinkhole or a contained red-team or penetration test. Confirm by verifying that `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectGUID`, `winlog.event_data.DSName`, `user.id`, `winlog.event_data.SubjectLogonId`, and recovered 5136 attribute evidence all align with that exact object and scope.
- If independent confirmation of the sinkhole or test is unavailable, do not close as benign even when the Windows Security evidence is internally consistent.
- Before creating an exception, require the same wildcard object, authorized zone, creator identity, and defensive or test window to recur as one stable workflow. Avoid exceptions on `user.name`, `user.id`, or the domain partition alone because those would suppress lookalike wildcard creation.
### Response and remediation
- If confirmed as an authorized defensive sinkhole or test, reverse any temporary containment, verify the wildcard is removed or retained according to that scope, and document `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectGUID`, `winlog.event_data.DSName`, creating `user.id`, `winlog.event_data.SubjectLogonId`, `winlog.computer_name`, and the confirming scope.
- If suspicious but unconfirmed, export the AD object state, replication context, and related 5136/5137 Windows Security events before modifying the record or account. Then apply reversible containment tied to the evidence, such as restricting the creating account's ADIDNS write path or temporarily limiting that account while scope is clarified.
- If confirmed malicious, preserve the exported AD object, 5136 attribute evidence, session-origin evidence, and related alerts before deletion. Remove the wildcard and any unauthorized ADIDNS objects from the same session, then verify removal replicated to all domain controllers.
- Disable or restrict the creating account after evidence preservation to prevent re-poisoning. Use `winlog.event_data.SubjectLogonId` and recovered `source.ip` to hand off the source system for endpoint investigation of ADIDNS tooling, credential capture, or follow-on authentication.
- If separate response evidence proves client redirection through the wildcard, treat credentials active on affected systems as exposed. Reset those accounts, prioritizing privileged and service accounts, and investigate for relayed authentication or follow-on access.
- Review ADIDNS permissions for the affected zone; reduce wildcard-creation opportunities, especially broadly delegated or authenticated-user create-child rights. Search all AD-integrated zones for additional wildcard or suspicious ADIDNS objects and document the final evidence set for future narrow exceptions.
"""
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.name",
"user.id",
"winlog.event_data.SubjectLogonId",
"winlog.event_data.OpCorrelationID",
"winlog.event_data.ObjectDN",
"winlog.event_data.ObjectGUID",
"winlog.event_data.DSName",
"winlog.computer_name",
"host.id"
]
[[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 domain controller"
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 = "Session origin (4624) for the wildcard-creating logon"
description = ""
providers = [
[
{ 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" },
{ excluded = false, field = "event.code", queryType = "phrase", value = "4624", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[transform.investigate]]
label = "Directory service changes from the wildcard-creating session"
description = ""
providers = [
[
{ 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" },
{ 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.SubjectLogonId", queryType = "phrase", value = "{{winlog.event_data.SubjectLogonId}}", valueType = "string" },
{ 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.SubjectLogonId", queryType = "phrase", value = "{{winlog.event_data.SubjectLogonId}}", valueType = "string" },
{ excluded = false, field = "event.code", queryType = "phrase", value = "5137", valueType = "string" }
]
]
relativeFrom = "now-1h/h"
relativeTo = "now"
[[rule.threat]]
framework = "MITRE ATT&CK"
@@ -109,9 +186,7 @@ id = "T1557"
name = "Adversary-in-the-Middle"
reference = "https://attack.mitre.org/techniques/T1557/"
[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"
rules/windows/credential_access_browsers_unusual_parent.toml
+168 -44
View File
@@ -2,13 +2,13 @@
creation_date = "2025/08/27"
integration = ["windows", "endpoint", "system", "m365_defender", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2026/04/07"
updated_date = "2026/04/22"
[rule]
author = ["Elastic"]
description = """
Identifies instances where an unusual process spawns a chrome browser child process. This behavior could be related to malware
stealing browser information.
Identifies instances where a browser is launched with remote debugging, headless automation, or minimal arguments from
an unusual parent process. This may indicate an attempt to broker or tamper with a browser session for credential theft.
"""
from = "now-9m"
index = [
@@ -24,40 +24,6 @@ index = [
language = "eql"
license = "Elastic License v2"
name = "Browser Process Spawned from an Unusual Parent"
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 Browser Process Spawned from an Unusual Parent
### Possible investigation steps
- Review the process execution details to confirm that a web browser process (e.g., chrome.exe, msedge.exe, firefox.exe) has an unusual or suspicious parent process. Focus on the process.parent.name, process.name, and process.args fields.
- Examine the command line arguments for signs of remote debugging flags (e.g., --remote-debugging-port, --remote-debugging-pipe) or injected DLLs that could indicate attempts to hijack browser sessions.
- Check whether the parent process is a scripting host (e.g., wscript.exe, cscript.exe), system utility, or unexpected binary (e.g., cmd.exe, rundll32.exe, powershell.exe) rather than the legitimate browser updater or system launcher.
- Investigate if the suspicious parent process has a known reputation or hash linked to malware or credential-stealing tools by correlating with threat intelligence sources.
- Look for additional related processes spawned by the browser that might indicate malicious activity, such as network connections to unusual external IPs or data exfiltration attempts.
- Review authentication logs to identify if any credential theft attempts occurred shortly after the suspicious browser activity, focusing on abnormal logins, failed authentications, or credential access patterns.
- Cross-reference with endpoint telemetry (e.g., Defender for Endpoint, Sysmon) to identify whether this event is part of a broader intrusion attempt involving code injection or persistence mechanisms.
### False positive analysis
- Certain enterprise management or testing tools may launch browsers with remote debugging enabled for automation purposes. Identify and document such legitimate tools and processes.
- Development environments may use browser remote debugging features during legitimate software testing. Exclude known dev/test machines or users from triggering alerts in production environments.
- Security testing frameworks or internal red team activities may use similar techniques. Coordinate with authorized security teams to whitelist scheduled exercises.
- Browser extensions or third-party plugins could sometimes spawn processes that appear unusual. Validate if the behavior aligns with known, legitimate extensions.
- Automated IT scripts or orchestration tools might start browsers in debugging mode for monitoring purposes. Whitelist these cases based on process path, signature, or command-line arguments.
### Response and remediation
- Isolate the affected endpoint from the network to prevent potential credential theft or data exfiltration.
- Terminate any suspicious processes identified in the alert, including both the browser and its anomalous parent process.
- Collect forensic artifacts (process memory, browser profiles, injected modules) for further investigation and potential IOCs.
- Reset credentials for accounts that may have been exposed through the compromised browser session.
- Deploy updated endpoint protection signatures and enable stricter application control policies to prevent browsers from being launched by untrusted processes.
- Enhance monitoring for browser processes launched with debugging flags or code injection indicators across the environment.
- Escalate to the SOC or IR team to determine whether this event is part of a larger credential theft campaign or linked to other lateral movement activity."""
references = ["https://www.elastic.co/security-labs/katz-and-mouse-game"]
risk_score = 73
rule_id = "46b01bb5-cff2-4a00-9f87-c041d9eab554"
@@ -81,19 +47,19 @@ type = "eql"
query = '''
process where host.os.type == "windows" and event.type == "start" and
process.name : ("chrome.exe", "msedge.exe") and
process.parent.executable != null and process.command_line != null and
process.parent.executable != null and
(
process.command_line :
("\"C:\\Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe\"",
process.command_line : (
"\"C:\\Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe\"",
"\"C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe\"",
"\"C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe\" --headless --disable-logging --log-level=3 --v=0",
"\"C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe\" --headless --log-level=3",
"\"C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe\" --headless",
"\"C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe\" --remote-debugging-port=922? --profile-directory=\"Default\"*",
"\"C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe\" --headless --restore-last-session --remote-debugging-port=45452*") or
(process.args : "--remote-debugging-port=922?" and process.args : "--window-position=-*,-*")
) and
"\"C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe\" --headless --restore-last-session --remote-debugging-port=45452*"
) or
(process.args : "--remote-debugging-port=922?" and process.args : "--window-position=-*,-*")
) and
not process.parent.executable :
("C:\\Windows\\explorer.exe",
"C:\\Program Files (x86)\\*.exe",
@@ -104,7 +70,165 @@ process where host.os.type == "windows" and event.type == "start" and
"C:\\Windows\\System32\\SECOCL64.exe")
'''
note = """## Triage and analysis
### Investigating Browser Process Spawned from an Unusual Parent
#### Possible investigation steps
- What browser-brokering path did the alert capture?
- Focus: `process.command_line`, `process.parent.executable`, `process.parent.command_line`, and `process.Ext.ancestry`.
- Implication: escalate with one corroborator when Chrome or Edge starts with high-risk arguments such as "--remote-debugging-port", "--user-data-dir", "--profile-directory", "--headless", offscreen window positioning, or bare browser execution from an unexplained shell, script host, Office app, archive tool, LOLBin, or remote-admin parent; lower suspicion only when a stable signed automation, RPA, support, or test-runner parent uses the same bounded debug or profile behavior for the same user-host cohort.
- Is the browser and launcher identity consistent with a signed automation toolchain?
- Focus: `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.parent.code_signature.subject_name`.
- Implication: escalate when the browser or launcher is unsigned, user-writable, mismatched to its product identity, or signed by an unexpected publisher; identity looks cleaner when Chrome or Edge and the launcher signer match the same recognized toolchain, but identity alone does not clear the browser-brokering behavior.
- Does the user, host, and session context fit the launch?
- Focus: `user.id`, `user.name`, `host.id`, `process.Ext.session_info.logon_type`, and `process.Ext.authentication_id`. $investigate_4
- Hint: if Windows Security logs are available, pivot `process.Ext.authentication_id` plus `host.id` to `winlog.event_data.TargetLogonId` for 4624 session origin, `source.ip`, and `winlog.event_data.AuthenticationPackageName`; search `winlog.event_data.SubjectLogonId` separately for 4648 explicit-credential context. Missing auth telemetry is unresolved, not benign.
- Implication: escalate when the browser starts from a service, scheduled, remote, or explicit-credential session that does not match the user-host role; lower suspicion when the session, parent, and user-host cohort all fit the same recognized automation pattern.
- Do network events show DevTools brokering or unexpected egress?
- Focus: if network telemetry is available, review browser- and parent-scoped connection events on `host.id` for `process.entity_id` and `process.parent.entity_id`: `source.ip`, `destination.ip`, and `destination.port`. $investigate_2
- Hint: separately review DNS events for `dns.question.name`; DNS events do not carry connection-side `source.ip` or `destination.ip`. The linked transform includes browser and parent `process.entity_id` values to catch browser egress and parent-side DevTools client connections. Missing network telemetry is unresolved, not benign.
- Implication: escalate when a parent or non-browser process connects over loopback to the browser debugging port, or when the browser reaches rare public destinations unrelated to the same automation pattern; lower suspicion when traffic stays inside recognized vendor, proxy, test, or local automation paths for that parent and command line.
- Do file events show browser-store collection or staged output?
- Focus: if file telemetry is available, review file events on `host.id` for `process.entity_id` and `process.parent.entity_id`: `file.path` and `file.Ext.original.path`, especially copied or renamed browser-store artifacts such as "Login Data", "Cookies", "Local State", or "LocalPrefs.json". $investigate_3
- Hint: if entity IDs are unavailable, pivot with `host.id`, process IDs, and a tight alert window; absence of file telemetry does not close the alert.
- Implication: escalate when the process writes copied browser databases, archives, exported tokens, or renamed outputs in user-writable paths; lower suspicion when file activity stays inside the recognized automation cache or download path and no browser-store artifacts are staged.
- Is the same browser-brokering pattern present beyond this process?
- Focus: if local evidence is suspicious or unresolved, review recent alerts for the same `user.id` and then the same `host.id`.
- Hint: user-scoped related alerts: $investigate_0
- Hint: host-scoped related alerts: $investigate_1
- Implication: escalate scope when the same parent, command-line pattern, destination, or browser-store artifact repeats across hosts or users; recurrence of one exact automation pattern supports exception review but does not override contradictory telemetry.
- What disposition does the evidence support?
- Focus: behavior path, browser and launcher identity, session context, DevTools or egress evidence, browser-store artifacts, and scope.
- Implication: escalate when an unexpected parent drives a browser debug interface, hidden automation, or profile targeting with suspicious session, network, file, or scope evidence; close only when alert-local process evidence and available session, network, file, and scope evidence all bind to one recognized automation, support, or test workflow; preserve and escalate when evidence is mixed or visibility is incomplete.
### False positive analysis
- Browser automation, QA, RPA, monitoring, enterprise management, remote-support, and security-testing workflows can legitimately launch Chrome or Edge with debug or headless behavior only when the signals converge: a stable signed launcher, bounded debug/profile arguments, the expected `user.id` and `host.id` cohort, and no parent-side DevTools client or browser-store staging outside that toolchain. When optional network or file telemetry is available, require it to fit the same workflow. For security testing, also confirm the activity is contained to the intended hosts and users.
- Before creating an exception, validate that `process.parent.executable`, `process.executable`, `process.code_signature.subject_name`, `process.command_line`, `user.id`, and `host.id` recur across prior alerts from this rule. Avoid exceptions on `process.name`, browser install paths, or remote-debugging text alone because those match both benign automation and credential-theft launchers.
### Response and remediation
- If confirmed benign, reverse temporary containment and document the evidence that proved the workflow: browser and launcher identity, parent command line, user-host scope, and any corroborating destinations or file artifacts. Create an exception only after the same confirmed pattern recurs across prior alerts from this rule.
- If suspicious but unconfirmed, export the alert, process tree, browser and parent command lines, relevant `process.entity_id` values, debugging port or profile arguments, and any collected file or network evidence before containment. Preserve copied browser stores, staged archives, dropped tools, and relevant browser-session state; apply reversible containment first, such as browser-session revocation, heightened monitoring on the affected `user.id` and `host.id`, or temporary destination controls.
- If confirmed malicious, record volatile browser-session state and preserve staged artifacts before terminating the browser or parent. Then isolate the host through endpoint response or equivalent controls when the host role can tolerate interruption. Block confirmed malicious destinations and hashes for the parent launcher, staged tool, or tampered browser binary; reset exposed credentials and revoke sessions when browser-store or cookie-theft evidence is present.
- After containment, scope related users and hosts for the same `process.parent.executable`, `process.command_line`, browser-store artifact, or confirmed destination pattern from network review. Remove only the unauthorized extensions, staged artifacts, or launcher components identified during investigation. Close the entry path by disabling the unauthorized launcher or restoring browser policy if it was changed.
"""
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:
- [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.name",
"user.id",
"process.entity_id",
"process.executable",
"process.command_line",
"process.parent.entity_id",
"process.parent.executable",
"process.parent.command_line",
"process.code_signature.subject_name",
"process.code_signature.trusted",
"process.parent.code_signature.subject_name",
"process.Ext.authentication_id",
"process.Ext.session_info.logon_type",
]
[[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 = "Network activity for browser and parent processes"
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 = "network", valueType = "string" }
],
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.parent.entity_id}}", valueType = "string" },
{ excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "File activity for browser and parent processes"
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.entity_id", queryType = "phrase", value = "{{process.parent.entity_id}}", valueType = "string" },
{ excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "Authentication events for the linked session"
description = ""
providers = [
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "winlog.event_data.TargetLogonId", queryType = "phrase", value = "{{process.Ext.authentication_id}}", valueType = "string" },
{ excluded = false, field = "event.code", queryType = "phrase", value = "4624", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[rule.threat]]
framework = "MITRE ATT&CK"
rules/windows/credential_access_cmdline_dump_tool.toml
+158 -40
View File
@@ -2,7 +2,7 @@
creation_date = "2020/11/24"
integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "system"]
maturity = "production"
updated_date = "2026/04/07"
updated_date = "2026/04/22"
[rule]
author = ["Elastic"]
@@ -24,40 +24,6 @@ index = [
language = "eql"
license = "Elastic License v2"
name = "Potential Credential Access via Windows Utilities"
note = """## Triage and analysis
### Investigating Potential Credential Access via Windows Utilities
Local Security Authority Server Service (LSASS) is a process in Microsoft Windows operating systems that is responsible for enforcing security policy on the system. It verifies users logging on to a Windows computer or server, handles password changes, and creates access tokens.
The `Ntds.dit` file is a database that stores Active Directory data, including information about user objects, groups, and group membership.
This rule looks for the execution of utilities that can extract credential data from the LSASS memory and Active Directory `Ntds.dit` file.
#### 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 abnormal behaviors observed by the subject process, such as network connections, registry or file modifications, and any spawned child processes.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Examine the command line to identify what information was targeted.
- Identify the target computer and its role in the IT environment.
### False positive analysis
- This activity is unlikely to happen legitimately. Any activity that triggered the alert and is not inherently malicious must be monitored by the security team.
### Response and remediation
- Initiate the incident response process based on the outcome of the triage.
- If the host is a domain controller (DC):
- Activate your incident response plan for total Active Directory compromise.
- Review the privileges assigned to users that can access the DCs, to ensure that the least privilege principle is being followed and to reduce the attack surface.
- Isolate the involved hosts 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.
- 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://lolbas-project.github.io/",
"https://www.elastic.co/security-labs/elastic-protects-against-data-wiper-malware-targeting-ukraine-hermeticwiper",
@@ -117,6 +83,163 @@ process where host.os.type == "windows" and event.type == "start" and
)
'''
note = """## Triage and analysis
### Investigating Potential Credential Access via Windows Utilities
#### Possible investigation steps
- Which utility path did the alert take, and is the binary identity credible?
- Focus: `process.name`, `process.pe.original_file_name`, `process.executable`, `process.command_line`, and `process.code_signature.subject_name`.
- Implication: escalate faster when the alert path is a dump-capable utility from a user-writable, renamed, missing expected signer, or unexpected location; lower suspicion only when the utility family, signer, installed path, and command pattern fit one recognized diagnostic, SQL troubleshooting, crash-triage, or AD maintenance workflow. Identity alone does not clear the behavior.
- Do the arguments identify a credential-dump objective?
- Focus: `process.command_line`: credential target, dump mode, script path, and output location.
- Hint: high-risk examples include "procdump -ma lsass.exe", Rundll32/comsvcs MiniDump, ntdsutil IFM output, and "diskshadow.exe /s" scripts that expose, copy, exec, or delete shadow-copy paths.
- Implication: escalate when arguments target LSASS, invoke Rundll32/comsvcs dumping, create NTDS/IFM output, drive VSS script execution, or write to user-writable or share paths; lower suspicion when the target is clearly non-credential and the output path matches the same recognized troubleshooting or backup workflow.
- Does the parent chain explain why this host would run a dump or snapshot utility?
- Focus: `process.parent.executable`, `process.parent.command_line`, `process.Ext.ancestry`, and `process.Ext.session_info.logon_type`, with `user.id` defining the actor scope.
- Implication: escalate when the chain starts from shells, script hosts, Office processes, unexpected services, scheduled tasks, or remote-interactive sessions; lower suspicion only when the same actor, session type, and parent workflow explain the utility launch and do not conflict with command intent.
- If file telemetry is available, did the utility create dump, shadow-copy, or directory database artifacts?
- Focus: recover file events with `host.id` + `process.entity_id`; if `process.entity_id` is missing, use `host.id` + `process.pid` + a tight alert window, then review `file.path`, `file.Ext.original.path`, and `file.Ext.header_bytes` for dump files, copied directory-database material, IFM folders, registry hives, shadow-copy output, or archive staging. $investigate_2
- Implication: escalate when artifacts show LSASS dumps, AD database or credential-hive collection, shadow-copy access, or staged archives; close cannot rely on absent file events because missing file telemetry is unresolved, not benign.
- Do child processes or connection events show collected material being staged or exported?
- Focus: child process starts, file activity, and network activity where `process.parent.entity_id` matches the alerting `process.entity_id` on `host.id`; if network telemetry is available, review `destination.ip`, `destination.port`, and `network.direction`. $investigate_3 $investigate_4
- Hint: if the utility spawns a short-lived archiver or copy tool, pivot from that child into same-host connection events before broadening.
- Implication: escalate when the utility or child process spawns archivers, copy tools, "diskshadow.exe" exec children, or transfers dump material off-host; missing network telemetry is unresolved, not benign.
- If local findings remain suspicious or unresolved, do related alerts show broader credential-access activity?
- Focus: related alerts for `user.id` covering dumping, privilege escalation, lateral movement, archiving, or staging. $investigate_0
- Hint: if the actor view is sparse, pivot to related alerts for `host.id` covering precursor access, persistence, archiving, or exfiltration. $investigate_1
- Implication: broaden when either view shows a credential-access chain or reuse of the same utility pattern; do not close solely because related alerts are absent if command intent, artifacts, lineage, or post-dump cleanup remain suspicious.
- Disposition: escalate when utility identity, command intent, lineage, artifacts, staging, or related scope indicate credential access; close only when identity, arguments, lineage, recovered artifacts, and supported scope all align with one recognized diagnostic, troubleshooting, crash-triage, backup, or IFM workflow; preserve artifacts and escalate when evidence is mixed or visibility is incomplete.
### False positive analysis
- Recognized crash-triage, SQL troubleshooting, AD backup, or IFM workflows can trigger this rule. Confirm the same workflow across identity (`process.executable`, `process.code_signature.subject_name`), lineage (`process.parent.executable`), intent (`process.command_line`), actor/scope (`user.id`, `host.id`), and recovered artifact paths when available. Case records may corroborate the workflow, but do not close on recurrence alone; use prior alerts only after current telemetry aligns.
- Build exceptions only from the confirmed recurring workflow: `process.executable`, `process.code_signature.subject_name`, `process.parent.executable`, stable `process.command_line`, `user.id`, `host.id`, and recovered output path or dump-directory pattern when available. Avoid exceptions on `process.name`, `host.id`, utility family, or generic dump switches alone.
### Response and remediation
- If confirmed benign, record the recognized diagnostic, backup, or directory-services evidence in `process.executable`, `process.command_line`, `process.parent.executable`, `user.id`, `host.id`, and recovered output paths when available, then reverse any temporary containment. Create an exception only if that same pattern recurs consistently across prior alerts from this rule.
- If suspicious but unconfirmed, preserve the recovered `process.entity_id` or `process.pid` with `host.id` and time, `process.command_line`, script-file, dump, shadow-copy, and copied-database paths, child-process lineage via `process.parent.entity_id` / `process.parent.pid`, and any confirmed destination pairs before making destructive changes. Apply reversible containment first, such as temporary destination blocking or increased monitoring on the affected `host.id` and `user.id`. Escalate to host isolation only if dump material, IFM output, or staging transfers are confirmed and the host can tolerate interruption.
- If confirmed malicious, use endpoint response actions to isolate the host and terminate the dump or staging process after preserving `process.entity_id`, `process.parent.entity_id`, `process.command_line`, recovered output paths, any available `process.hash.sha256`, and confirmed destinations. If direct endpoint response is unavailable, hand off that artifact set immediately to the team that can isolate the system or block the destinations.
- If LSASS dumping is confirmed, assume exposure for all accounts with active sessions on the affected host, including interactive, service, and cached credentials. Prioritize resets for privileged, service, and lateral-movement-relevant accounts and review whether the dump material was staged or transferred before containment.
- If NTDS access or dump activity is confirmed on a domain controller, activate the organization's Active Directory compromise response plan, preserve the evidence needed to scope database and credential exposure, and begin privileged-account hygiene based on the systems and accounts implicated by the investigation before deleting copied database material.
- Review related hosts and users for the same `process.command_line` patterns, dump-file naming patterns, `process.parent.executable`, and confirmed destinations before deleting dump files, IFM output, shadow copies, utilities, or persistence mechanisms uncovered during the investigation, then remediate the delivery or privilege path that allowed the utility to run.
"""
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:
- [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.name",
"user.id",
"process.entity_id",
"process.name",
"process.executable",
"process.command_line",
"process.pe.original_file_name",
"process.parent.entity_id",
"process.parent.executable",
"process.parent.command_line",
"process.code_signature.subject_name",
"process.code_signature.trusted",
"process.Ext.session_info.logon_type",
]
[[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 = "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 = "Network 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 = "network", 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 = "network", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[rule.threat]]
framework = "MITRE ATT&CK"
@@ -134,8 +257,6 @@ id = "T1003.003"
name = "NTDS"
reference = "https://attack.mitre.org/techniques/T1003/003/"
[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
@@ -151,10 +272,7 @@ id = "T1218.011"
name = "Rundll32"
reference = "https://attack.mitre.org/techniques/T1218/011/"
[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
rules/windows/credential_access_copy_ntds_sam_volshadowcp_cmdline.toml
+173 -87
View File
@@ -2,33 +2,7 @@
creation_date = "2020/11/24"
integration = ["endpoint", "windows", "system", "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/22"
[rule]
author = ["Elastic", "Austin Songer"]
@@ -52,62 +26,6 @@ language = "eql"
license = "Elastic License v2"
max_signals = 33
name = "NTDS or SAM Database File Copied"
note = """## Triage and analysis
### Investigating NTDS or SAM Database File Copied
The Active Directory Domain Database (ntds.dit) and Security Account Manager (SAM) files are critical components in Windows environments, containing sensitive information such as hashed domain and local credentials.
This rule identifies copy operations of these files using specific command-line tools, such as Cmd.Exe, PowerShell.EXE, XCOPY.EXE, and esentutl.exe. By monitoring for the presence of these tools and their associated arguments, the rule aims to detect potential credential access activities.
> **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, command lines, whether they are located in expected locations, and if they are signed with valid digital signatures.
- Identify the user account that performed the action and whether it should perform this kind of action.
- Contact the account owner and confirm whether they are aware of this activity.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Check for any recent changes in user account privileges or group memberships that may have allowed the unauthorized access.
- Determine whether the file was potentially exfiltrated from the subject host.
- Scope compromised credentials and disable the accounts.
- Examine the host for derived artifacts that indicate suspicious activities:
- Analyze the process executable 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.
- Look for the presence of relevant artifacts on other systems. Identify commonalities and differences between potentially compromised systems.
### 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.
- If malicious activity is confirmed, perform a broader investigation to identify the scope of the compromise and determine the appropriate remediation steps.
- 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.
- 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://thedfirreport.com/2020/11/23/pysa-mespinoza-ransomware/",
"https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1003.002/T1003.002.md#atomic-test-3---esentutlexe-sam-copy",
@@ -142,9 +60,180 @@ process where host.os.type == "windows" and event.type == "start" and
) or
((?process.pe.original_file_name : "esentutl.exe" or process.name : "esentutl.exe") and process.args : ("*/y*", "*/vss*", "*/d*"))
) and
process.command_line : ("*\\ntds.dit*", "*\\config\\SAM*", "*\\*\\GLOBALROOT\\Device\\HarddiskVolumeShadowCopy*\\*", "*/system32/config/SAM*", "*\\User Data\\*")
process.command_line : ("*\\ntds.dit*", "*\\config\\SAM*", "*\\*\\GLOBALROOT\\Device\\HarddiskVolumeShadowCopy*\\*", "*/system32/config/SAM*")
'''
note = """## Triage and analysis
### Investigating NTDS or SAM Database File Copied
#### Possible investigation steps
- What protected store did the alerting command try to copy, and where was it sent?
- Focus: `process.command_line` for NTDS vs SAM, direct path vs "GLOBALROOT\\Device\\HarddiskVolumeShadowCopy" or "esentutl.exe /y /vss /d", and a local, UNC, archive, or temp-like destination.
- Implication: escalate when the command copies NTDS, SAM, or a VSS-backed hive to a user-writable, remote, or archive path, and treat NTDS as domain credential exposure and SAM as local credential exposure; lower suspicion only when the exact source, destination, and copy method fit one recognized backup, repair, or authorized forensic collection. Identity alone never clears the copy.
- If PowerShell performed the copy, what script content produced it?
- Focus: if PowerShell script-block telemetry is available, recover events with `host.id` + `process.pid` in a tight alert window; reconstruct split blocks with `powershell.file.script_block_id`, `powershell.sequence`, and `powershell.total`, then read `powershell.file.script_block_text`. Missing PowerShell telemetry is unresolved, not benign.
- Implication: escalate when the reconstructed script copies NTDS, SAM, or VSS paths, loops shadow copies, hides destinations, or chains archive or transfer logic; lower suspicion when script content matches the same recognized backup, repair, or forensic workflow as the alert command.
- Is the copier the expected binary in the expected launch chain?
- Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.parent.executable`.
- Implication: escalate when the copier is renamed, unsigned or unexpectedly signed, runs from a user-writable path, or is launched by an unusual shell, script, service, or remote tool; lower suspicion when the same binary identity and parent chain match the workflow proven in the command line.
- Does the user, privilege, and session context fit protected credential-store access?
- Focus: `user.id`, `process.Ext.session_info.logon_type`, `process.Ext.token.integrity_level_name`, and `process.Ext.authentication_id`. $investigate_2
- Hint: if Windows Security authentication logs are available, recover session origin by matching `process.Ext.authentication_id` to same-host `winlog.event_data.TargetLogonId`, then read `source.ip` and `winlog.event_data.AuthenticationPackageName`. Missing authentication telemetry is unresolved, not benign.
- Implication: escalate when the copy runs under an unexpected admin, service, machine, remote-interactive, or high-integrity context, or when recovered origin evidence conflicts with the same backup, repair, or forensic pattern; lower suspicion only when account, session type, and origin all match that pattern.
- Do recovered artifacts or follow-on activity show staging or transfer?
- Focus: if endpoint file telemetry is available, recover file events for the copier and children; read `file.path` and `file.name`. Missing file telemetry is unresolved, not benign. $investigate_3
- Hint: review child starts where `process.parent.entity_id` matches the copier, especially `process.command_line` and `process.executable`; if endpoint network telemetry is available, recover connections for the copier and children, then read `destination.ip`, `destination.port`, and `network.direction`. Missing network telemetry is unresolved, not benign. $investigate_4 $investigate_5
- Implication: escalate when copied hives, "ntds.dit", SAM exports, archives, child archivers, share-copy tools, upload utilities, or outbound connections reuse the copied store or destination; absence of recovered artifacts or connections cannot close the alert by itself.
- If local evidence is unrecognized, is this copy part of a VSS-to-archive credential-access chain?
- Focus: related alerts for `user.id` showing shadow-copy creation, credential dumping, archiving, privilege escalation, lateral movement, or the same command/store pattern. $investigate_0
- Hint: compare `host.id` history for the same store or destination pattern; this rule catches the copy, so earlier shadow-copy or backup-service activity changes scope. $investigate_1
- Implication: broaden scope when related evidence shows shadow-copy creation before the copy or archiving/transfer after it; do not close while the current copy evidence remains unresolved.
- Escalate on an unrecognized NTDS, SAM, or VSS copy to a staging path, abnormal copier or parent, mismatched session, recovered script/artifact/transfer evidence, or a VSS-to-archive chain; close only when source, destination, copier, session, and recovered evidence all match one backup, repair, or authorized forensic/IR pattern; preserve and escalate when evidence is mixed or incomplete.
### False positive analysis
- Backup, disaster-recovery, repair, and authorized forensic/IR collection can legitimately copy NTDS, SAM, or VSS-backed hives. Confirm by aligning identity (`process.executable`, `process.code_signature.subject_name`, `process.parent.executable`), intent (bounded `process.command_line` source/destination), and scope (`user.id`, `host.id`, recovered artifact destination, and recovered session origin). If organizational records are unavailable, close only when telemetry proves the same identity, command, destination, artifact, session, `user.id`, and `host.id` pattern; otherwise preserve and escalate.
- Build exceptions only from the minimum confirmed workflow pattern: stable `process.executable` or `process.code_signature.subject_name`, `process.parent.executable`, bounded `process.command_line` source/destination, `user.id`, and `host.id`. Avoid exceptions on utility name, copied store name, or destination family alone.
### Response and remediation
- If confirmed benign, reverse temporary containment and document the evidence that proved the workflow: copier identity, parent chain, command source/destination, recovered artifact destination, `user.id`, `host.id`, and recovered session origin. Create an exception only after a tuning review confirms the same stable workflow pattern; do not suppress on one partial match.
- If suspicious but unconfirmed, preserve the alert, Timeline or query results, `process.entity_id` or `process.pid` + `host.id` + alert time, `process.command_line`, `process.parent.executable`, recovered copied-store paths, archive names, destination shares, transfer destinations, and recovered session-origin evidence before containment or cleanup.
- Apply reversible containment next: restrict the destination share, block confirmed transfer destinations, heighten monitoring for the affected `host.id` and `user.id`, or isolate the endpoint only after weighing tier-0 and production impact.
- If malicious activity is confirmed, isolate the host or contain the account according to the evidence, then terminate the copy, archive, or transfer process only after preserving `process.entity_id`, `process.parent.entity_id`, command lines, copied-store locations, and destination indicators.
- For confirmed NTDS copying, activate the Active Directory compromise response plan and begin credential hygiene for affected administrative tiers. For confirmed SAM copying, scope local-account and service-account exposure on the affected endpoint or server.
- After evidence export and scoping, eradicate only copied databases or hives, archives, shadow-copy artifacts, and staging utilities identified during investigation, then remediate the privilege path or access vector that enabled the copy.
"""
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.name",
"user.id",
"process.entity_id",
"process.executable",
"process.command_line",
"process.pe.original_file_name",
"process.parent.entity_id",
"process.parent.executable",
"process.parent.command_line",
"process.code_signature.subject_name",
"process.Ext.authentication_id",
"process.Ext.session_info.logon_type",
"process.Ext.token.integrity_level_name",
]
[[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 = "Authentication events for the linked session"
description = ""
providers = [
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "winlog.event_data.TargetLogonId", queryType = "phrase", value = "{{process.Ext.authentication_id}}", valueType = "string" },
{ excluded = false, field = "event.code", queryType = "phrase", value = "4624", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[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 copier"
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 = "Network 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 = "network", 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 = "network", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[rule.threat]]
framework = "MITRE ATT&CK"
@@ -162,10 +251,7 @@ id = "T1003.003"
name = "NTDS"
reference = "https://attack.mitre.org/techniques/T1003/003/"
[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"
rules/windows/credential_access_credential_dumping_msbuild.toml
+168 -88
View File
@@ -2,33 +2,7 @@
creation_date = "2020/03/25"
integration = ["endpoint", "windows"]
maturity = "production"
updated_date = "2025/03/20"
[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/22"
[rule]
author = ["Elastic"]
@@ -47,59 +21,9 @@ index = [
language = "eql"
license = "Elastic License v2"
name = "Potential Credential Access via Trusted Developer Utility"
note = """## Triage and analysis
### Investigating Potential Credential Access via Trusted Developer Utility
The Microsoft Build Engine is a platform for building applications. This engine, also known as MSBuild, provides an XML schema for a project file that controls how the build platform processes and builds software.
Adversaries can abuse MSBuild to proxy the execution of malicious code. The inline task capability of MSBuild that was introduced in .NET version 4 allows for C# or Visual Basic code to be inserted into an XML project file. MSBuild will compile and execute the inline task. `MSBuild.exe` is a signed Microsoft binary, and the execution of code using it can bypass application control defenses that are configured to allow `MSBuild.exe` execution.
This rule looks for the MSBuild process loading `vaultcli.dll` or `SAMLib.DLL`, which indicates the execution of credential access activities.
> **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 abnormal behaviors observed by the subject process, such as network connections, registry or file modifications, and any spawned child processes.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Examine the command line to identify the `.csproj` file location.
- Examine the host for derived artifacts that indicate suspicious activities:
- Analyze the file 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' `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.
- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification.
### 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 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.
- 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://lolbas-project.github.io/lolbas/Binaries/Msbuild/",
]
risk_score = 73
rule_id = "9d110cb3-5f4b-4c9a-b9f5-53f0a1707ae5"
severity = "high"
@@ -113,15 +37,177 @@ tags = [
"Data Source: Elastic Defend",
"Data Source: Sysmon",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
sequence by process.entity_id
[process where host.os.type == "windows" and event.type == "start" and (process.name : "MSBuild.exe" or process.pe.original_file_name == "MSBuild.exe")]
[any where host.os.type == "windows" and (event.category == "library" or (event.category == "process" and event.action : "Image loaded*")) and
(?dll.name : ("vaultcli.dll", "SAMLib.DLL") or file.name : ("vaultcli.dll", "SAMLib.DLL"))]
[library where host.os.type == "windows" and dll.name : ("vaultcli.dll", "SAMLib.DLL")]
'''
note = """## Triage and analysis
### Investigating Potential Credential Access via Trusted Developer Utility
#### Possible investigation steps
- What do the matched source events show about the MSBuild instance?
- Focus: Timeline source events for `process.entity_id` -- the start-event `process.executable` and `process.command_line` plus the library-stage `dll.path`.
- Implication: more concerning when MSBuild loads vaultcli.dll or SAMLib.dll from an unusual path or unexpected context; more explainable when Timeline shows a recognized build task loading the library from the default Windows system directory.
- Is the MSBuild binary and launch chain expected for this host?
- Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.parent.executable`.
- Implication: more concerning when MSBuild is renamed, unsigned, user-writable, outside expected .NET Framework or Visual Studio build roots, or launched by Office, a script host, an archive utility, or another unexpected parent.
- Does the command line or project path suggest transient or user-delivered build content?
- Focus: `process.command_line` and `process.working_directory`, especially .csproj, .xml, .proj, /logger, or @ response-file paths in temp folders, downloads, removable media, user-profile paths, or network shares.
- Implication: supports concern when MSBuild runs user-delivered project content, logger DLLs, response files, or inline tasks outside normal compilation; less suspicious when the project resides in a stable source-tree or CI workspace and the build arguments match a recurring compilation pattern.
- Does the loaded credential library path, trust, and recency fit legitimate development behavior?
- Focus: `dll.name`, `dll.path`, `dll.code_signature.trusted`, and `dll.Ext.relative_file_creation_time`.
- Implication: supports concern when vaultcli or SAMLib loads from user-writable or transient paths, arrives unsigned, or was created shortly before the load; weaker support when the path is the expected Windows system directory and project context supports a recognized credential-management test.
- Do file writes or child processes show MSBuild acting as a launcher instead of a compiler?
- Focus: file activity from `process.entity_id`: written `file.path` values, especially payloads, scripts, or compiled artifacts in user-writable paths. $investigate_2
- Hint: review child starts where `process.parent.entity_id` equals the MSBuild entity; shell or script-engine children are stronger than normal compiler toolchain children. $investigate_3
- Implication: suggests proxy execution when MSBuild drops payloads, stages scripts or compiled artifacts, or spawns shells or script engines. Missing file telemetry is unresolved, not benign.
- Do MSBuild or its child processes attempt off-host staging?
- Focus: same-host connection events for the MSBuild `process.entity_id` or direct children where `process.parent.entity_id` matches the MSBuild entity, with `destination.ip` and `destination.port`. $investigate_4
- Implication: supports containment when suspicious project, DLL, file, or child-process evidence is followed by outbound staging; missing network telemetry is unresolved, not benign.
- Does the user and host context fit developer or build-runner activity?
- Focus: `user.id`, `user.domain`, `process.Ext.session_info.logon_type`, `host.id`, and `host.name`; compare prior source events for the same user-host cohort.
- Implication: risk rises when the user-host pair has no recurring build-tool history or when the session type is unexpected; lower only when the user, host, session, and source events fit a bounded developer or build-service pattern.
- If local MSBuild evidence is still suspicious, does related alert history show the same user or host reusing trusted-utility abuse patterns?
- Focus: related alerts for `user.id`, especially trusted-utility abuse, credential access, lateral movement, or launches of "InstallUtil", "RegAsm", "MSHTA", or similar signed proxies; inspect their source events before comparing project paths or destinations. $investigate_0
- Hint: compare `host.id` alert history to assess whether activity is confined to this asset. $investigate_1
- Implication: suggests broader scope when the same user or host shows trusted-utility abuse, persistence, staging, or credential-access alerts; stays localized when history is limited to the same recognized build or test workflow on this asset.
- Escalate when MSBuild identity, project path, loaded library, follow-on behavior, user-host context, or alert scope show unrecognized use, credential-library loads from non-standard paths, or payload behavior; close only when all jointly fit a recognized build or test scenario; preserve and escalate when evidence is mixed or visibility incomplete.
### False positive analysis
- Authorized credential-management tests, security-tool validation, or build pipelines compiling code that uses Windows credential APIs can legitimately trigger vaultcli.dll or SAMLib.dll loads. Confirm only when `process.command_line`, project path, `dll.path`, `process.executable`, `process.parent.executable`, `user.id`, and `host.id` align with that same recognized lab or build-pipeline workflow. If records are unavailable, require the same process-identity fields, loaded `dll.path`, and `user.id`/`host.id` to recur across prior alerts before treating the activity as benign.
- Before creating an exception, validate that `process.executable`, `process.code_signature.subject_name`, `process.parent.executable`, stable `process.command_line` pattern, loaded `dll.path`, `user.id`, and `host.id` recur across prior alerts from this rule. Build the exception from that minimum confirmed workflow pattern. Avoid exceptions on `process.name` alone, the library name alone, or the host alone.
### Response and remediation
- If confirmed benign, reverse temporary containment and record the confirmed explanation in `process.executable`, `process.parent.executable`, project path from `process.command_line`, loaded `dll.path`, `user.id`, and `host.id`. Create an exception only if that same pattern recurs consistently across prior alerts from this rule.
- If suspicious but unconfirmed, preserve a case export for the recovered MSBuild process, its command line, project/task files, loaded credential DLL, dropped artifacts, child-process lineage, and confirmed destinations. Apply reversible containment first -- temporary destination restrictions or heightened monitoring on `host.id` and `user.id` -- and escalate to host isolation only when preserved evidence shows meaningful staging or payload risk.
- If confirmed malicious, use endpoint response actions to isolate the host and terminate MSBuild or its staging child processes after preserving the recovered MSBuild and parent entity IDs, project files, compiled artifacts, child processes, confirmed destinations, and loaded DLL path. If direct endpoint response is unavailable, hand off that artifact set immediately to the team that can isolate the host or block the destinations.
- Eradicate the malicious project files, inline tasks, payloads, persistence artifacts, and secondary tooling uncovered during the investigation, then remediate the delivery or execution-control gap that allowed MSBuild to proxy the credential-access behavior.
- Investigate credential exposure based on what the project targeted: review Windows Credential Manager, saved secrets, and local-account exposure on the host, and rotate or revoke affected credentials according to the recovered artifacts and follow-on activity.
- Review related hosts for the same project-path pattern, library-load combination, child-process behavior, and adjacent trusted-developer-utility abuse before deleting files or removing tooling, and retain process, library, file, and network telemetry needed for future cases.
"""
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:
- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
- [Sysmon Event ID 7 - Image Loaded](https://ela.st/sysmon-event-7-setup)
"""
[rule.investigation_fields]
field_names = [
"@timestamp",
"host.id",
"user.name",
"user.id",
"process.entity_id",
"process.executable",
"process.command_line",
"process.working_directory",
"process.parent.executable",
"process.code_signature.subject_name",
"process.Ext.session_info.logon_type",
"dll.name",
"dll.path",
"dll.code_signature.trusted",
"dll.Ext.relative_file_creation_time",
]
[[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 = "File activity for the MSBuild 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 spawned by MSBuild"
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 = "Network activity for the MSBuild 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 = "network", 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 = "network", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[rule.threat]]
framework = "MITRE ATT&CK"
@@ -134,7 +220,6 @@ id = "T1003.002"
name = "Security Account Manager"
reference = "https://attack.mitre.org/techniques/T1003/002/"
[[rule.threat.technique]]
id = "T1555"
name = "Credentials from Password Stores"
@@ -144,8 +229,6 @@ id = "T1555.004"
name = "Windows Credential Manager"
reference = "https://attack.mitre.org/techniques/T1555/004/"
[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
@@ -161,10 +244,7 @@ id = "T1127.001"
name = "MSBuild"
reference = "https://attack.mitre.org/techniques/T1127/001/"
[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
rules/windows/credential_access_dcsync_newterm_subjectuser.toml
+150 -68
View File
@@ -2,7 +2,7 @@
creation_date = "2022/12/19"
integration = ["windows", "system"]
maturity = "production"
updated_date = "2025/11/14"
updated_date = "2026/04/22"
[rule]
author = ["Elastic"]
@@ -15,44 +15,7 @@ from = "now-9m"
index = ["winlogbeat-*", "logs-system.security*", "logs-windows.forwarded*"]
language = "kuery"
license = "Elastic License v2"
name = "FirstTime Seen Account Performing DCSync"
note = """## Triage and analysis
### Investigating FirstTime Seen Account Performing DCSync
Active Directory replication is the process by which the changes that originate on one domain controller are automatically transferred to other domain controllers that store the same data.
Active Directory data consists of objects that have properties, or attributes. Each object is an instance of an object class, and object classes and their respective attributes are defined in the Active Directory schema. Objects are defined by the values of their attributes, and changes to attribute values must be transferred from the domain controller on which they occur to every other domain controller that stores a replica of an affected object.
Adversaries can use the DCSync technique that uses Windows Domain Controller's API to simulate the replication process from a remote domain controller, compromising major credential material such as the Kerberos krbtgt keys that are used legitimately for creating tickets, but also for forging tickets by attackers. This attack requires some extended privileges to succeed (DS-Replication-Get-Changes and DS-Replication-Get-Changes-All), which are granted by default to members of the Administrators, Domain Admins, Enterprise Admins, and Domain Controllers groups. Privileged accounts can be abused to grant controlled objects the right to DCsync/Replicate.
More details can be found on [Threat Hunter Playbook](https://threathunterplaybook.com/library/windows/active_directory_replication.html?highlight=dcsync#directory-replication-services-auditing) and [The Hacker Recipes](https://www.thehacker.recipes/ad/movement/credentials/dumping/dcsync).
This rule monitors for when a Windows Event ID 4662 (Operation was performed on an Active Directory object) with the access mask 0x100 (Control Access) and properties that contain at least one of the following or their equivalent Schema-Id-GUID (DS-Replication-Get-Changes, DS-Replication-Get-Changes-All, DS-Replication-Get-Changes-In-Filtered-Set) is seen in the environment for the first time in the last 15 days.
#### Possible investigation steps
- Identify the user account that performed the action and whether it should perform this kind of action.
- 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.
- Correlate security events 4662 and 4624 (Logon Type 3) by their Logon ID (`winlog.logon.id`) on the Domain Controller (DC) that received the replication request. This will tell you where the AD replication request came from, and if it came from another DC or not.
- Scope which credentials were compromised (for example, whether all accounts were replicated or specific ones).
### False positive analysis
- Administrators may use custom accounts on Azure AD Connect; investigate if this is part of a new Azure AD account setup, and ensure it is properly secured. If the activity was expected and there is no other suspicious activity involving the host or user, the analyst can dismiss the alert.
- Although replicating Active Directory (AD) data to non-Domain Controllers is not a common practice and is generally not recommended from a security perspective, some software vendors may require it for their products to function correctly. Investigate if this is part of a new product setup, and ensure it is properly secured. If the activity was expected and there is no other suspicious activity involving the host or user, the analyst can dismiss the alert.
### 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.
- If the entire domain or the `krbtgt` user was compromised:
- Activate your incident response plan for total Active Directory compromise which should include, but not be limited to, a password reset (twice) of the `krbtgt` user.
- 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).
"""
name = "First Time Seen Account Performing DCSync"
references = [
"https://threathunterplaybook.com/notebooks/windows/06_credential_access/WIN-180815210510.html",
"https://threathunterplaybook.com/library/windows/active_directory_replication.html?highlight=dcsync#directory-replication-services-auditing",
@@ -63,22 +26,6 @@ references = [
]
risk_score = 73
rule_id = "5c6f4c58-b381-452a-8976-f1b1c6aa0def"
setup = """## Setup
The 'Audit Directory Service Access' 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 Access (Success,Failure)
```
"""
severity = "high"
tags = [
"Domain: Endpoint",
@@ -103,6 +50,153 @@ event.code:"4662" and host.os.type:"windows" and
not winlog.event_data.SubjectUserName:(*$ or MSOL_*)
'''
note = """## Triage and analysis
### Investigating First Time Seen Account Performing DCSync
#### Possible investigation steps
- What did the alerted 4662 prove about the subject and replication request?
- Focus: `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.Properties`, `winlog.event_data.AccessMask`, and `winlog.computer_name`.
- Hint: replication-right GUIDs map to `DS-Replication-Get-Changes` (`1131f6aa-9c07-11d1-f79f-00c04fc2dcd2`), `DS-Replication-Get-Changes-All` (`1131f6ad-9c07-11d1-f79f-00c04fc2dcd2`), and `DS-Replication-Get-Changes-In-Filtered-Set` (`89e95b76-444d-4c62-991a-0facbeda640c`).
- Implication: escalate faster when a human admin, new service account, or other non-machine principal used Control Access with DS-Replication-Get-Changes rights; lower suspicion only when the same stable SID and controller match one recognized directory-replication connector or AD backup/recovery job.
- Do the 4662 object-access details show domain-wide replication or access to especially sensitive naming contexts?
- Why: DCSync stands out when the event shows replication extended rights plus access to the domain root or other high-value directory objects.
- Focus: `winlog.event_data.Properties`, `winlog.event_data.AccessMask`, `winlog.event_data.ObjectName`, and `winlog.event_data.ObjectType`.
- Hint: treat the domain naming context or root DN, such as `DC=corp,DC=example,DC=com`, as broader and higher risk; interpret Configuration, DomainDNSZones, ForestDNSZones, or specific object paths against the exact connector or job workflow before lowering severity.
- Implication: escalate on broad domain naming-context, high-value object, or DS-Replication-Get-Changes-All / In-Filtered-Set scope because the request can expose domain secrets; lower suspicion only when the same rights and object scope fit the exact connector workflow from step 1.
- Does the subject logon session resolve to another domain controller or an unexpected source system?
- Focus: match `winlog.event_data.SubjectLogonId` to 4624 `winlog.event_data.TargetLogonId` on the same `host.id`, then read `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`. $investigate_0
- Range: search backward from `@timestamp` on the same `host.id` because the session-creating 4624 can predate the 4662 by minutes or hours.
- Hint: if the linked 4624 is missing or `source.ip` is absent, preserve `winlog.event_data.SubjectLogonId`, `winlog.computer_name`, and `@timestamp`. Missing authentication telemetry is unresolved, not benign.
- Implication: escalate when the session originates from a workstation, member server, rare admin host, or a DC interactive / remote-interactive logon; lower suspicion when the 4624 source, logon type, and auth package match recognized replication infrastructure.
- Do surrounding authentication events show explicit-credential use or a session pattern that does not fit routine replication?
- Why: stolen or relayed credentials often leave 4624 or 4648 context riskier than the 4662 event alone.
- Focus: linked 4624 events where `winlog.event_data.TargetLogonId` matches the alerted `winlog.event_data.SubjectLogonId`, plus 4648 events for the same session; read `source.ip`, `winlog.logon.type`, `winlog.event_data.AuthenticationPackageName`, and `winlog.event_data.TargetServerName`.
- Hint: 4648 means credentials were presented, not that the replication succeeded; missing linked authentication telemetry is unresolved, not benign.
- Implication: escalate when the subject shows new remote-interactive or network sessions from unusual origins, explicit credentials for the alerted account or controller, or NTLM where the workflow normally uses Kerberos.
- Did surrounding directory-object changes or related 4662 activity show how the account obtained or expanded replication rights?
- Focus: surrounding 4662 activity for `winlog.event_data.SubjectUserSid`, plus 5136 changes using `winlog.event_data.ObjectDN`, `winlog.event_data.AttributeLDAPDisplayName`, `winlog.event_data.AttributeValue`, and `winlog.event_data.OpCorrelationID`. $investigate_1
- Hint: group related 5136 records by `winlog.event_data.OpCorrelationID`; if 5136 visibility is absent, preserve the gap and answer from surrounding 4662 activity.
- Implication: escalate when 5136 shows recent ACL or delegation changes granting DS-Replication-Get-Changes rights to the subject or its groups, when another grantor touched sensitive delegation or domain-level objects, or when privileged 4662 access appears on multiple controllers.
- If local evidence is still suspicious, did the same subject or replication-right scope touch other controllers?
- Focus: Windows Security 4662 and 5136 records for `winlog.event_data.SubjectUserSid` and `winlog.event_data.Properties`, grouped by `winlog.computer_name` and `winlog.event_data.ObjectName`.
- Range: start with the surrounding window, then expand only if the local subject, source, or rights scope remains suspicious.
- Implication: escalate domain-wide when the same subject or rights scope appears on multiple controllers or directory objects; keep scope local when only this controller shows activity, but do not close unresolved DCSync evidence from absence alone.
- Based on the evidence gathered, what disposition is supported?
- Focus: identity, replication scope, session origin, authentication pattern, directory-rights changes, and controller spread.
- Implication: escalate when those categories show an unrecognized subject, broad scope, unexpected source, explicit-credential use, or privilege changes; close only when alert-local evidence plus supported recovery tightly bind one exact directory-replication connector or AD backup/recovery job, with outside confirmation when telemetry alone cannot prove legitimacy; preserve and escalate if evidence is mixed or incomplete.
### False positive analysis
- Directory-replication connectors and AD backup/recovery jobs can legitimately trigger this rule. Confirm only when `winlog.event_data.SubjectUserSid`, `winlog.event_data.Properties`, `winlog.event_data.ObjectName`, recovered 4624 `source.ip`, and `winlog.computer_name` align to one exact connector or job run. For backup/recovery tooling, require 5136 or owner/product evidence that the activity was tool-driven rather than hands-on operator behavior. If telemetry cannot prove the workflow, require outside confirmation for that exact run; do not close from prior-alert recurrence alone.
- Build exceptions from the minimum confirmed workflow: stable `winlog.event_data.SubjectUserSid`, recovered 4624 `source.ip`, `winlog.event_data.Properties`, `winlog.event_data.ObjectName`, and `winlog.computer_name`, plus the specific product or connector identity that explains the access. Avoid exceptions on `winlog.event_data.SubjectUserName` alone, broad replication-right strings, or "first benign occurrence" claims without exact workflow confirmation.
### Response and remediation
- If confirmed benign, reverse temporary containment and document the exact evidence that validated the directory-replication connector or AD backup/recovery job: subject SID, connector source, replication rights, object scope, controller, and confirming product or owner record. Create an exception only from those same workflow anchors.
- If suspicious but unconfirmed, preserve a case export containing the triggering 4662 event, linked 4624/4648 authentication records, recovered `source.ip`, replication rights/object fields, and any 5136 delegation-change records before containment. Apply reversible containment first, such as temporarily blocking the recovered `source.ip` from reaching domain controllers or isolating the unexpected non-domain-controller source host when its role tolerates isolation. Escalate to broader account disablement or host isolation only if credential-theft, relay, or privilege-change evidence appears.
- If confirmed malicious, use endpoint or identity-response tooling to isolate the unexpected source host and disable or reset the implicated account. If direct response is unavailable, escalate with the same artifact set to the AD or incident-response team. Record all preserved evidence before terminating processes, revoking access, or removing delegated rights.
- If confirmed malicious activity included broad domain scope in `winlog.event_data.ObjectName` or `winlog.event_data.ObjectType`, hand off to the AD incident-response team with the preserved evidence before privileged-account resets or delegated-rights cleanup.
- Review other controllers and sync hosts for the same `winlog.event_data.SubjectUserSid`, `source.ip`, and `winlog.event_data.Properties` before removing delegated rights or cleaning up changes.
- Eradicate only the unauthorized replication-right delegation or directory changes identified during the investigation: remove "DS-Replication-Get-Changes*" grants, restore modified directory objects or ACLs, and remediate the path that let the subject obtain replication capability.
- Post-incident hardening: restrict replication rights to authorized service accounts and sync hosts, retain Security 4662, 4624, 4648, and 5136 coverage on controllers, and document any uncovered variant or logging gap in the incident record for follow-up ownership.
"""
setup = """## Setup
Audit Directory Service Access must be enabled to generate the events used by this rule.
Setup instructions: https://ela.st/audit-directory-service-access
"""
[rule.investigation_fields]
field_names = [
"@timestamp",
"host.id",
"winlog.computer_name",
"winlog.event_data.SubjectUserName",
"winlog.event_data.SubjectUserSid",
"winlog.event_data.SubjectDomainName",
"winlog.event_data.SubjectLogonId",
"winlog.event_data.ObjectName",
"winlog.event_data.ObjectType",
"winlog.event_data.Properties",
"winlog.event_data.AccessMask",
"winlog.event_data.OpCorrelationID",
]
[[transform.investigate]]
label = "Authentication events for the subject logon session"
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 = "winlog.event_data.TargetLogonId", queryType = "phrase", value = "{{winlog.event_data.SubjectLogonId}}", 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 = "winlog.event_data.SubjectLogonId", queryType = "phrase", value = "{{winlog.event_data.SubjectLogonId}}", valueType = "string" }
]
]
relativeFrom = "now-24h"
relativeTo = "now"
[[transform.investigate]]
label = "Directory replication and rights events for the subject"
description = ""
providers = [
[
{ excluded = false, field = "event.code", queryType = "phrase", value = "4662", valueType = "string" },
{ excluded = false, field = "winlog.event_data.SubjectUserSid", queryType = "phrase", value = "{{winlog.event_data.SubjectUserSid}}", valueType = "string" },
{ excluded = false, field = "winlog.event_data.Properties", queryType = "phrase", value = "DS-Replication-Get-Changes", valueType = "string" }
],
[
{ excluded = false, field = "event.code", queryType = "phrase", value = "4662", valueType = "string" },
{ excluded = false, field = "winlog.event_data.SubjectUserSid", queryType = "phrase", value = "{{winlog.event_data.SubjectUserSid}}", valueType = "string" },
{ excluded = false, field = "winlog.event_data.Properties", queryType = "phrase", value = "DS-Replication-Get-Changes-All", valueType = "string" }
],
[
{ excluded = false, field = "event.code", queryType = "phrase", value = "4662", valueType = "string" },
{ excluded = false, field = "winlog.event_data.SubjectUserSid", queryType = "phrase", value = "{{winlog.event_data.SubjectUserSid}}", valueType = "string" },
{ excluded = false, field = "winlog.event_data.Properties", queryType = "phrase", value = "DS-Replication-Get-Changes-In-Filtered-Set", valueType = "string" }
],
[
{ excluded = false, field = "event.code", queryType = "phrase", value = "4662", valueType = "string" },
{ excluded = false, field = "winlog.event_data.SubjectUserSid", queryType = "phrase", value = "{{winlog.event_data.SubjectUserSid}}", valueType = "string" },
{ excluded = false, field = "winlog.event_data.Properties", queryType = "phrase", value = "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2", valueType = "string" }
],
[
{ excluded = false, field = "event.code", queryType = "phrase", value = "4662", valueType = "string" },
{ excluded = false, field = "winlog.event_data.SubjectUserSid", queryType = "phrase", value = "{{winlog.event_data.SubjectUserSid}}", valueType = "string" },
{ excluded = false, field = "winlog.event_data.Properties", queryType = "phrase", value = "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2", valueType = "string" }
],
[
{ excluded = false, field = "event.code", queryType = "phrase", value = "4662", valueType = "string" },
{ excluded = false, field = "winlog.event_data.SubjectUserSid", queryType = "phrase", value = "{{winlog.event_data.SubjectUserSid}}", valueType = "string" },
{ excluded = false, field = "winlog.event_data.Properties", queryType = "phrase", value = "89e95b76-444d-4c62-991a-0facbeda640c", valueType = "string" }
],
[
{ excluded = false, field = "event.code", queryType = "phrase", value = "5136", valueType = "string" },
{ excluded = false, field = "winlog.event_data.SubjectUserSid", queryType = "phrase", value = "{{winlog.event_data.SubjectUserSid}}", valueType = "string" }
]
]
relativeFrom = "now-24h"
relativeTo = "now"
[rule.new_terms]
field = "new_terms_fields"
value = ["winlog.event_data.SubjectUserName"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-15d"
[[rule.threat]]
framework = "MITRE ATT&CK"
@@ -115,12 +209,11 @@ id = "T1003.006"
name = "DCSync"
reference = "https://attack.mitre.org/techniques/T1003/006/"
[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
@@ -132,18 +225,7 @@ id = "T1078.002"
name = "Domain Accounts"
reference = "https://attack.mitre.org/techniques/T1078/002/"
[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"
[rule.new_terms]
field = "new_terms_fields"
value = ["winlog.event_data.SubjectUserName"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-15d"
rules/windows/credential_access_dollar_account_relay_kerberos.toml
+134 -40
View File
@@ -2,57 +2,21 @@
creation_date = "2025/06/18"
integration = ["system", "windows"]
maturity = "production"
updated_date = "2026/03/24"
updated_date = "2026/04/22"
[rule]
author = ["Elastic"]
description = """
Detects potential relay attacks by identifying coercion attempts followed by authentication events using a target
server's computer account, originating from a different host. This may indicate that an attacker has captured and
relayed the server's computer account hash to execute code on behalf of the compromised system.
relayed Kerberos authentication material for the server's computer account to execute code on behalf of the
compromised system.
"""
from = "now-9m"
index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
language = "eql"
license = "Elastic License v2"
name = "Potential Kerberos Relay Attack against a Computer Account"
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 Kerberos Relay Attack against a Computer Account
### Possible investigation steps
- Compare the source.ip to the target server host.ip addresses to make sure it's indeed a remote use of the machine account.
- Examine the source.ip activities as this is the attacker IP address used to relay.
- Review all relevant activities such as services creation, file and process events on the target server within the same period.
- Verify the machine account names that end with a dollar sign ($) to ensure they match the expected hostnames, and investigate any discrepancies.
- Check the network logon types to confirm if they align with typical usage patterns for the identified machine accounts.
- Investigate the context of the source IP addresses that do not match the host IP, looking for any signs of unauthorized access or unusual network activity.
- Correlate the findings with other security logs and alerts to identify any patterns or additional indicators of compromise related to the potential relay attack.
### False positive analysis
- Machine accounts performing legitimate network logons from different IP addresses can trigger false positives. To manage this, identify and whitelist known IP addresses associated with legitimate administrative tasks or automated processes.
- Scheduled tasks or automated scripts that use machine accounts for network operations may be flagged. Review and document these tasks, then create exceptions for their associated IP addresses and hostnames.
- Load balancers or proxy servers that alter the source IP address of legitimate authentication requests can cause false alerts. Ensure these devices are accounted for in the network architecture and exclude their IP addresses from the rule.
- Temporary network reconfigurations or migrations might result in machine accounts appearing to log in from unexpected hosts. During such events, temporarily adjust the rule parameters or disable the rule to prevent unnecessary alerts.
- Regularly review and update the list of exceptions to ensure they reflect current network configurations and operational practices, minimizing the risk of overlooking genuine threats.
### 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 involved server is a Domain Controller, coordinate the isolation of the server with infrastructure and identity teams to contain the threat while preserving service availability and forensic evidence. Prioritize this step if active compromise or attacker persistence is confirmed.- Reset the domain controller's machine account password, along with any accounts suspected to be compromised or exposed. Ensure strong, unique credentials are used and apply tiered credential hygiene where applicable.
- Reset the domain controller's machine account password, along with any accounts suspected to be compromised or exposed. Ensure strong, unique credentials are used and apply tiered credential hygiene where applicable.
- Analyze recent authentication logs, event logs, and network traffic, focusing on suspicious activity and the source IPs referenced in the alert. Correlate findings to identify any lateral movement or additional compromised systems.
- Strengthen network segmentation, especially between domain controllers, administrative workstations, and critical infrastructure. This limits the attack surface and impedes credential relay or reuse across systems.
- Escalate the incident to the SOC or incident response team to coordinate a full investigation, containment, and recovery plan. Ensure stakeholders are kept informed throughout the response.
- Enhance detection mechanisms by tuning alerts and deploying additional telemetry focused on credential relay patterns, anomalous authentication, and NTLM-related activity.
- Conduct a structured post-incident review, documenting findings, identifying control gaps, and updating playbooks, configurations, or security policies to reduce the likelihood of similar incidents in the future.
"""
references = [
"https://github.com/p0dalirius/windows-coerced-authentication-methods",
"https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications",
@@ -70,7 +34,6 @@ tags = [
"OS: Windows",
"Use Case: Threat Detection",
"Tactic: Credential Access",
"Data Source: Elastic Defend",
"Data Source: Active Directory",
"Use Case: Active Directory Monitoring",
"Data Source: Windows Security Event Logs",
@@ -103,6 +66,137 @@ sequence by winlog.computer_name, source.ip with maxspan=5s
source.ip != null and source.ip != "::1" and source.ip != "127.0.0.1"]
'''
note = """## Triage and analysis
### Investigating Potential Kerberos Relay Attack against a Computer Account
#### Possible investigation steps
- What do the recovered source events prove about the relay sequence?
- Why: Kerberos relay can reuse a coerced machine-account ticket when SPN selection or service protections allow it; reflective variants keep the same triage anchors: recovered pipe, `source.ip`, target dollar account, and Kerberos network auth.
- Hint: Open Investigate in Timeline before interpreting the grouped alert; filter the alert window to `event.code` 5145 and 4624/4625 with the same `winlog.computer_name` and `source.ip`. In this step, read `file.name` from the recovered 5145 source event. If endpoint file telemetry is available for this host and time window, recover the matching `file.*` evidence before using it for interpretation or remediation. Treat it as optional corroboration, not the alert source.
- Focus: recovered 5145 and 4624/4625 source events scoped by `winlog.computer_name`, `source.ip`, and `@timestamp`; in the 5145 event read `file.name` as the named-pipe value, then in the auth event read `winlog.event_data.AuthenticationPackageName`, `winlog.logon.type`, and `host.ip`.
- Implication: escalate when a known coercion pipe such as Spoolss, netdfs, lsarpc, efsrpc, netlogon, srvsvc, or winreg is followed within seconds by a Kerberos network logon from the same non-target `source.ip`; lower suspicion only when the recovered pipe/auth outcome recurs for the same source, server, and machine account and outside topology or owner evidence verifies that exact infrastructure role.
- Does the authenticated machine account belong to the target server?
- Focus: `winlog.event_data.TargetUserName` dollar-account prefix and `winlog.event_data.TargetDomainName` from the auth source event compared with `winlog.computer_name`.
- Implication: escalate when the target account is the target server's dollar account and the source is not the server itself; if the account does not map to the target server, resolve whether the sequence paired unrelated events before using the alert for closure or escalation.
- Did the Kerberos authentication create a usable session or only a failed attempt?
- Focus: auth source-event `event.code`, `winlog.event_data.Status`, `winlog.event_data.SubStatus`, `winlog.event_data.TargetLogonId`, and `source.ip`.
- Implication: prioritize confirmed compromise review when a 4624 produces a `winlog.event_data.TargetLogonId`; keep failed-only 4625 sequences suspicious when the source or pipe is unexplained, but lower urgency when the status pattern is a recurring, bounded failure from recognized infrastructure.
- Does the source IP fit recognized infrastructure or relay-characteristic behavior?
- Focus: surrounding Windows Security authentication events for `source.ip` and `winlog.computer_name`, reading `winlog.event_data.TargetUserName`, `winlog.event_data.AuthenticationPackageName`, `winlog.logon.type`, `winlog.event_data.Status`, and `winlog.event_data.SubStatus`.
- Hint: use same-source authentication events to see whether the source targets multiple machine accounts or alternates Kerberos successes and failures around the alert. $investigate_2
- Implication: escalate when the source is rare for this server, targets multiple machine accounts, or alternates Kerberos successes and failures outside a verified infrastructure role; missing surrounding authentication telemetry is unresolved, not benign. Lower suspicion only when the same bounded source/server/account/outcome pattern recurs and outside topology or owner evidence verifies the exact role.
- If local evidence is suspicious or unresolved, is this part of broader relay activity?
- Focus: related alerts for `source.ip` that show additional coercion or machine-account Kerberos relay. $investigate_0
- Hint: pivot target-server related alerts for service creation, persistence, or remote execution only when the source pivot is suspicious; missing related alerts narrows existing-alert scope only, not host activity. $investigate_1
- Hint: for raw Windows Security scoping after a 4624, review follow-on Windows Security events on the same `winlog.computer_name` where `winlog.event_data.SubjectLogonId` matches the recovered `winlog.event_data.TargetLogonId`; filter within results for service creation, task creation, share access, or persistence if the result set is large. Missing follow-on events is unresolved unless that event coverage is confirmed. $investigate_3
- Implication: expand scope when source history shows other coercion or machine-account Kerberos relay, or when target history shows follow-on service, persistence, or remote-execution alerts; keep containment local only when related alerts stay limited to the same explained infrastructure tuple.
- Based on the recovered evidence, what disposition is supported?
- Focus: sequence integrity, target dollar-account identity, Kerberos outcome, source-fit tuple, and related-alert results.
- Implication: escalate when the sequence is intact and unexplained, when successful machine-account Kerberos comes from an unrecognized source, or when related-alert evidence shows follow-on abuse; close only when recovered source events and supported recovery bind one exact recognized infrastructure workflow with no contradictory evidence; preserve and escalate when evidence conflicts or visibility is missing.
### False positive analysis
- Validated infrastructure peers or authorized relay/coercion testing are the narrow benign paths. Confirm by verifying the recovered source events align on the same `source.ip`, `winlog.computer_name`, target machine account in `winlog.event_data.TargetUserName`, Kerberos `winlog.event_data.AuthenticationPackageName`, network `winlog.logon.type`, bounded `winlog.event_data.Status`/`winlog.event_data.SubStatus`, and recovered pipe evidence for the same server/account/pipe/outcome tuple. If telemetry cannot explain the specific pipe, account, and outcome, do not close as benign.
- Use topology, owner, or test-plan confirmation only to verify the exact recovered tuple after source-event recovery. Before creating an exception, validate recurrence across prior alerts from this rule for the same source/server/account/pipe/outcome pattern. If this is the first confirmed benign occurrence, document it as a candidate exception and monitor before suppressing. Build exceptions from the full confirmed workflow pattern; avoid exceptions on `source.ip`, `winlog.computer_name`, or machine-account name alone.
### Response and remediation
- If confirmed benign, reverse any temporary containment and document the evidence that proved the workflow: `source.ip`, `winlog.computer_name`, target machine account, Kerberos network auth, bounded `winlog.event_data.Status`/`winlog.event_data.SubStatus`, and recovered pipe evidence. Create an exception only after the same full pattern recurs across prior alerts from this rule.
- If suspicious but unconfirmed, preserve the alert export, Timeline source events, recovered pipe evidence, target machine-account identity, auth outcome, session identifier when present, and related-alert results before containment. Use reversible containment first: temporarily restrict SMB/RPC between `source.ip` and the affected server, or isolate the source host when its role tolerates isolation. Escalate to broader host or account action only if follow-on service, persistence, execution, or wider relay evidence appears.
- If confirmed malicious, preserve the same alert export, Timeline source events, recovered pipe evidence, target machine-account identity, auth outcome, session identifier when present, and related-alert results before action. Then contain the source host and restrict access to the affected `winlog.computer_name`; if direct containment is unavailable, hand off the preserved evidence set to the team that can act. Remove the coercion route, block the offending source path, and eradicate only services, scheduled tasks, dropped tools, or configuration changes confirmed during response.
- Rotate the affected computer-account secret and review adjacent delegated, service, or administrative credentials that could have been exposed through the relay path. Coordinate disruptive credential or host actions with identity and infrastructure owners when the target is a domain controller, cluster node, or other critical service.
- After containment, audit other servers reached from the same `source.ip` and retain Windows Security source events needed to reconstruct each source/server/account/pipe sequence.
- Post-incident hardening: before releasing containment for a reflective Kerberos relay path, validate the relevant CVE-2025-33073 fixes and SMB signing or service-specific signing/sealing/channel binding on the affected service tier. Restrict coercion-prone RPC and named-pipe exposure, then document the confirmed source/server/account/pipe pattern for future analysts and control owners.
"""
setup = """## Setup
The following Windows audit policies must be enabled to generate the events used by this rule:
- [Audit Logon](https://ela.st/audit-logon)
- [Audit Detailed File Share](https://ela.st/audit-detailed-file-share)
"""
[rule.investigation_fields]
field_names = [
"@timestamp",
"event.code",
"winlog.computer_name",
"source.ip",
"host.ip",
"user.name",
"file.name",
"winlog.event_data.TargetUserName",
"winlog.event_data.TargetDomainName",
"winlog.event_data.AuthenticationPackageName",
"winlog.logon.type",
"winlog.event_data.Status",
"winlog.event_data.SubStatus",
"winlog.event_data.TargetLogonId",
"winlog.event_data.SubjectLogonId",
]
[[transform.investigate]]
label = "Alerts associated with this source IP"
description = ""
providers = [
[
{ excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
{ excluded = false, field = "source.ip", queryType = "phrase", value = "{{source.ip}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[transform.investigate]]
label = "Alerts associated with this target server"
description = ""
providers = [
[
{ excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
{ excluded = false, field = "winlog.computer_name", queryType = "phrase", value = "{{winlog.computer_name}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[transform.investigate]]
label = "Authentication events from this source to this target"
description = ""
providers = [
[
{ excluded = false, field = "winlog.computer_name", queryType = "phrase", value = "{{winlog.computer_name}}", valueType = "string" },
{ excluded = false, field = "source.ip", queryType = "phrase", value = "{{source.ip}}", valueType = "string" },
{ excluded = false, field = "event.code", queryType = "phrase", value = "4624", valueType = "string" },
{ excluded = false, field = "winlog.event_data.AuthenticationPackageName", queryType = "phrase", value = "Kerberos", valueType = "string" }
],
[
{ excluded = false, field = "winlog.computer_name", queryType = "phrase", value = "{{winlog.computer_name}}", valueType = "string" },
{ excluded = false, field = "source.ip", queryType = "phrase", value = "{{source.ip}}", valueType = "string" },
{ excluded = false, field = "event.code", queryType = "phrase", value = "4625", valueType = "string" },
{ excluded = false, field = "winlog.event_data.AuthenticationPackageName", queryType = "phrase", value = "Kerberos", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "Follow-on Windows Security events for the Kerberos logon session"
description = ""
providers = [
[
{ excluded = false, field = "winlog.computer_name", queryType = "phrase", value = "{{winlog.computer_name}}", valueType = "string" },
{ excluded = false, field = "winlog.event_data.SubjectLogonId", queryType = "phrase", value = "{{winlog.event_data.TargetLogonId}}", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[rule.threat]]
framework = "MITRE ATT&CK"
rules/windows/credential_access_dollar_account_relay_ntlm.toml
+145 -44
View File
@@ -2,7 +2,7 @@
creation_date = "2025/06/18"
integration = ["system", "windows"]
maturity = "production"
updated_date = "2025/10/17"
updated_date = "2026/04/22"
[rule]
author = ["Elastic"]
@@ -16,49 +16,10 @@ index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
language = "eql"
license = "Elastic License v2"
name = "Potential NTLM Relay Attack against a Computer Account"
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 NTLM Relay Attack against a Computer Account
### Possible investigation steps
- Compare the source.ip to the target server host.ip addresses to make sure it's indeed a remote use of the machine account.
- Examine the source.ip activities as this is the attacker IP address used to relay.
- Review all relevant activities such as services creation, file and process events on the target server within the same period.
- Verify the machine account names that end with a dollar sign ($) to ensure they match the expected hostnames, and investigate any discrepancies.
- Check the network logon types to confirm if they align with typical usage patterns for the identified machine accounts.
- Investigate the context of the source IP addresses that do not match the host IP, looking for any signs of unauthorized access or unusual network activity.
- Correlate the findings with other security logs and alerts to identify any patterns or additional indicators of compromise related to the potential relay attack.
### False positive analysis
- Machine accounts performing legitimate network logons from different IP addresses can trigger false positives. To manage this, identify and whitelist known IP addresses associated with legitimate administrative tasks or automated processes.
- Scheduled tasks or automated scripts that use machine accounts for network operations may be flagged. Review and document these tasks, then create exceptions for their associated IP addresses and hostnames.
- Load balancers or proxy servers that alter the source IP address of legitimate authentication requests can cause false alerts. Ensure these devices are accounted for in the network architecture and exclude their IP addresses from the rule.
- Temporary network reconfigurations or migrations might result in machine accounts appearing to log in from unexpected hosts. During such events, temporarily adjust the rule parameters or disable the rule to prevent unnecessary alerts.
- Regularly review and update the list of exceptions to ensure they reflect current network configurations and operational practices, minimizing the risk of overlooking genuine threats.
### 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 involved server is a Domain Controller, coordinate the isolation of the server with infrastructure and identity teams to contain the threat while preserving service availability and forensic evidence. Prioritize this step if active compromise or attacker persistence is confirmed.- Reset the domain controller's machine account password, along with any accounts suspected to be compromised or exposed. Ensure strong, unique credentials are used and apply tiered credential hygiene where applicable.
- Analyze recent authentication logs, event logs, and network traffic, focusing on suspicious activity and the source IPs referenced in the alert. Correlate findings to identify any lateral movement or additional compromised systems.
- Strengthen network segmentation, especially between domain controllers, administrative workstations, and critical infrastructure. This limits the attack surface and impedes credential relay or reuse across systems.
- Escalate the incident to the SOC or incident response team to coordinate a full investigation, containment, and recovery plan. Ensure stakeholders are kept informed throughout the response.
- Enhance detection mechanisms by tuning alerts and deploying additional telemetry focused on credential relay patterns, anomalous authentication, and NTLM-related activity.
- Conduct a structured post-incident review, documenting findings, identifying control gaps, and updating playbooks, configurations, or security policies to reduce the likelihood of similar incidents in the future.
"""
references = [
"https://github.com/p0dalirius/windows-coerced-authentication-methods",
"https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications",
"https://www.synacktiv.com/publications/ntlm-reflection-is-dead-long-live-ntlm-reflection-an-in-depth-analysis-of-cve-2025",
"https://blog.redteam-pentesting.de/2025/reflective-kerberos-relay-attack/",
"https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html",
"https://github.com/CICADA8-Research/RemoteKrbRelay/blob/main/README.md",
"https://github.com/Orange-Cyberdefense/ocd-mindmaps/blob/main/excalimap/mindmap/ad/authenticated.md",
]
risk_score = 73
@@ -69,7 +30,6 @@ tags = [
"OS: Windows",
"Use Case: Threat Detection",
"Tactic: Credential Access",
"Data Source: Elastic Defend",
"Data Source: Active Directory",
"Use Case: Active Directory Monitoring",
"Data Source: Windows Security Event Logs",
@@ -102,6 +62,150 @@ sequence by winlog.computer_name, source.ip with maxspan=5s
source.ip != null and source.ip != "::1" and source.ip != "127.0.0.1"]
'''
note = """## Triage and analysis
### Investigating Potential NTLM Relay Attack against a Computer Account
#### Possible investigation steps
- What source events make up the sequence, and do they support a coercion-to-NTLM path?
- Focus: open Timeline from the sequence alert and recover member events for the alert `host.id` or `host.name` plus `source.ip`; compare source-event `winlog.computer_name`, 5145 `file.name`, `winlog.event_data.TargetUserName`, `winlog.event_data.AuthenticationPackageName`, and `winlog.logon.type`.
- Hint: use the recovered 5145 Windows Security source event as the primary pipe evidence. If endpoint file telemetry is available for this host and time window, recover the matching `file.*` evidence before using it for interpretation or remediation.
- Implication: escalate when a coercion-style pipe such as Spoolss, netdfs, efsrpc, FssagentRpc, lsarpc, netlogon, samr, srvsvc, winreg, dnsserver, or WinsPipe is followed within seconds by a type 3 NTLM machine-account logon from the same source; lower concern when the recovered pair matches a recurring proxy, cluster, backup, or management path with the same pipe and auth pattern; close as a non-hit only when source events break the sequence or do not share the same source and target.
- Did the authentication stage succeed, fail, or show weak NTLM handling?
- Focus: auth-stage `event.code`, `winlog.event_data.Status`, `winlog.event_data.SubStatus`, `winlog.event_data.LmPackageName`, and `winlog.event_data.AuthenticationPackageName`.
- Implication: urgent escalation is warranted for a 4624 success, success-after-failure pattern, or NTLMv1/weak `winlog.event_data.LmPackageName`; failure-only 4625 activity still supports attempted coercion when the recovered pipe event and source path hold.
- Does the authenticated machine account belong to the target server?
- Focus: auth-stage `winlog.event_data.TargetUserName` and `winlog.event_data.TargetDomainName` compared with `winlog.computer_name`, `host.name`, and `host.id`.
- Implication: target-name alignment plus a dollar-suffixed machine account supports relayed or reflected computer-account use; a different host, alias, or cluster identity is an identity mismatch to resolve before disposition, not a benign conclusion by itself.
- Does the source fit a recognized SMB/RPC infrastructure path for this server?
- Focus: surrounding Windows Security events for the same target, source, and machine account, checking `winlog.event_data.TargetUserName`, `winlog.event_data.AuthenticationPackageName`, `winlog.event_data.LmPackageName`, `winlog.event_data.Status`, and `winlog.event_data.SubStatus`.
- Hint: use same-source NTLM authentication events to review repeated machine-account logons, success-after-failure patterns, and weak `LmPackageName` values around the alert. $investigate_2
- Implication: escalate when the source is rare for this server, targets multiple machine accounts, or drives burst failures followed by success; lower concern only when the same source/server/account/auth pattern recurs as a recognized proxy, load-balancer, cluster, backup, or management path. Missing Windows Security history leaves source fit unresolved, not benign.
- Did the same source perform follow-on Windows Security activity after the relay pair?
- Focus: post-sequence Windows Security events on the same target and source, especially `event.code` 5145, 4624, or 4625 plus `winlog.event_data.TargetUserName`, `winlog.event_data.Status`, and `winlog.event_data.SubStatus`.
- Hint: review same-source follow-on Windows Security events for repeated share or pipe access and repeated machine-account logons after the sequence. $investigate_3
- Implication: escalate when the source keeps accessing shares or pipes or repeats machine-account logons after the relay window; absence of follow-on Windows Security events reduces observed scope but does not prove benign execution did not occur.
- If local evidence is suspicious or unresolved, does related alert scope change urgency?
- Focus: related source-IP alerts for `source.ip`, especially other coercion, machine-account NTLM, service creation, or remote-execution signals. $investigate_0
- Hint: if source scope remains unclear, check related target-server alerts for the alert `host.id`. $investigate_1
- Implication: broaden response when the same source or target shows related relay or execution alerts; keep the case locally scoped when related alerts add no new source, target, or follow-on evidence.
- Based on sequence integrity, auth result, identity, source fit, follow-through, and scope, what disposition is supported?
- Focus: recovered source events, machine-account identity, NTLM handling, recognized infrastructure fit, follow-on Windows Security events, and related-alert scope.
- Implication: escalate when the recovered sequence holds and the source is unrecognized, successful, weakly protected, or followed by further access; close only when recovered evidence and supported context bind one exact workflow on this host, with outside confirmation when telemetry cannot prove legitimacy; preserve evidence and escalate when results are mixed or visibility is limited.
### False positive analysis
- Clustered file services, SMB/RPC proxies, backup controllers, or management tiers can legitimately front machine-account NTLM traffic through bounded SMB/RPC paths. Confirm by verifying the same `source.ip`, `winlog.computer_name`, `winlog.event_data.TargetUserName`, `winlog.event_data.AuthenticationPackageName`, `winlog.event_data.LmPackageName`, status pattern, 5145 named-pipe/share object, and lack of suspicious follow-on `event.code` activity all converge on the same workflow. If workflow records are unavailable, require historical recurrence of that exact telemetry pattern before closing.
- Before creating an exception, validate recurrence across prior alerts from this rule for the same `source.ip`, `winlog.computer_name`, machine account, NTLM package/version, and 5145 object family. Build the exception from the minimum confirmed workflow pattern; avoid exceptions on source IP alone, target server alone, or dollar-suffixed machine-account names alone.
### Response and remediation
- If confirmed benign, reverse temporary containment and document the exact `source.ip`, `winlog.computer_name`, `winlog.event_data.TargetUserName`, `winlog.event_data.AuthenticationPackageName`, `winlog.event_data.LmPackageName`, `winlog.event_data.Status` or `winlog.event_data.SubStatus`, and 5145 object pattern that proved the workflow. Create a narrow exception only after recurrence proves the same telemetry pattern.
- If suspicious but unconfirmed, preserve the alert document, Timeline member events, recovered 5145 object, authentication result, NTLM package/version, source and target identifiers, status values, and any follow-on Windows Security records before containment. Use reversible containment first, such as temporarily blocking the recovered source from SMB/RPC access to the affected server or isolating the unexpected source host when its role tolerates isolation.
- If confirmed malicious, keep the preserved evidence set attached to the case, then isolate or block the source host and restrict its SMB/RPC access to the affected `winlog.computer_name`. Eradicate only confirmed follow-on services, tasks, shares, or relay tooling identified during investigation; coordinate disruptive actions on domain controllers, cluster nodes, and production servers with identity and infrastructure owners.
- Rotate the affected computer-account secret only after evidence preservation and service-impact review, then review delegated or administrative credentials that could have been exposed or reused through the relayed session. Reduce NTLM exposure, enforce SMB signing and Extended Protection for Authentication where applicable, and disable unneeded coercion-prone RPC services on the affected tier.
- After containment, audit other servers reached from the same `source.ip` and retain the Windows Security telemetry needed to reconstruct the 5145-to-4624/4625 sequence. Document any reflection-style or marshaled-target variant indicators for future case comparison.
"""
setup = """## Setup
The following Windows audit policies must be enabled to generate the events used by this rule:
- [Audit Logon](https://ela.st/audit-logon)
- [Audit Detailed File Share](https://ela.st/audit-detailed-file-share)
"""
[rule.investigation_fields]
field_names = [
"@timestamp",
"event.code",
"host.id",
"host.name",
"host.ip",
"source.ip",
"winlog.computer_name",
"file.name",
"winlog.event_data.TargetUserName",
"winlog.event_data.TargetDomainName",
"winlog.event_data.AuthenticationPackageName",
"winlog.event_data.LmPackageName",
"winlog.logon.type",
"winlog.event_data.Status",
"winlog.event_data.SubStatus",
]
[[transform.investigate]]
label = "Alerts associated with this source IP"
description = ""
providers = [
[
{ excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
{ excluded = false, field = "source.ip", queryType = "phrase", value = "{{source.ip}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[transform.investigate]]
label = "Alerts associated with this target server"
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 = "NTLM authentication events from this source to this target"
description = ""
providers = [
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "source.ip", queryType = "phrase", value = "{{source.ip}}", valueType = "string" },
{ excluded = false, field = "event.code", queryType = "phrase", value = "4624", valueType = "string" },
{ excluded = false, field = "winlog.event_data.AuthenticationPackageName", queryType = "phrase", value = "NTLM", valueType = "string" }
],
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "source.ip", queryType = "phrase", value = "{{source.ip}}", valueType = "string" },
{ excluded = false, field = "event.code", queryType = "phrase", value = "4625", valueType = "string" },
{ excluded = false, field = "winlog.event_data.AuthenticationPackageName", queryType = "phrase", value = "NTLM", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "Follow-on Windows Security events from this source to this target"
description = ""
providers = [
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "source.ip", queryType = "phrase", value = "{{source.ip}}", valueType = "string" },
{ excluded = false, field = "event.code", queryType = "phrase", value = "5145", valueType = "string" }
],
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "source.ip", queryType = "phrase", value = "{{source.ip}}", 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 = "source.ip", queryType = "phrase", value = "{{source.ip}}", valueType = "string" },
{ excluded = false, field = "event.code", queryType = "phrase", value = "4625", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[rule.threat]]
framework = "MITRE ATT&CK"
@@ -119,10 +223,7 @@ id = "T1557.001"
name = "LLMNR/NBT-NS Poisoning and SMB Relay"
reference = "https://attack.mitre.org/techniques/T1557/001/"
[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"
rules/windows/credential_access_domain_backup_dpapi_private_keys.toml
+177 -5
View File
@@ -2,7 +2,7 @@
creation_date = "2020/08/13"
integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defender", "crowdstrike"]
maturity = "production"
updated_date = "2026/04/07"
updated_date = "2026/04/22"
[rule]
author = ["Elastic"]
@@ -23,10 +23,6 @@ index = [
language = "eql"
license = "Elastic License v2"
name = "Creation or Modification of Domain Backup DPAPI private key"
note = """## Triage and analysis
Domain DPAPI Backup keys are stored on domain controllers and can be dumped remotely with tools such as Mimikatz. The resulting .pvk private key can be used to decrypt ANY domain user masterkeys, which then can be used to decrypt any secrets protected by those keys.
"""
references = [
"https://www.dsinternals.com/en/retrieving-dpapi-backup-keys-from-active-directory/",
"https://posts.specterops.io/operational-guidance-for-offensive-user-dpapi-abuse-1fb7fac8b107",
@@ -54,6 +50,182 @@ query = '''
file where host.os.type == "windows" and event.type != "deletion" and file.name : ("ntds_capi_*.pfx", "ntds_capi_*.pvk")
'''
note = """## Triage and analysis
### Investigating Creation or Modification of Domain Backup DPAPI private key
#### Possible investigation steps
- Does the alert show a new or changed domain DPAPI backup key artifact?
- Focus: `event.type`, `event.action`, `file.name`, `file.path`, and `file.size`; distinguish `ntds_capi_*.pfx` or `ntds_capi_*.pvk` in temp, user, share, removable, archive, or controlled recovery paths.
- Implication: escalate on create or modify activity in staging paths or analyst home directories because the artifact can unlock domain DPAPI-protected secrets; lower suspicion only when the path is a controlled DC recovery or IR location tied to the same case.
- Is the acting process a recognized recovery tool or an export utility being abused?
- Why: live DC retrieval and offline AD database extraction both create domain-scale DPAPI exposure once backup keys leave controlled recovery.
- Focus: process-start events scoped by `host.id` and `process.entity_id`, checking `process.executable`, `process.command_line`, `process.pe.original_file_name`, `process.parent.command_line`, and `process.code_signature.subject_name`. $investigate_0
- Implication: escalate when a shell, script host, renamed binary, or command line expresses backup-key export outside controlled recovery; lower concern only when tool identity, parent, and output path fit one controlled recovery workflow.
- Did the same process export companion key material or package the result?
- Focus: file events scoped to `process.entity_id`, or `host.id` plus `process.pid` in a tight time window, checking `file.name`, `file.path`, `file.Ext.original.path`, and `file.Ext.original.name`. $investigate_1
- Implication: escalate when the process creates multiple backup-key outputs, writes companion legacy-key material, renames the files, archives them, or stages other credential-sensitive artifacts.
- Hint: if `ntds_capi_*` disappears quickly, trace rename events through `file.Ext.original.path` and `file.Ext.original.name`; if those fields are absent, fall back to current `file.path` plus the same `process.entity_id` or host/PID time window.
- Do the user and host telemetry fit a tightly scoped recovery operator path?
- Focus: `user.id`, `user.name`, `user.domain`, `host.id`, and `host.name`; separate domain recovery, backup, or IR identities from standard users and ad hoc workstations.
- Implication: escalate when the user or host identity is mismatched, generic, or unexplained for domain backup-key handling; treat a plausible operator and host pairing as candidate benign only after the file, process, and artifact evidence also fit the same workflow.
- Did follow-on activity stage the export for off-host use?
- Focus: process, child-process, file, and network events for the recovered process scope, especially `process.command_line`, `process.parent.command_line`, UNC, removable-media, archive, or share values in `file.path`, and off-host connections. $investigate_4 $investigate_5
- Implication: escalate when copy, archive, compression, removable-media, or share-write activity follows the export, especially from a non-DC host; absence of staging evidence narrows scope but does not close the alert by itself.
- If local evidence remains suspicious or unresolved and related-alert telemetry is available, does the same user or host show credential-access, staging, or tier-0 alerts?
- Focus: optional related-alert views for `user.id`, especially DPAPI abuse, LSASS or credential dumping, DCSync, archive or share staging, lateral movement to DCs, or tier-0 persistence. $investigate_2
- Hint: Pivot by `host.id` when user scope is sparse or host role changes urgency; absence of related-alert telemetry is unresolved, not benign. $investigate_3
- Implication: broaden to domain-compromise scoping when related alerts show credential access, DC access, or staging around the same time; absence of related alerts can narrow scope but must not close the alert without local file, process, artifact, and context alignment.
- Escalate on unrecognized export path, export-tool intent, companion artifacts, mismatched user or host, staging, or corroborating tier-0 alerts; close only when telemetry and recovery, backup, or IR verification bind one controlled workflow; preserve and escalate if evidence is mixed or visibility is incomplete.
### False positive analysis
- AD disaster-recovery, backup validation, or IR collection can legitimately export DPAPI domain backup material. Confirm telemetry first: `process.executable`, `process.command_line`, `file.path`, `user.id`, and `host.id` must all align with the same exact workflow.
- Use a recovery ticket, backup job, or IR case only to verify an already aligned telemetry pattern; do not close on records alone. If records are unavailable, recurring telemetry is a candidate benign pattern, not closure, until it verifies one controlled recovery path without contradictory staging.
- Before creating an exception, validate that the same `process.executable`, `process.command_line`, `file.path`, `user.id`, and `host.id` recur across prior alerts from this rule. Build the exception from that confirmed workflow, and avoid exceptions on `file.name` alone, `.pvk` or `.pfx` extensions alone, or the host alone.
### Response and remediation
- If confirmed benign, reverse any temporary containment and record the process path, command-line pattern, export location, operator identity, and host role that justified closure. Create an exception only if that same workflow recurs consistently across prior alerts from this rule.
- If suspicious but unconfirmed, preserve the exported `file.path`, rename evidence from `file.Ext.original.path` or `file.Ext.original.name`, the file-event timeline, recovered `process.entity_id` or `process.pid`, `process.command_line`, responsible `user.id`, `host.id`, and any UNC, removable-media, archive, or share paths before destructive changes. Apply reversible containment first, such as temporarily restricting share access or outbound connectivity for the affected `host.id`; escalate to host isolation or account containment only if companion staging, corroborating alerts, or other findings show broader compromise and the asset role can tolerate it.
- If confirmed malicious, preserve the same artifacts and use endpoint response to isolate the host or terminate the responsible process. If direct response is unavailable, escalate with the preserved artifact set to the team that can act. For domain controllers, weigh service impact before isolation but do not leave the export accessible.
- If unauthorized domain backup-key export is confirmed on a domain controller, activate the organization's Active Directory compromise response plan, preserve evidence needed to scope DPAPI-protected credential exposure, and begin privileged-account hygiene according to that plan.
- Before deleting or rotating anything, review related `host.id` and `user.id` activity for the same exported filenames, companion legacy-key artifacts, archive names, and UNC or share paths. Then eradicate the unauthorized export files, staging archives, copy utilities, scripts, and persistence mechanisms uncovered during the investigation, and remediate the privilege path or access vector that allowed the export.
- After containment, hunt for the same exported filenames, archive names, and UNC or share paths across other hosts.
"""
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.type",
"host.id",
"host.name",
"user.name",
"user.id",
"user.domain",
"process.entity_id",
"process.pid",
"process.executable",
"process.command_line",
"process.parent.command_line",
"process.code_signature.subject_name",
"file.path",
"file.Ext.original.path",
]
[[transform.investigate]]
label = "Process events for the alerting 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 = "process", valueType = "string" }
],
[
{ 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.category", queryType = "phrase", value = "process", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "File activity for the alerting 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" }
],
[
{ 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.category", queryType = "phrase", value = "file", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "Alerts associated with this 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 this 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 = "Child processes of the export 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 = "Network activity for the export 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 = "network", 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 = "network", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[rule.threat]]
framework = "MITRE ATT&CK"
rules/windows/credential_access_dump_registry_hives.toml
+178 -43
View File
@@ -2,7 +2,7 @@
creation_date = "2020/11/23"
integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/04/07"
updated_date = "2026/04/22"
[rule]
author = ["Elastic"]
@@ -22,45 +22,6 @@ index = [
language = "eql"
license = "Elastic License v2"
name = "Credential Acquisition via Registry Hive Dumping"
note = """## Triage and analysis
### Investigating Credential Acquisition via Registry Hive Dumping
Dumping registry hives is a common way to access credential information as some hives store credential material.
For example, the SAM hive stores locally cached credentials (SAM Secrets), and the SECURITY hive stores domain cached credentials (LSA secrets).
Dumping these hives in combination with the SYSTEM hive enables the attacker to decrypt these secrets.
This rule identifies the usage of `reg.exe` to dump SECURITY and/or SAM hives, which potentially indicates the compromise of the credentials stored in the host.
#### Possible investigation steps
- Investigate the script 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.
- Identify the user account that performed the action and whether it should perform this kind of action.
- Contact the account owner and confirm whether they are aware of this activity.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Investigate if the credential material was exfiltrated or processed locally by other tools.
- Investigate potentially compromised accounts. Analysts can do this by searching for login events (e.g., 4624) to the target host.
### False positive analysis
- Administrators can export registry hives for backup purposes using command line tools like `reg.exe`. Check whether the user is legitamitely performing this kind of activity.
### Related rules
- Registry Hive File Creation via SMB - a4c7473a-5cb4-4bc1-9d06-e4a75adbc494
### 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.
- 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.
- Reimage the host operating system and restore compromised files to clean versions.
- 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://medium.com/threatpunter/detecting-attempts-to-steal-passwords-from-the-registry-7512674487f8",
"https://www.elastic.co/security-labs/detect-credential-access",
@@ -92,6 +53,183 @@ process where host.os.type == "windows" and event.type == "start" and
process.args : ("hklm\\sam", "hklm\\security")
'''
note = """## Triage and analysis
### Investigating Credential Acquisition via Registry Hive Dumping
#### Possible investigation steps
- What exact hive-export behavior did the alert capture?
- Focus: `process.command_line`, `process.executable`, `process.pe.original_file_name`, and `process.code_signature.subject_name`.
- Implication: escalate if the command saves or exports SAM or SECURITY to temp, public, admin-share, UNC, removable, or deceptive paths; lower suspicion only when the signed Microsoft reg.exe identity, destination, and export set fit the same recognized backup, recovery, forensic, or break-glass workflow. Identity alone never clears the export.
- Does the parent and session context explain why credential-bearing hives were exported?
- Focus: `process.parent.executable`, `process.parent.command_line`, `process.Ext.session_info.logon_type`, and `user.id`.
- Hint: If the parent is generic and lineage remains unclear, expand ancestry before accepting a maintenance explanation.
- Implication: escalate when an interactive shell, script host, RMM tool, service account, remote-style session, or unexpected user initiated the export; lower suspicion when the same user or service identity, parent workflow, and session type recur for a recognized backup, recovery, forensic, or break-glass process.
- Did the alert parent launch accompanying SYSTEM export, staging, transfer, cleanup, or alternate dump commands?
- Focus: process events from the alert parent and reg.exe children, using `process.parent.entity_id`, `process.parent.pid`, `process.executable`, and `process.command_line`. $investigate_2 $investigate_3
- Hint: If `process.parent.entity_id` is absent, use the `host.id` + alert `process.parent.pid` branch in a tight alert-time window; if reg.exe spawned a helper, pivot from alert `process.entity_id` to child `process.parent.entity_id`.
- Hint: If file or network telemetry is available, recover file activity and connections for reg.exe and its children to identify hive output, archives, share writes, removable-media staging, or off-host transfer. Missing network telemetry is unresolved, not benign. $investigate_4 $investigate_5
- Implication: escalate when the same parent exports SYSTEM, packages, copies, deletes, or transfers hive output, or launches vssadmin.exe, diskshadow.exe, or shadow-copy paths to continue dumping outside this rule; absence of same-parent support reduces staging evidence but does not clear the original export.
- Does the host role or hive combination raise credential-exposure severity?
- Focus: `host.id`, `host.name`, and `process.command_line`, plus asset or case records only as corroboration.
- Hint: Do not infer privileged role from `host.name` alone.
- Implication: raise urgency when asset context or host history identifies a jump host, backup node, admin workstation, server, or shared management platform, or when same-parent process review confirms SYSTEM was exported with SAM or SECURITY; lower urgency only when the host role and export set fit the same recognized workflow.
- If local evidence remains suspicious or unresolved, does related alert scope show broader credential-access activity?
- Focus: related alerts for the same `user.id` and `host.id`, looking for credential dumping, archiving, privilege escalation, persistence, or lateral movement.
- Hint: Start with same-user alerts. $investigate_0
- Hint: Compare same-host alerts. $investigate_1
- Implication: broaden scope and credential review when related alerts show complementary abuse; keep the case local when related alert scope is quiet and local telemetry already binds the export to one recognized workflow.
- Based on the evidence gathered, what disposition is supported?
- Focus: binary identity, hive targets and output path, parent/session context, same-parent or child-process activity, host exposure, and related-alert scope.
- Implication: escalate when an unrecognized SAM or SECURITY export has a risky destination, suspicious lineage or session, follow-on staging, privileged-host exposure, or related credential-access alerts; close only when the same evidence categories bind one exact recognized workflow on this host, with outside confirmation if telemetry cannot prove legitimacy; preserve artifacts and escalate when evidence is mixed or incomplete.
### False positive analysis
- Backup, recovery, forensic, or break-glass workflows can legitimately export SAM or SECURITY hives. Confirm that the signed Microsoft utility identity, command-line hive and destination pattern, parent workflow, session context, `user.id`, `host.id`, host role, and same-parent or child-process activity all align with the same workflow. If telemetry cannot prove legitimacy, use case records, change records, or owner confirmation only as corroboration for that exact activity. If any evidence dimension contradicts the workflow, do not close as benign.
- Before creating an exception, validate that the same `process.executable`, `process.code_signature.subject_name`, `process.parent.command_line`, `process.command_line` hive/destination pattern, `user.id`, and `host.id` recur across prior alerts from this rule. Build from that minimum confirmed pattern. Avoid exceptions on `process.name`, reg.exe, the hive name, or the host alone.
### Response and remediation
- If confirmed benign, reverse any temporary restriction and document the recognized utility path, hive/destination pattern, parent and session context, `user.id`, `host.id`, host role, and corroborating case evidence that justified closure. Create an exception only if that same pattern recurs consistently across prior alerts from this rule.
- If suspicious but unconfirmed, preserve the alert record, process tree, `process.entity_id`, `process.command_line`, output path named in the command, same-parent or child-process command lines, session context, `user.id`, and `host.id` before containment or cleanup. Apply reversible containment tied to the findings, such as temporary share restriction or limited outbound access for the affected host; escalate to host isolation or account action only if staging, transfer commands, related alerts, or host criticality justify the impact.
- If confirmed malicious, preserve the same evidence set, then isolate the host if its role can tolerate it and the findings show unauthorized hive export or movement risk. Contain the responsible account only when the user/session evidence indicates account misuse. Terminate the process only after evidence capture if it is still running.
- Scope exposure from the copied material: SAM implies local account hash exposure; SECURITY implies LSA secret or cached-credential exposure; a same-parent SYSTEM export makes offline decryption more plausible and should raise urgency.
- Before deleting or rotating anything, review related `host.id` and `user.id` activity for the same command patterns, hive-copy names, archive names, share paths, transfer commands, and alternate copy methods such as vssadmin.exe, diskshadow.exe, or raw shadow-copy access. Then remove only the unauthorized dump scripts, archives, copied hive files, and persistence mechanisms identified during the investigation, and remediate the access path that allowed the export.
- Post-incident hardening: restrict hive export activity to recognized recovery or forensic workflows, document the confirmed `process.command_line` and destination patterns behind any exception, and retain process telemetry needed to distinguish future recovery work from repeated abuse.
"""
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",
"host.name",
"user.name",
"user.id",
"process.entity_id",
"process.executable",
"process.command_line",
"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.Ext.session_info.logon_type",
]
[[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 = "Processes from same parent as alert"
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.parent.entity_id}}", 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.pid", queryType = "phrase", value = "{{process.parent.pid}}", valueType = "string" },
{ excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "Child processes of reg.exe"
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 = "File activity for reg.exe 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 = "Network activity for reg.exe 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 = "network", 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 = "network", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[rule.threat]]
framework = "MITRE ATT&CK"
@@ -109,10 +247,7 @@ id = "T1003.004"
name = "LSA Secrets"
reference = "https://attack.mitre.org/techniques/T1003/004/"
[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"