[New] Potential Machine Account Relay Attack via SMB

Identify a server machine account accessing itself via SMB but from a remote source.ip, this behavior is abnormal and match SMB relay:

Author: Samirbous

rules/windows/credential_access_machine_account_smb_relay.toml

@@ -0,0 +1,101 @@
+[metadata]
+creation_date = "2025/06/16"
+integration = ["system", "windows"]
+maturity = "production"
+updated_date = "2025/06/16"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies potential relay attacks against a machine account by identifying network share access events coming from a
+remote source.ip but using the target server computer account. This may indicate a successful SMB relay attack.
+"""
+from = "now-9m"
+index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential Machine Account Relay Attack via SMB"
+note = """## Triage and analysis
+
+### Investigating Potential Machine Account Relay Attack via SMB
+
+### Possible investigation steps
+- Compare the source.ip to the target server host.ip 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
+
+- 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."""
+references = [
+    "https://github.com/p0dalirius/windows-coerced-authentication-methods",
+    "https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications",
+    "https://attack.mitre.org/techniques/T1187/",
+]
+risk_score = 73
+rule_id = "d84a11c0-eb12-4e7d-8a0a-718e38351e29"
+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 = '''
+file where event.code == "5145" and endswith(user.name, "$") and
+ startswith~(winlog.computer_name, substring(user.name, 0, -1)) and
+ not cidrmatch(source.ip, "127.0.0.1", "::1") and not string(source.ip) like "*:*"  and
+ 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/"
+