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

nldcsc_elastic_rules/rules/windows/credential_access_posh_relay_tools.toml

@@ -0,0 +1,152 @@
+[metadata]
+creation_date = "2024/03/27"
+integration = ["windows"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects PowerShell scripts that can execute pass-the-hash (PtH) attacks, intercept and relay NTLM challenges, and carry
+out other man-in-the-middle (MitM) attacks.
+"""
+from = "now-9m"
+index = ["winlogbeat-*", "logs-windows.powershell*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Potential PowerShell Pass-the-Hash/Relay Script"
+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 PowerShell Pass-the-Hash/Relay Script
+
+PowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit PowerShell to perform pass-the-hash attacks, where they use stolen hashed credentials to authenticate without knowing the actual password. The detection rule identifies scripts attempting to execute such attacks by monitoring for specific NTLM negotiation patterns and hex sequences indicative of credential relay activities, while excluding legitimate system processes.
+
+### Possible investigation steps
+
+- Review the PowerShell script block text associated with the alert to identify any suspicious patterns or hex sequences, such as "NTLMSSPNegotiate" or specific hex values like "4E544C4D53535000".
+- Check the process execution details, including the parent process and command line arguments, to determine if the script was executed by a legitimate user or process.
+- Investigate the source and destination IP addresses involved in the NTLM negotiation to identify any unusual or unauthorized network activity.
+- Examine the user account associated with the process to verify if it has been compromised or if there are any signs of unauthorized access.
+- Correlate the alert with other security events or logs, such as Windows Event Logs or network traffic logs, to gather additional context and identify potential lateral movement or further compromise.
+- Assess the file directory from which the script was executed, ensuring it is not a known safe location like "C:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Downloads", which is excluded in the query.
+
+### False positive analysis
+
+- Legitimate system processes may occasionally trigger the rule if they perform operations that mimic NTLM negotiation patterns. To manage this, users can create exceptions for specific processes known to be safe by excluding their file paths or hashes.
+- Security tools or network monitoring solutions that perform NTLM authentication checks might generate false positives. Users should identify these tools and exclude their associated scripts or directories from the detection rule.
+- Automated scripts for system administration that involve NTLM authentication could be flagged. Review these scripts and, if verified as safe, add them to an exclusion list based on their directory or script block text.
+- PowerShell scripts used for legitimate penetration testing or security assessments may trigger alerts. Ensure these activities are documented and exclude the relevant scripts or directories during the testing period.
+- Regular updates or patches from Microsoft might include scripts that temporarily match the detection criteria. Monitor updates and adjust exclusions as necessary to prevent false positives from these legitimate updates.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further credential relay or unauthorized access.
+- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing malicious activities.
+- Conduct a thorough review of recent authentication logs and network traffic from the isolated system to identify any lateral movement or additional compromised accounts.
+- Reset passwords for any accounts suspected to be compromised, ensuring that new credentials are not reused or easily guessable.
+- Apply patches and updates to the affected system and any other vulnerable systems to mitigate known exploits used in pass-the-hash attacks.
+- Implement network segmentation to limit the spread of similar attacks in the future, focusing on restricting access to critical systems and sensitive data.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
+references = [
+    "https://github.com/Kevin-Robertson/Invoke-TheHash/blob/master/Invoke-WMIExec.ps1",
+    "https://github.com/Kevin-Robertson/Invoke-TheHash/blob/master/Invoke-SMBExec.ps1",
+    "https://github.com/dafthack/Check-LocalAdminHash/blob/master/Check-LocalAdminHash.ps1",
+    "https://github.com/nettitude/PoshC2/blob/master/resources/modules/Invoke-Tater.ps1",
+    "https://github.com/Kevin-Robertson/Inveigh/blob/master/Inveigh.ps1",
+]
+risk_score = 73
+rule_id = "951779c2-82ad-4a6c-82b8-296c1f691449"
+setup = """## Setup
+
+The 'PowerShell Script Block Logging' logging policy must be enabled.
+Steps to implement the logging policy with Advanced Audit Configuration:
+
+```
+Computer Configuration >
+Administrative Templates >
+Windows PowerShell >
+Turn on PowerShell Script Block Logging (Enable)
+```
+
+Steps to implement the logging policy via registry:
+
+```
+reg add "hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
+```
+"""
+severity = "high"
+tags = [
+    "Domain: Endpoint",
+    "OS: Windows",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Resources: Investigation Guide",
+    "Data Source: PowerShell Logs",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.category:process and host.os.type:windows and
+  powershell.file.script_block_text : (
+    ("NTLMSSPNegotiate" and ("NegotiateSMB" or "NegotiateSMB2")) or
+    "4E544C4D53535000" or
+    "0x4e,0x54,0x4c,0x4d,0x53,0x53,0x50" or
+    "0x4e,0x54,0x20,0x4c,0x4d" or
+    "0x53,0x4d,0x42,0x20,0x32" or
+    "0x81,0xbb,0x7a,0x36,0x44,0x98,0xf1,0x35,0xad,0x32,0x98,0xf0,0x38"
+  ) and
+  not file.directory : "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Downloads"
+'''
+
+
+[[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/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1059"
+name = "Command and Scripting Interpreter"
+reference = "https://attack.mitre.org/techniques/T1059/"
+[[rule.threat.technique.subtechnique]]
+id = "T1059.001"
+name = "PowerShell"
+reference = "https://attack.mitre.org/techniques/T1059/001/"
+
+
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1550"
+name = "Use Alternate Authentication Material"
+reference = "https://attack.mitre.org/techniques/T1550/"
+[[rule.threat.technique.subtechnique]]
+id = "T1550.002"
+name = "Pass the Hash"
+reference = "https://attack.mitre.org/techniques/T1550/002/"
+
+
+
+[rule.threat.tactic]
+id = "TA0008"
+name = "Lateral Movement"
+reference = "https://attack.mitre.org/tactics/TA0008/"
+

nldcsc_elastic_rules/rules/windows/credential_access_posh_request_ticket.toml

@@ -0,0 +1,139 @@
+[metadata]
+creation_date = "2022/01/24"
+integration = ["windows"]
+maturity = "production"
+updated_date = "2025/09/03"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects PowerShell scripts that have the capability of requesting kerberos tickets, which is a common step in
+Kerberoasting toolkits to crack service accounts.
+"""
+from = "now-9m"
+index = ["winlogbeat-*", "logs-windows.powershell*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "PowerShell Kerberos Ticket Request"
+note = """## Triage and analysis
+
+### Investigating PowerShell Kerberos Ticket Request
+
+PowerShell is one of the main tools system administrators use for automation, report routines, and other tasks, making it available for use in various environments, creating an attractive way for attackers to execute code.
+
+Accounts associated with a service principal name (SPN) are viable targets for Kerberoasting attacks, which use brute force to crack the user password, which is used to encrypt a Kerberos TGS ticket.
+
+Attackers can use PowerShell to request these Kerberos tickets, with the intent of extracting them from memory to perform Kerberoasting.
+
+#### Possible investigation steps
+
+- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.
+- 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.
+- Investigate if the script was executed, and if so, which account was targeted.
+- Validate if the account has an SPN associated with it.
+- 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.
+- Check if the script has any other functionality that can be potentially malicious.
+- Investigate other alerts associated with the user/host during the past 48 hours.
+- Review event ID [4769](https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4769) related to this account and service name for additional information.
+
+### False positive analysis
+
+- A possible false positive can be identified if the script content is not malicious/harmful or does not request Kerberos tickets for user accounts, as computer accounts are not vulnerable to Kerberoasting due to complex password requirements and policy.
+
+### 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. Prioritize privileged accounts.
+- Isolate the involved hosts to prevent further post-compromise behavior.
+- 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://cobalt.io/blog/kerberoast-attack-techniques",
+    "https://github.com/EmpireProject/Empire/blob/master/data/module_source/credentials/Invoke-Kerberoast.ps1",
+]
+risk_score = 73
+rule_id = "eb610e70-f9e6-4949-82b9-f1c5bcd37c39"
+setup = """## Setup
+
+The 'PowerShell Script Block Logging' logging policy must be enabled.
+Steps to implement the logging policy with Advanced Audit Configuration:
+
+```
+Computer Configuration >
+Administrative Templates >
+Windows PowerShell >
+Turn on PowerShell Script Block Logging (Enable)
+```
+
+Steps to implement the logging policy via registry:
+
+```
+reg add "hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
+```
+"""
+severity = "high"
+tags = [
+    "Domain: Endpoint",
+    "OS: Windows",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Resources: Investigation Guide",
+    "Data Source: PowerShell Logs",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.category:process and host.os.type:windows and
+  powershell.file.script_block_text : (
+    KerberosRequestorSecurityToken
+  ) and not user.id : ("S-1-5-18" or "S-1-5-20") and
+  not powershell.file.script_block_text : (
+    ("sentinelbreakpoints" and ("Set-PSBreakpoint" or "Set-HookFunctionTabs")) or
+    ("function global" and "\\windows\\sentinel\\4")
+  )
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1003"
+name = "OS Credential Dumping"
+reference = "https://attack.mitre.org/techniques/T1003/"
+
+[[rule.threat.technique]]
+id = "T1558"
+name = "Steal or Forge Kerberos Tickets"
+reference = "https://attack.mitre.org/techniques/T1558/"
+[[rule.threat.technique.subtechnique]]
+id = "T1558.003"
+name = "Kerberoasting"
+reference = "https://attack.mitre.org/techniques/T1558/003/"
+
+
+
+[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 = "T1059"
+name = "Command and Scripting Interpreter"
+reference = "https://attack.mitre.org/techniques/T1059/"
+[[rule.threat.technique.subtechnique]]
+id = "T1059.001"
+name = "PowerShell"
+reference = "https://attack.mitre.org/techniques/T1059/001/"
+
+
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+

nldcsc_elastic_rules/rules/windows/credential_access_posh_veeam_sql.toml

@@ -0,0 +1,134 @@
+[metadata]
+creation_date = "2024/03/14"
+integration = ["windows"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies PowerShell scripts that can access and decrypt Veeam credentials stored in MSSQL databases. Attackers can use
+Veeam Credentials to target backups as part of destructive operations such as Ransomware attacks.
+"""
+from = "now-9m"
+index = ["winlogbeat-*", "logs-windows.powershell*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "PowerShell Script with Veeam Credential Access Capabilities"
+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 PowerShell Script with Veeam Credential Access Capabilities
+
+PowerShell, a powerful scripting language in Windows environments, can be exploited by attackers to access and decrypt sensitive credentials, such as those stored by Veeam in MSSQL databases. Adversaries may leverage this to compromise backup data, facilitating ransomware attacks. The detection rule identifies suspicious script activity by monitoring specific database interactions and decryption attempts, flagging potential credential access threats.
+
+### Possible investigation steps
+
+- Review the PowerShell script block text associated with the alert to identify any references to "[dbo].[Credentials]" and "Veeam" or "VeeamBackup" to confirm potential credential access attempts.
+- Check the event logs for the specific host where the alert was triggered to gather additional context about the process execution, including the user account involved and the script's origin.
+- Investigate any recent changes or access to the MSSQL database containing Veeam credentials to determine if there were unauthorized access attempts or modifications.
+- Analyze the use of "ProtectedStorage]::GetLocalString" within the script to understand if it was used to decrypt or access sensitive information.
+- Correlate the alert with other security events or logs from the same host or network segment to identify any related suspicious activities or patterns that could indicate a broader attack.
+
+### False positive analysis
+
+- Routine administrative scripts that query MSSQL databases for maintenance purposes may trigger the rule. To manage this, identify and whitelist specific scripts or processes that are known to be safe and regularly executed by trusted administrators.
+- Scheduled tasks or automated backup verification processes that access Veeam credentials for legitimate reasons can be mistaken for malicious activity. Exclude these tasks by specifying their unique identifiers or execution paths in the monitoring system.
+- Security audits or compliance checks that involve accessing credential information for validation purposes might be flagged. Coordinate with the audit team to document these activities and create exceptions for their scripts.
+- Development or testing environments where PowerShell scripts are used to simulate credential access for testing purposes can generate false positives. Implement environment-specific exclusions to prevent these from being flagged in production monitoring.
+- Third-party monitoring tools that interact with Veeam credentials for health checks or performance monitoring may inadvertently trigger alerts. Work with the tool vendors to understand their access patterns and exclude them if they are verified as non-threatening.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing credential access attempts.
+- Change all Veeam-related credentials and any other potentially compromised credentials stored in the MSSQL database to prevent further unauthorized access.
+- Conduct a thorough review of backup integrity and ensure that no unauthorized modifications or deletions have occurred.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected.
+- Implement enhanced monitoring for PowerShell activity and MSSQL database access to detect similar threats in the future.
+- Review and update access controls and permissions for Veeam and MSSQL databases to ensure they follow the principle of least privilege."""
+references = [
+    "https://forums.veeam.com/veeam-backup-replication-f2/recover-esxi-password-in-veeam-t34630.html",
+    "https://www.crowdstrike.com/blog/anatomy-of-alpha-spider-ransomware/",
+]
+risk_score = 47
+rule_id = "5c602cba-ae00-4488-845d-24de2b6d8055"
+setup = """## Setup
+
+The 'PowerShell Script Block Logging' logging policy must be enabled.
+Steps to implement the logging policy with Advanced Audit Configuration:
+
+```
+Computer Configuration >
+Administrative Templates >
+Windows PowerShell >
+Turn on PowerShell Script Block Logging (Enable)
+```
+
+Steps to implement the logging policy via registry:
+
+```
+reg add "hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
+```
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Windows",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Data Source: PowerShell Logs",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.category:process and host.os.type:windows and
+  powershell.file.script_block_text : (
+    (
+      "[dbo].[Credentials]" and
+      ("Veeam" or "VeeamBackup")
+    ) or
+    "ProtectedStorage]::GetLocalString"
+  )
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1003"
+name = "OS Credential Dumping"
+reference = "https://attack.mitre.org/techniques/T1003/"
+
+[[rule.threat.technique]]
+id = "T1555"
+name = "Credentials from Password Stores"
+reference = "https://attack.mitre.org/techniques/T1555/"
+
+
+[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 = "T1059"
+name = "Command and Scripting Interpreter"
+reference = "https://attack.mitre.org/techniques/T1059/"
+[[rule.threat.technique.subtechnique]]
+id = "T1059.001"
+name = "PowerShell"
+reference = "https://attack.mitre.org/techniques/T1059/001/"
+
+
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+

nldcsc_elastic_rules/rules/windows/credential_access_potential_lsa_memdump_via_mirrordump.toml

@@ -0,0 +1,103 @@
+[metadata]
+creation_date = "2021/09/27"
+integration = ["windows"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies suspicious access to an LSASS handle via DuplicateHandle from an unknown call trace module. This may indicate
+an attempt to bypass the NtOpenProcess API to evade detection and dump LSASS memory for credential access.
+"""
+from = "now-9m"
+index = ["winlogbeat-*", "logs-windows.sysmon_operational-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential Credential Access via DuplicateHandle in LSASS"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Potential Credential Access via DuplicateHandle in LSASS
+
+The Local Security Authority Subsystem Service (LSASS) is crucial for enforcing security policies and managing user credentials in Windows environments. Adversaries may exploit the DuplicateHandle function to access LSASS memory, bypassing traditional API calls to avoid detection. The detection rule identifies suspicious LSASS handle access attempts from unknown modules, flagging potential credential dumping activities.
+
+### Possible investigation steps
+
+- Review the event logs for the specific event code "10" to gather more details about the suspicious activity, focusing on the process name "lsass.exe" and the granted access "0x40".
+- Investigate the call trace details where the event data indicates "*UNKNOWN*" to identify any unknown or suspicious modules that may have initiated the DuplicateHandle request.
+- Correlate the suspicious activity with other security events or alerts on the same host to determine if there are additional indicators of compromise or related malicious activities.
+- Check the process tree and parent-child relationships of the lsass.exe process to identify any unusual or unauthorized processes that may have interacted with LSASS.
+- Analyze the timeline of events to understand the sequence of actions leading up to and following the alert, which may help in identifying the adversary's objectives or next steps.
+- Review recent changes or updates to the system that might have introduced the unknown module or altered the behavior of legitimate processes.
+
+### False positive analysis
+
+- Legitimate software or security tools that interact with LSASS for monitoring or protection purposes may trigger this rule. Users should identify and whitelist these trusted applications to prevent unnecessary alerts.
+- System management or administrative scripts that perform legitimate operations on LSASS might be flagged. Review these scripts and, if verified as safe, add them to an exception list to reduce false positives.
+- Custom in-house applications that require access to LSASS for valid reasons could be mistakenly identified. Conduct a thorough review of these applications and exclude them from the rule if they are deemed non-threatening.
+- Security testing or penetration testing activities may mimic malicious behavior. Coordinate with security teams to recognize these activities and temporarily adjust the rule settings during testing periods to avoid false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes associated with the unknown executable region accessing LSASS to halt potential credential dumping activities.
+- Conduct a thorough memory analysis of the affected system to identify any malicious artifacts or indicators of compromise related to the DuplicateHandle exploitation.
+- Reset credentials for all accounts that may have been accessed or compromised, prioritizing high-privilege accounts.
+- Review and update endpoint protection configurations to ensure they are capable of detecting and blocking similar unauthorized access attempts in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Implement enhanced monitoring and logging for LSASS and related processes to detect any future attempts to exploit the DuplicateHandle function."""
+references = ["https://github.com/CCob/MirrorDump"]
+risk_score = 47
+rule_id = "02a4576a-7480-4284-9327-548a806b5e48"
+setup = """## Setup
+
+If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2,
+events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2.
+Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate
+`event.ingested` to @timestamp.
+For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Windows",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Data Source: Sysmon",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "windows" and event.code == "10" and
+
+ /* LSASS requesting DuplicateHandle access right to another process */
+ process.name : "lsass.exe" and winlog.event_data.GrantedAccess == "0x40" and
+
+ /* call is coming from an unknown executable region */
+ winlog.event_data.CallTrace : "*UNKNOWN*"
+'''
+
+
+[[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.001"
+name = "LSASS Memory"
+reference = "https://attack.mitre.org/techniques/T1003/001/"
+
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+

nldcsc_elastic_rules/rules/windows/credential_access_rare_webdav_destination.toml

@@ -0,0 +1,98 @@
+[metadata]
+creation_date = "2025/04/28"
+integration = ["endpoint", "system", "windows", "m365_defender", "crowdstrike"]
+maturity = "production"
+updated_date = "2025/07/16"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies rare connection attempts to a Web Distributed Authoring and Versioning (WebDAV) resource. Attackers may
+inject WebDAV paths in files or features opened by a victim user to leak their NTLM credentials via forced
+authentication.
+"""
+from = "now-3660s"
+language = "esql"
+license = "Elastic License v2"
+name = "Rare Connection to WebDAV Target"
+note = """## Triage and analysis
+
+### Investigating Rare Connection to WebDAV Target
+
+### Possible investigation steps
+
+- Examine the reputation of the destination domain or IP address.
+- Verify if the target user opened any attachments or clicked links pointing to the same target within seconds from the alert timestamp.
+- 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
+
+- User accessing legit WebDAV resources.
+
+### Response and remediation
+
+- Conduct a password reset for the target account that may have been compromised or are at risk, ensuring the use of strong, unique passwords.
+- Verify whether other users were targeted but did not open the lure..
+- 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.
+- 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://attack.mitre.org/techniques/T1187/"]
+risk_score = 47
+rule_id = "6756ee27-9152-479b-9b73-54b5bbda301c"
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Windows",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Data Source: Elastic Defend",
+    "Data Source: Windows Security Event Logs",
+    "Data Source: Microsoft Defender for Endpoint",
+    "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "esql"
+
+query = '''
+from logs-*
+| where
+    @timestamp > now() - 8 hours and
+    event.category == "process" and
+    event.type == "start" and
+    process.name == "rundll32.exe" and
+    process.command_line like "*DavSetCookie*"
+| keep host.id, process.command_line, user.name
+| grok
+    process.command_line """(?<Esql.server_webdav_cookie>DavSetCookie .* http)"""
+| eval
+    Esql.server_webdav_cookie_replace = replace(Esql.server_webdav_cookie, "(DavSetCookie | http)", "")
+| where
+    Esql.server_webdav_cookie_replace is not null and
+    Esql.server_webdav_cookie_replace rlike """(([a-zA-Z0-9-]+\.)+[a-zA-Z]{2,3}(@SSL.*)*|(\d{1,3}\.){3}\d{1,3})""" and
+    not Esql.server_webdav_cookie_replace in ("www.google.com@SSL", "www.elastic.co@SSL") and
+    not Esql.server_webdav_cookie_replace rlike """(10\.(\d{1,3}\.){2}\d{1,3}|172\.(1[6-9]|2\d|3[0-1])\.(\d{1,3}\.)\d{1,3}|192\.168\.(\d{1,3}\.)\d{1,3})"""
+| stats
+    Esql.event_count = count(*),
+    Esql.host_id_count_distinct = count_distinct(host.id),
+    Esql.host_id_values = values(host.id),
+    Esql.user_name_values = values(user.name)
+  by Esql.server_webdav_cookie_replace
+| where
+    Esql.host_id_count_distinct == 1 and
+    Esql.event_count <= 3
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1187"
+name = "Forced Authentication"
+reference = "https://attack.mitre.org/techniques/T1187/"
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+