[New Rules] Potential Relay Attack against a Computer Account

rules/windows/credential_access_dollar_account_relay.toml

@@ -2,33 +2,32 @@
 creation_date = "2024/07/24"
 integration = ["system", "windows"]
 maturity = "production"
-updated_date = "2025/03/20"
+updated_date = "2025/06/16"
 
 [rule]
 author = ["Elastic"]
 description = """
-Identifies potential relay attacks against a domain controller (DC) by identifying authentication events using the
-domain controller computer account coming from other hosts to the DC that owns the account. Attackers may relay the DC
+Identifies potential relay activities against a Computer account by identifying authentication events using the computer
+account coming from from hosts other than the server that owns the account. Attackers may relay the computer account
 hash after capturing it using forced authentication.
 """
 from = "now-9m"
 index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
 language = "eql"
 license = "Elastic License v2"
-name = "Potential Relay Attack against a Domain Controller"
+name = "Potential Computer Account Relay Activity"
 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 Relay Attack against a Domain Controller
-
-Domain Controllers (DCs) are critical in managing authentication within Windows environments. Adversaries exploit this by capturing and relaying DC credentials, often using NTLM authentication, to gain unauthorized access. The detection rule identifies anomalies in authentication events, such as machine accounts logging in from unexpected hosts, indicating potential relay attacks. By analyzing network logon types and mismatched IP addresses, it flags suspicious activities, aiding in early threat detection.
+### Investigating Potential Computer Account Relay Activity
 
 ### Possible investigation steps
 
-- Review the authentication events with event codes 4624 and 4625 to identify any anomalies in logon attempts, focusing on those using NTLM authentication.
-- Examine the source IP addresses of the suspicious authentication events to determine if they are external or unexpected within the network environment.
+- 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.
@@ -42,15 +41,18 @@ Domain Controllers (DCs) are critical in managing authentication within Windows
 - 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
-
-- Immediately isolate the affected domain controller from the network to prevent further unauthorized access and potential lateral movement by the attacker.
-- Conduct a password reset for the domain controller's machine account and any other accounts that may have been compromised or are at risk, ensuring the use of strong, unique passwords.
-- Review and analyze recent authentication logs and network traffic to identify any other potentially compromised systems or accounts, focusing on the source IP addresses flagged in the alert.
-- Implement network segmentation to limit the ability of attackers to relay credentials between systems, particularly between domain controllers and other critical infrastructure.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the breach.
-- Deploy additional monitoring and detection mechanisms to identify similar relay attack patterns in the future, enhancing the detection capabilities for NTLM relay attacks.
-- Conduct a post-incident review to identify any gaps in security controls and update policies or procedures to prevent recurrence, ensuring lessons learned are applied to improve overall security posture."""
+### 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",
@@ -74,8 +76,8 @@ timestamp_override = "event.ingested"
 type = "eql"
 
 query = '''
-authentication where host.os.type == "windows" and event.code in ("4624", "4625") and endswith~(user.name, "$") and
-    winlog.event_data.AuthenticationPackageName : "NTLM" and winlog.logon.type : "network" and
+authentication where host.os.type == "windows" and event.code in ("4624", "4625") and
+    endswith~(user.name, "$") and winlog.logon.type : "network" and
 
     /* Filter for a machine account that matches the hostname */
     startswith~(host.name, substring(user.name, 0, -1)) and

rules/windows/credential_access_dollar_account_relay_kerberos.toml

@@ -0,0 +1,129 @@
+[metadata]
+creation_date = "2025/06/18"
+integration = ["system", "windows"]
+maturity = "production"
+updated_date = "2025/06/18"
+
+[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.
+"""
+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",
+    "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
+rule_id = "2d58f67c-156e-480a-a6eb-a698fd8197ff"
+severity = "high"
+tags = [
+    "Domain: Endpoint",
+    "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",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+sequence by winlog.computer_name, source.ip with maxspan=5s
+
+/* Filter for an event that indicates coercion against known abused named pipes using an account that is not the host */
+[file where host.os.type == "windows" and event.code : "5145" and 
+    not startswith~(winlog.computer_name, substring(user.name, 0, -1)) and
+    file.name : (
+        "Spoolss", "netdfs", "lsarpc", "lsass", "netlogon", "samr", "efsrpc", "FssagentRpc",
+        "eventlog", "winreg", "srvsvc", "dnsserver", "dhcpserver", "WinsPipe"
+    )]
+
+/* Detects a logon attempt using the Kerberos protocol resulting from the coercion coming from the same IP address */
+[authentication where host.os.type == "windows" and event.code in ("4624", "4625") and
+    endswith~(user.name, "$") and winlog.logon.type : "network" and
+    winlog.event_data.AuthenticationPackageName : "Kerberos" and
+
+    /* Filter for a machine account that matches the hostname */
+    startswith~(winlog.computer_name, substring(user.name, 0, -1)) and
+
+    /* Verify if the Source IP belongs to the host */
+    not endswith(string(source.ip), string(host.ip)) and
+    source.ip != null and source.ip != "::1" and source.ip != "127.0.0.1"]
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1187"
+name = "Forced Authentication"
+reference = "https://attack.mitre.org/techniques/T1187/"
+
+[[rule.threat.technique]]
+id = "T1557"
+name = "Adversary-in-the-Middle"
+reference = "https://attack.mitre.org/techniques/T1557/"
+[[rule.threat.technique.subtechnique]]
+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/"
+