nldcsc-elastic-rules 0.0.8__py3-none-any.whl

nldcsc_elastic_rules/rules/windows/credential_access_dcsync_replication_rights.toml

@@ -0,0 +1,155 @@
+[metadata]
+creation_date = "2022/02/08"
+integration = ["system", "windows"]
+maturity = "production"
+updated_date = "2025/09/11"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule identifies when a User Account starts the Active Directory Replication Process. Attackers can use the DCSync
+technique to get credential information of individual accounts or the entire domain, thus compromising the entire
+domain.
+"""
+false_positives = [
+  """
+  Service accounts that perform replication may trigger this alert on the first run per AD object, but they'll be
+  suppressed in subsequent runs since this rule uses the new_terms rule type.
+  """
+]
+from = "now-9m"
+index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Potential Credential Access via DCSync"
+note = """## Triage and analysis
+
+### Investigating Potential Credential Access via 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 used legitimately for tickets creation, but also tickets forging 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 Event ID 4662 (Operation was performed on an Active Directory object) and identifies events that use 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). It also filters out events that use computer accounts and also Azure AD Connect MSOL accounts (more details [here](https://techcommunity.microsoft.com/t5/microsoft-defender-for-identity/ad-connect-msol-user-suspected-dcsync-attack/m-p/788028)).
+
+#### 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 it is the case, and if it is properly secured. If noisy in your environment due to expected activity, consider adding the corresponding account as a exception.
+- 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. If this rule is noisy in your environment due to expected activity, consider adding the corresponding account as a exception.
+
+### 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).
+"""
+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",
+    "https://github.com/SigmaHQ/sigma/blob/master/rules/windows/builtin/security/win_ad_replication_non_machine_account.yml",
+    "https://github.com/atc-project/atomic-threat-coverage/blob/master/Atomic_Threat_Coverage/Logging_Policies/LP_0027_windows_audit_directory_service_access.md",
+    "https://attack.stealthbits.com/privilege-escalation-using-mimikatz-dcsync",
+    "https://www.thehacker.recipes/ad/movement/credentials/dumping/dcsync",
+    "https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry",
+]
+risk_score = 47
+rule_id = "9f962927-1a4f-45f3-a57b-287f2c7029c1"
+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 = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Windows",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Tactic: Privilege Escalation",
+    "Data Source: Active Directory",
+    "Resources: Investigation Guide",
+    "Use Case: Active Directory Monitoring",
+    "Data Source: Windows Security Event Logs",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+host.os.type:"windows" and event.code:"4662" and
+  winlog.event_data.Properties:(
+    *DS-Replication-Get-Changes* or *DS-Replication-Get-Changes-All* or
+    *DS-Replication-Get-Changes-In-Filtered-Set* or *1131f6ad-9c07-11d1-f79f-00c04fc2dcd2* or
+    *1131f6aa-9c07-11d1-f79f-00c04fc2dcd2* or *89e95b76-444d-4c62-991a-0facbeda640c*
+  ) and winlog.event_data.AccessMask : "0x100" and
+  not winlog.event_data.SubjectUserName:(*$ or MSOL_*)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1003"
+name = "OS Credential Dumping"
+reference = "https://attack.mitre.org/techniques/T1003/"
+[[rule.threat.technique.subtechnique]]
+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]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+[[rule.threat.technique.subtechnique]]
+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.SubjectUserSid", "winlog.event_data.ObjectName"]
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-12h"

nldcsc_elastic_rules/rules/windows/credential_access_dcsync_user_backdoor.toml

@@ -0,0 +1,124 @@
+[metadata]
+creation_date = "2024/07/10"
+integration = ["system", "windows"]
+maturity = "production"
+updated_date = "2025/11/14"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies the modification of the nTSecurityDescriptor attribute in a domain object with rights related to DCSync to a
+user/computer account. Attackers can use this backdoor to re-obtain access to hashes of any user/computer.
+"""
+from = "now-9m"
+index = ["winlogbeat-*", "logs-system.security*", "logs-windows.forwarded*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Potential Active Directory Replication Account Backdoor"
+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 Active Directory Replication Account Backdoor
+
+Active Directory (AD) is a critical component in many enterprise environments, managing user and computer accounts. Adversaries may exploit AD by modifying security descriptors to gain replication rights, allowing them to extract sensitive credential data. The detection rule identifies suspicious changes to security descriptors, specifically targeting attributes that grant replication capabilities, which could indicate an attempt to establish a backdoor for credential access.
+
+### Possible investigation steps
+
+- Review the event logs for the specific event code 5136 to identify the exact changes made to the nTSecurityDescriptor attribute and the account involved.
+- Examine the winlog.event_data.AttributeValue to determine if the changes include the specific GUIDs (*1131f6ad-9c07-11d1-f79f-00c04fc2dcd2, *1131f6aa-9c07-11d1-f79f-00c04fc2dcd2, *89e95b76-444d-4c62-991a-0facbeda640c) that indicate replication rights were granted.
+- Identify the user or computer account (S-1-5-21-*) that was granted these rights and assess whether this account should have such permissions.
+- Check the account's recent activity and login history to identify any unusual or unauthorized access patterns.
+- Investigate any recent changes or anomalies in the directory service that could correlate with the suspicious modification event.
+- Consult with the Active Directory administrators to verify if the changes were authorized and part of any legitimate administrative tasks.
+
+### False positive analysis
+
+- Changes made by authorized administrators during legitimate security audits or system maintenance can trigger the rule. To manage this, create exceptions for known administrative accounts performing regular audits.
+- Automated scripts or tools used for Active Directory management might modify security descriptors as part of their normal operation. Identify these scripts and exclude their associated accounts from triggering alerts.
+- Scheduled tasks or system processes that require replication rights for synchronization purposes may also cause false positives. Review and whitelist these processes if they are verified as non-threatening.
+- Third-party applications with legitimate replication needs might alter security descriptors. Ensure these applications are documented and their actions are excluded from the rule.
+- Temporary changes during system migrations or upgrades can be mistaken for suspicious activity. Monitor these events closely and apply temporary exceptions as needed.
+
+### Response and remediation
+
+- Immediately isolate the affected user or computer account from the network to prevent further unauthorized access or data exfiltration.
+- Revoke any unauthorized permissions or changes made to the nTSecurityDescriptor attribute for the affected account to remove replication rights.
+- Conduct a thorough review of recent changes to the AD environment, focusing on accounts with elevated privileges, to identify any other unauthorized modifications.
+- Reset passwords for all accounts that may have been compromised, prioritizing those with administrative or sensitive access.
+- Implement additional monitoring on the affected account and related systems to detect any further suspicious activity.
+- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the full scope of the breach.
+- Review and update access control policies and security descriptors in Active Directory to prevent similar unauthorized changes in the future.
+
+## 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)
+```
+"""
+references = [
+    "https://twitter.com/menasec1/status/1111556090137903104",
+    "https://www.specterops.io/assets/resources/an_ace_up_the_sleeve.pdf",
+    "https://github.com/SigmaHQ/sigma/blob/master/rules/windows/builtin/security/win_security_account_backdoor_dcsync_rights.yml",
+    "https://learn.microsoft.com/en-us/windows/win32/adschema/r-ds-replication-get-changes-all",
+    "https://learn.microsoft.com/en-us/windows/win32/adschema/r-ds-replication-get-changes",
+    "https://learn.microsoft.com/en-us/windows/win32/adschema/r-ds-replication-get-changes-in-filtered-set",
+]
+risk_score = 47
+rule_id = "f8822053-a5d2-46db-8c96-d460b12c36ac"
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Windows",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Data Source: Active Directory",
+    "Use Case: Active Directory Monitoring",
+    "Data Source: Windows Security Event Logs",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.code:"5136" and host.os.type:"windows" and
+  winlog.event_data.AttributeLDAPDisplayName:"nTSecurityDescriptor" and
+  winlog.event_data.AttributeValue : (
+    (
+      *1131f6ad-9c07-11d1-f79f-00c04fc2dcd2;;S-1-5-21-* and
+      *1131f6aa-9c07-11d1-f79f-00c04fc2dcd2;;S-1-5-21-* and
+      *89e95b76-444d-4c62-991a-0facbeda640c;;S-1-5-21-*
+    )
+  )
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1003"
+name = "OS Credential Dumping"
+reference = "https://attack.mitre.org/techniques/T1003/"
+[[rule.threat.technique.subtechnique]]
+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/"
+

nldcsc_elastic_rules/rules/windows/credential_access_disable_kerberos_preauth.toml

@@ -0,0 +1,138 @@
+[metadata]
+creation_date = "2022/01/24"
+integration = ["system", "windows"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies the modification of an account's Kerberos pre-authentication options. An adversary with
+GenericWrite/GenericAll rights over the account can maliciously modify these settings to perform offline password
+cracking attacks such as AS-REP roasting.
+"""
+from = "now-9m"
+index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Kerberos Pre-authentication Disabled for User"
+note = """## Triage and analysis
+
+### Investigating Kerberos Pre-authentication Disabled for User
+
+Kerberos pre-authentication is an account protection against offline password cracking. When enabled, a user requesting access to a resource initiates communication with the Domain Controller (DC) by sending an Authentication Server Request (AS-REQ) message with a timestamp that is encrypted with the hash of their password. If and only if the DC is able to successfully decrypt the timestamp with the hash of the user’s password, it will then send an Authentication Server Response (AS-REP) message that contains the Ticket Granting Ticket (TGT) to the user. Part of the AS-REP message is signed with the user’s password. Microsoft's security monitoring [recommendations](https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4738) state that `'Don't Require Preauth' – Enabled` should not be enabled for user accounts because it weakens security for the account’s Kerberos authentication.
+
+AS-REP roasting is an attack against Kerberos for user accounts that do not require pre-authentication, which means that if the target user has pre-authentication disabled, an attacker can request authentication data for it and get a TGT that can be brute-forced offline, similarly to Kerberoasting.
+
+#### Possible investigation steps
+
+- 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.
+- Determine if the target account is sensitive or privileged.
+- Inspect the account activities for suspicious or abnormal behaviors in the alert timeframe.
+
+### False positive analysis
+
+- Disabling pre-authentication is a bad security practice and should not be allowed in the domain. The security team should map and monitor any potential benign true positives (B-TPs), especially if the target account is privileged.
+
+### Response and remediation
+
+- Initiate the incident response process based on the outcome of the triage.
+- Reset the target account's password if there is any risk of TGTs having been retrieved.
+- Re-enable the preauthentication option or disable the target account.
+- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed.
+- 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.
+- 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://harmj0y.medium.com/roasting-as-reps-e6179a65216b",
+    "https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4738",
+    "https://github.com/atc-project/atomic-threat-coverage/blob/master/Atomic_Threat_Coverage/Logging_Policies/LP_0026_windows_audit_user_account_management.md",
+]
+risk_score = 47
+rule_id = "e514d8cd-ed15-4011-84e2-d15147e059f1"
+setup = """## Setup
+
+The 'Audit User Account Management' 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 >
+Account Management >
+Audit User Account Management (Success,Failure)
+```
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Windows",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Tactic: Defense Evasion",
+    "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
+    "Use Case: Active Directory Monitoring",
+    "Data Source: Active Directory",
+    "Data Source: Windows Security Event Logs",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+any where host.os.type == "windows" and event.code == "4738" and
+  winlog.event_data.NewUACList == "USER_DONT_REQUIRE_PREAUTH"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1558"
+name = "Steal or Forge Kerberos Tickets"
+reference = "https://attack.mitre.org/techniques/T1558/"
+[[rule.threat.technique.subtechnique]]
+id = "T1558.004"
+name = "AS-REP Roasting"
+reference = "https://attack.mitre.org/techniques/T1558/004/"
+
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+[[rule.threat.technique.subtechnique]]
+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/"
+

nldcsc_elastic_rules/rules/windows/credential_access_dnsnode_creation.toml

@@ -0,0 +1,117 @@
+[metadata]
+creation_date = "2024/03/26"
+integration = ["system", "windows"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+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 because of the default permission (Any authenticated users) to create DNS-named records. Attackers
+can perform Dynamic Spoofing attacks, where they monitor LLMNR/NBT-NS requests and create DNS-named records to target
+systems that are requested from multiple systems. They can also create specific records to target specific services,
+such as wpad, for spoofing attacks.
+"""
+from = "now-9m"
+index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Creation of a DNS-Named Record"
+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 Creation of a DNS-Named Record
+
+Active Directory Integrated DNS (ADIDNS) is crucial for maintaining domain consistency by storing DNS zones as AD objects. However, its default permissions can be exploited by attackers to create DNS records for spoofing attacks, targeting services like WPAD. The detection rule identifies such abuse by monitoring specific Windows events related to DNS record creation, filtering out legitimate system accounts to highlight potential threats.
+
+### Possible investigation steps
+
+- Review the event logs for event code 5137 to identify the specific DNS-named record that was created and the associated timestamp.
+- Examine the winlog.event_data.SubjectUserName field to determine the user account that initiated the DNS record creation, ensuring it is not a system account.
+- Investigate the context around the winlog.event_data.ObjectClass field to confirm the object class is "dnsNode" and assess if the DNS record creation aligns with expected administrative activities.
+- Check for any recent LLMNR/NBT-NS requests or network traffic that might indicate an attempt to exploit the newly created DNS record for spoofing purposes.
+- Correlate the alert with other security events or logs to identify any patterns or anomalies that might suggest malicious intent or unauthorized access attempts.
+- Assess the risk and impact of the DNS record creation by determining if it targets critical services like WPAD or other sensitive systems within the network.
+
+### False positive analysis
+
+- Legitimate administrative actions may trigger the rule when DNS records are created or modified by IT staff. To manage this, create exceptions for known administrative accounts that regularly perform these tasks.
+- Automated system processes or scripts that update DNS records can also cause false positives. Identify these processes and exclude their associated accounts from the rule to prevent unnecessary alerts.
+- Service accounts used by legitimate applications to dynamically update DNS records might be flagged. Review these accounts and add them to an exception list if they are verified as non-threatening.
+- Temporary network changes or testing environments where DNS records are frequently modified can lead to false positives. Consider excluding these environments or specific IP ranges from the rule to reduce noise.
+- Regularly review and update the exception list to ensure it reflects current network and administrative practices, minimizing the risk of overlooking genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious DNS record creation and potential spoofing attacks.
+- Review and remove any unauthorized DNS records created by non-system accounts, focusing on those targeting services like WPAD.
+- Reset credentials for any accounts that were potentially compromised or used in the attack to prevent further unauthorized access.
+- Implement stricter access controls on DNS record creation within Active Directory to limit permissions to only necessary and trusted accounts.
+- Monitor for any further suspicious DNS record creation events, particularly those involving non-system accounts, to detect and respond to potential follow-up attacks.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or services were affected.
+- Conduct a post-incident review to identify gaps in detection and response, and update security policies and procedures to prevent similar incidents in the future."""
+references = [
+    "https://www.netspi.com/blog/technical/network-penetration-testing/adidns-revisited/",
+    "https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications/wpad-spoofing",
+]
+risk_score = 21
+rule_id = "1e1b2e7e-b8f5-45e5-addc-66cc1224ffbc"
+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 = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Windows",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "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 = '''
+any where host.os.type == "windows" and event.code == "5137" and winlog.event_data.ObjectClass == "dnsNode" and
+    not winlog.event_data.SubjectUserName : "*$"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+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/"
+

nldcsc_elastic_rules/rules/windows/credential_access_dollar_account_relay.toml

@@ -0,0 +1,113 @@
+[metadata]
+creation_date = "2024/07/24"
+integration = ["system", "windows"]
+maturity = "production"
+updated_date = "2025/06/16"
+
+[rule]
+author = ["Elastic"]
+description = """
+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 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 Computer Account Relay Activity
+
+### 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://attack.mitre.org/techniques/T1187/",
+]
+risk_score = 21
+rule_id = "263481c8-1e9b-492e-912d-d1760707f810"
+severity = "low"
+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 = '''
+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
+
+    /* 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/"
+