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

nldcsc_elastic_rules/rules/network/initial_access_rpc_remote_procedure_call_to_the_internet.toml

@@ -0,0 +1,113 @@
+[metadata]
+creation_date = "2020/02/18"
+integration = ["network_traffic", "panw"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects network events that may indicate the use of RPC traffic to the Internet. RPC is commonly used by
+system administrators to remotely control a system for maintenance or to use shared resources. It should almost never be
+directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or
+backdoor vector.
+"""
+from = "now-9m"
+index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*", "logs-panw.panos*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "RPC (Remote Procedure Call) to the Internet"
+references = ["https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml"]
+risk_score = 73
+rule_id = "32923416-763a-4531-bb35-f33b9232ecdb"
+severity = "high"
+tags = ["Tactic: Initial Access", "Domain: Endpoint", "Use Case: Threat Detection", "Data Source: PAN-OS", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+(event.dataset: network_traffic.flow or (event.category: (network or network_traffic))) and
+  network.transport:tcp and (destination.port:135 or event.dataset:zeek.dce_rpc) and
+  source.ip:(
+    10.0.0.0/8 or
+    172.16.0.0/12 or
+    192.168.0.0/16
+  ) and
+  not destination.ip:(
+    10.0.0.0/8 or
+    127.0.0.0/8 or
+    169.254.0.0/16 or
+    172.16.0.0/12 or
+    192.0.0.0/24 or
+    192.0.0.0/29 or
+    192.0.0.8/32 or
+    192.0.0.9/32 or
+    192.0.0.10/32 or
+    192.0.0.170/32 or
+    192.0.0.171/32 or
+    192.0.2.0/24 or
+    192.31.196.0/24 or
+    192.52.193.0/24 or
+    192.168.0.0/16 or
+    192.88.99.0/24 or
+    224.0.0.0/4 or
+    100.64.0.0/10 or
+    192.175.48.0/24 or
+    198.18.0.0/15 or
+    198.51.100.0/24 or
+    203.0.113.0/24 or
+    240.0.0.0/4 or
+    "::1" or
+    "FE80::/10" or
+    "FF00::/8"
+  )
+'''
+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 RPC (Remote Procedure Call) to the Internet
+
+RPC enables remote management and resource sharing across networks, crucial for system administration. However, when exposed to the Internet, it becomes a target for attackers seeking initial access or backdoor entry. The detection rule identifies suspicious RPC traffic from internal IPs to external networks, flagging potential exploitation attempts by monitoring specific ports and IP ranges.
+
+### Possible investigation steps
+
+- Review the source IP address from the alert to identify the internal system initiating the RPC traffic. Check if this IP belongs to a known or authorized device within the network.
+- Examine the destination IP address to determine if it is a known or suspicious external entity. Use threat intelligence sources to assess if the IP has been associated with malicious activity.
+- Analyze the network traffic logs for the specific event.dataset values (network_traffic.flow or zeek.dce_rpc) to gather more context about the nature and volume of the RPC traffic.
+- Investigate the destination port, specifically port 135, to confirm if the traffic is indeed RPC-related and assess if there are any legitimate reasons for this communication.
+- Check for any recent changes or anomalies in the network configuration or system settings of the source IP that might explain the unexpected RPC traffic.
+- Correlate this alert with other security events or logs to identify any patterns or additional indicators of compromise that might suggest a broader attack campaign.
+
+### False positive analysis
+
+- Internal testing environments may generate RPC traffic to external IPs for legitimate purposes. Identify and document these environments, then create exceptions in the detection rule to prevent unnecessary alerts.
+- Cloud-based services or applications that require RPC communication for integration or management might trigger false positives. Review these services and whitelist their IP addresses if they are verified as non-threatening.
+- VPN or remote access solutions that use RPC for secure connections can be mistaken for suspicious activity. Ensure that the IP ranges of these solutions are excluded from the rule to avoid false alerts.
+- Automated backup or synchronization tools that use RPC to communicate with external servers could be flagged. Verify these tools and add their destination IPs to an exception list if they are part of routine operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough analysis of the affected system to identify any unauthorized changes or installed backdoors, focusing on processes and services related to RPC.
+- Revoke any compromised credentials and enforce a password reset for all accounts that may have been accessed or used during the incident.
+- Apply necessary patches and updates to the affected system and any other systems with similar vulnerabilities to mitigate the risk of exploitation.
+- Monitor network traffic for any signs of lateral movement or additional suspicious activity, particularly focusing on RPC-related traffic.
+- 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 logging and monitoring for RPC traffic to detect and respond to similar threats more effectively in the future."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1190"
+name = "Exploit Public-Facing Application"
+reference = "https://attack.mitre.org/techniques/T1190/"
+
+
+[rule.threat.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+

nldcsc_elastic_rules/rules/network/initial_access_smb_windows_file_sharing_activity_to_the_internet.toml

@@ -0,0 +1,126 @@
+[metadata]
+creation_date = "2020/02/18"
+integration = ["network_traffic", "panw"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects network events that may indicate the use of Windows file sharing (also called SMB or CIFS) traffic to
+the Internet. SMB is commonly used within networks to share files, printers, and other system resources amongst trusted
+systems. It should almost never be directly exposed to the Internet, as it is frequently targeted and exploited by
+threat actors as an initial access or backdoor vector or for data exfiltration.
+"""
+from = "now-9m"
+index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*", "logs-panw.panos*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "SMB (Windows File Sharing) Activity to the Internet"
+references = ["https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml"]
+risk_score = 73
+rule_id = "c82b2bd8-d701-420c-ba43-f11a155b681a"
+severity = "high"
+tags = ["Tactic: Initial Access", "Domain: Endpoint", "Use Case: Threat Detection", "Data Source: PAN-OS", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+(event.dataset: network_traffic.flow or (event.category: (network or network_traffic))) and
+  network.transport:tcp and (destination.port:(139 or 445) or event.dataset:zeek.smb) and
+  source.ip:(
+    10.0.0.0/8 or
+    172.16.0.0/12 or
+    192.168.0.0/16
+  ) and
+  not destination.ip:(
+    10.0.0.0/8 or
+    127.0.0.0/8 or
+    169.254.0.0/16 or
+    172.16.0.0/12 or
+    192.0.0.0/24 or
+    192.0.0.0/29 or
+    192.0.0.8/32 or
+    192.0.0.9/32 or
+    192.0.0.10/32 or
+    192.0.0.170/32 or
+    192.0.0.171/32 or
+    192.0.2.0/24 or
+    192.31.196.0/24 or
+    192.52.193.0/24 or
+    192.168.0.0/16 or
+    192.88.99.0/24 or
+    224.0.0.0/4 or
+    100.64.0.0/10 or
+    192.175.48.0/24 or
+    198.18.0.0/15 or
+    198.51.100.0/24 or
+    203.0.113.0/24 or
+    240.0.0.0/4 or
+    "::1" or
+    "FE80::/10" or
+    "FF00::/8"
+  )
+'''
+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 SMB (Windows File Sharing) Activity to the Internet
+
+SMB, a protocol for sharing files and resources within trusted networks, is vulnerable when exposed to the Internet. Adversaries exploit it for unauthorized access or data theft. The detection rule identifies suspicious SMB traffic from internal IPs to external networks, flagging potential threats by monitoring specific ports and excluding known safe IP ranges.
+
+### Possible investigation steps
+
+- Review the source IP address from the alert to identify the internal system initiating the SMB traffic. Check if this IP belongs to a known device or user within the organization.
+- Investigate the destination IP address to determine if it is associated with any known malicious activity or if it belongs to a legitimate external service that might require SMB access.
+- Analyze network logs to identify any patterns or anomalies in the SMB traffic, such as unusual data transfer volumes or repeated access attempts, which could indicate malicious activity.
+- Check for any recent changes or updates on the source system that might explain the SMB traffic, such as new software installations or configuration changes.
+- Correlate the alert with other security events or logs, such as authentication logs or endpoint security alerts, to gather additional context and determine if this is part of a broader attack or isolated incident.
+- Consult threat intelligence sources to see if there are any known vulnerabilities or exploits related to the SMB traffic observed, which could provide insight into potential attack vectors.
+
+### False positive analysis
+
+- Internal testing environments may generate SMB traffic to external IPs for legitimate reasons. Identify and whitelist these IPs to prevent false positives.
+- Cloud services or remote backup solutions might use SMB for data transfer. Verify these services and add their IP ranges to the exception list if they are trusted.
+- VPN connections can sometimes appear as external traffic. Ensure that VPN IP ranges are included in the list of known safe IPs to avoid misclassification.
+- Misconfigured network devices might inadvertently route SMB traffic externally. Regularly audit network configurations and update the rule exceptions to include any legitimate device IPs.
+- Some third-party applications may use SMB for updates or data synchronization. Confirm the legitimacy of these applications and exclude their associated IPs from the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough review of firewall and network configurations to ensure SMB traffic is not allowed to the Internet, and block any unauthorized outbound SMB traffic on ports 139 and 445.
+- Perform a comprehensive scan of the isolated system for malware or unauthorized access tools, focusing on identifying any backdoors or persistence mechanisms.
+- Reset credentials and review access permissions for any accounts that may have been compromised or used in the suspicious activity.
+- Notify the security operations center (SOC) and relevant stakeholders about the incident for further analysis and potential escalation.
+- Implement additional monitoring and logging for SMB traffic to detect any future unauthorized attempts to access the Internet.
+- Review and update security policies and procedures to prevent similar incidents, ensuring that SMB services are only accessible within trusted network segments."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1190"
+name = "Exploit Public-Facing Application"
+reference = "https://attack.mitre.org/techniques/T1190/"
+
+
+[rule.threat.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1048"
+name = "Exfiltration Over Alternative Protocol"
+reference = "https://attack.mitre.org/techniques/T1048/"
+
+
+[rule.threat.tactic]
+id = "TA0010"
+name = "Exfiltration"
+reference = "https://attack.mitre.org/tactics/TA0010/"
+

nldcsc_elastic_rules/rules/network/initial_access_unsecure_elasticsearch_node.toml

@@ -0,0 +1,92 @@
+[metadata]
+creation_date = "2020/08/11"
+integration = ["network_traffic"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies Elasticsearch nodes that do not have Transport Layer Security (TLS), and/or lack authentication, and are
+accepting inbound network connections over the default Elasticsearch port.
+"""
+false_positives = [
+    """
+    If you have front-facing proxies that provide authentication and TLS, this rule would need to be tuned to eliminate
+    the source IP address of your reverse-proxy.
+    """,
+]
+from = "now-9m"
+index = ["packetbeat-*", "logs-network_traffic.*"]
+language = "lucene"
+license = "Elastic License v2"
+name = "Inbound Connection to an Unsecure Elasticsearch Node"
+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 Inbound Connection to an Unsecure Elasticsearch Node
+
+Elasticsearch is a powerful search and analytics engine often used for log and data analysis. When improperly configured without TLS or authentication, it becomes vulnerable to unauthorized access. Adversaries can exploit these weaknesses to gain initial access, exfiltrate data, or disrupt services. The detection rule identifies unsecured nodes by monitoring inbound HTTP traffic on the default port, flagging connections lacking authentication headers, thus highlighting potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the source IP address of the inbound connection to determine if it is from a known or trusted entity. Cross-reference with internal asset inventories or threat intelligence sources.
+- Examine the network traffic logs for any unusual patterns or repeated access attempts from the same source IP, which might indicate a brute force or scanning activity.
+- Check for any data exfiltration attempts by analyzing outbound traffic from the Elasticsearch node, focusing on large data transfers or connections to unfamiliar external IPs.
+- Investigate the absence of authentication headers in the HTTP requests to confirm if the Elasticsearch node is indeed misconfigured and lacks proper security controls.
+- Assess the configuration of the Elasticsearch node to ensure that TLS is enabled and authentication mechanisms are properly implemented to prevent unauthorized access.
+- Look for any other alerts or logs related to the same Elasticsearch node or source IP to identify potential coordinated attack activities or previous incidents.
+
+### False positive analysis
+
+- Internal monitoring tools or scripts that regularly check Elasticsearch node status without authentication can trigger false positives. Exclude these specific IP addresses or user agents from the rule to reduce noise.
+- Automated backup systems that interact with Elasticsearch nodes without using authentication headers might be flagged. Identify these systems and create exceptions based on their IP addresses or network segments.
+- Development or testing environments where Elasticsearch nodes are intentionally left unsecured for testing purposes can generate alerts. Use network segmentation or specific tags to differentiate these environments and exclude them from the rule.
+- Security scans or vulnerability assessments conducted by internal teams may access Elasticsearch nodes without authentication, leading to false positives. Whitelist the IP ranges used by these security tools to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected Elasticsearch node from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough review of access logs to identify any unauthorized access or data exfiltration attempts, focusing on connections lacking authentication headers.
+- Implement Transport Layer Security (TLS) and enable authentication mechanisms on the Elasticsearch node to secure communications and restrict access to authorized users only.
+- Reset credentials and API keys associated with the Elasticsearch node to prevent further unauthorized access using potentially compromised credentials.
+- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized access and steps taken to contain the threat.
+- Monitor the network for any signs of continued unauthorized access attempts or related suspicious activity, adjusting detection rules as necessary to capture similar threats.
+- Document the incident, including the response actions taken, and conduct a post-incident review to identify any gaps in security controls and improve future response efforts.
+
+## Setup
+
+This rule requires the addition of port `9200` and `send_all_headers` to the `HTTP` protocol configuration in `packetbeat.yml`. See the References section for additional configuration documentation."""
+references = [
+    "https://www.elastic.co/guide/en/elasticsearch/reference/current/configuring-security.html",
+    "https://www.elastic.co/guide/en/beats/packetbeat/current/packetbeat-http-options.html#_send_all_headers",
+]
+risk_score = 47
+rule_id = "31295df3-277b-4c56-a1fb-84e31b4222a9"
+severity = "medium"
+tags = ["Use Case: Threat Detection", "Tactic: Initial Access", "Domain: Endpoint", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+(event.dataset: network_traffic.http OR (event.category: network_traffic AND network.protocol: http)) AND
+    status:OK AND destination.port:9200 AND network.direction:inbound AND NOT http.response.headers.content-type:"image/x-icon" AND NOT
+    _exists_:http.request.headers.authorization
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1190"
+name = "Exploit Public-Facing Application"
+reference = "https://attack.mitre.org/techniques/T1190/"
+
+
+[rule.threat.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+

nldcsc_elastic_rules/rules/network/lateral_movement_dns_server_overflow.toml

@@ -0,0 +1,92 @@
+[metadata]
+creation_date = "2020/07/16"
+integration = ["network_traffic"]
+maturity = "production"
+updated_date = "2024/05/21"
+
+[rule]
+author = ["Elastic"]
+description = """
+Specially crafted DNS requests can manipulate a known overflow vulnerability in some Windows DNS servers, resulting in
+Remote Code Execution (RCE) or a Denial of Service (DoS) from crashing the service.
+"""
+false_positives = [
+    """
+    Environments that leverage DNS responses over 60k bytes will result in false positives - if this traffic is
+    predictable and expected, it should be filtered out. Additionally, this detection rule could be triggered by an
+    authorized vulnerability scan or compromise assessment.
+    """,
+]
+index = ["packetbeat-*", "filebeat-*", "logs-network_traffic.*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Abnormally Large DNS Response"
+note = """## Triage and analysis
+
+### Investigating Abnormally Large DNS Response
+
+Detection alerts from this rule indicate possible anomalous activity around large byte DNS responses from a Windows DNS server. This detection rule was created based on activity represented in exploitation of vulnerability (CVE-2020-1350) also known as [SigRed](https://www.elastic.co/blog/detection-rules-for-sigred-vulnerability) during July 2020.
+
+#### Possible investigation steps
+
+- This specific rule is sourced from network log activity such as DNS or network level data. It's important to validate the source of the incoming traffic and determine if this activity has been observed previously within an environment.
+- Activity can be further investigated and validated by reviewing any associated Intrusion Detection Signatures (IDS) alerts.
+- Further examination can include a review of the `dns.question_type` network fieldset with a protocol analyzer, such as Zeek, Packetbeat, or Suricata, for `SIG` or `RRSIG` data.
+- Validate the patch level and OS of the targeted DNS server to validate the observed activity was not large-scale internet vulnerability scanning.
+- Validate that the source of the network activity was not from an authorized vulnerability scan or compromise assessment.
+
+#### False positive analysis
+
+- Based on this rule, which looks for a threshold of 60k bytes, it is possible for activity to be generated under 65k bytes and related to legitimate behavior. In packet capture files received by the [SANS Internet Storm Center](https://isc.sans.edu/forums/diary/PATCH+NOW+SIGRed+CVE20201350+Microsoft+DNS+Server+Vulnerability/26356/), byte responses were all observed as greater than 65k bytes.
+- This activity can be triggered by compliance/vulnerability scanning or compromise assessment; it's important to determine the source of the activity and potentially allowlist the source host.
+
+### Related rules
+
+- Unusual Child Process of dns.exe - 8c37dc0e-e3ac-4c97-8aa0-cf6a9122de45
+- Unusual File Modification by dns.exe - c7ce36c0-32ff-4f9a-bfc2-dcb242bf99f9
+
+### Response and remediation
+
+- Initiate the incident response process based on the outcome of the triage.
+- Ensure that you have deployed the latest Microsoft [Security Update](https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1350) (Monthly Rollup or Security Only) and restarted the patched machines. If unable to patch immediately, Microsoft [released](https://support.microsoft.com/en-us/help/4569509/windows-dns-server-remote-code-execution-vulnerability) a registry-based workaround that doesn’t require a restart. This can be used as a temporary solution before the patch is applied.
+- Maintain backups of your critical systems to aid in quick recovery.
+- Perform routine vulnerability scans of your systems, monitor [CISA advisories](https://us-cert.cisa.gov/ncas/current-activity) and patch identified vulnerabilities.
+- If you observe a true positive, implement a remediation plan and monitor host-based artifacts for additional post-exploitation behavior.
+"""
+references = [
+    "https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/",
+    "https://msrc-blog.microsoft.com/2020/07/14/july-2020-security-update-cve-2020-1350-vulnerability-in-windows-domain-name-system-dns-server/",
+    "https://github.com/maxpl0it/CVE-2020-1350-DoS",
+    "https://www.elastic.co/security-labs/detection-rules-for-sigred-vulnerability",
+]
+risk_score = 47
+rule_id = "11013227-0301-4a8c-b150-4db924484475"
+severity = "medium"
+tags = [
+    "Use Case: Threat Detection",
+    "Tactic: Lateral Movement",
+    "Resources: Investigation Guide",
+    "Use Case: Vulnerability",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+(event.dataset: network_traffic.dns or (event.category: (network or network_traffic) and destination.port: 53)) and
+  (event.dataset:zeek.dns or type:dns or event.type:connection) and network.bytes > 60000
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1210"
+name = "Exploitation of Remote Services"
+reference = "https://attack.mitre.org/techniques/T1210/"
+
+
+[rule.threat.tactic]
+id = "TA0008"
+name = "Lateral Movement"
+reference = "https://attack.mitre.org/tactics/TA0008/"
+

nldcsc_elastic_rules/rules/promotions/credential_access_endgame_cred_dumping_detected.toml

@@ -0,0 +1,91 @@
+[metadata]
+creation_date = "2020/02/18"
+maturity = "production"
+promotion = true
+updated_date = "2025/03/21"
+
+[rule]
+author = ["Elastic"]
+description = """
+Elastic Endgame detected Credential Dumping. Click the Elastic Endgame icon in the event.module column or the link in
+the rule.reference column for additional information.
+"""
+from = "now-2m"
+index = ["endgame-*"]
+interval = "1m"
+language = "kuery"
+license = "Elastic License v2"
+max_signals = 1000
+name = "Credential Dumping - Detected - Elastic Endgame"
+risk_score = 73
+rule_id = "571afc56-5ed9-465d-a2a9-045f099f6e7e"
+setup = """## Setup
+
+### Additional notes
+
+For information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).
+"""
+severity = "high"
+tags = ["Data Source: Elastic Endgame", "Use Case: Threat Detection", "Tactic: Credential Access", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:cred_theft_event or endgame.event_subtype_full:cred_theft_event)
+'''
+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 Credential Dumping - Detected - Elastic Endgame
+
+Elastic Endgame is a security solution that monitors and detects suspicious activities, such as credential dumping, which is a technique used by adversaries to extract sensitive authentication data. Attackers exploit this to gain unauthorized access to systems. The detection rule identifies such threats by analyzing alerts and specific event actions related to credential theft, ensuring timely threat detection and response.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of event.kind:alert and event.module:endgame, ensuring the alert is related to the Elastic Endgame detection.
+- Examine the event.action and endgame.event_subtype_full fields for the value cred_theft_event to understand the specific credential theft activity detected.
+- Check the associated host and user information to identify the potentially compromised system and user accounts.
+- Investigate the timeline of events leading up to and following the alert to identify any suspicious activities or patterns that may indicate further compromise.
+- Correlate the alert with other security events or logs to determine if this is part of a larger attack or isolated incident.
+- Assess the risk score and severity to prioritize the response and determine if immediate action is required to contain the threat.
+- Consult the MITRE ATT&CK framework for additional context on the T1003 technique to understand potential attacker methods and improve defensive measures.
+
+### False positive analysis
+
+- Routine administrative tasks that involve legitimate credential access tools may trigger alerts. Users can create exceptions for known administrative accounts or tools that are frequently used in these tasks.
+- Security software updates or scans that access credential stores might be flagged. Exclude these processes by identifying their specific event actions and adding them to the exception list.
+- Automated scripts for system maintenance that require credential access could be misidentified. Review and whitelist these scripts by their unique identifiers or execution paths.
+- Legitimate software installations that require elevated privileges may cause alerts. Monitor and exclude these installation processes by verifying their source and purpose.
+- Regularly scheduled backups that access credential data might be detected. Ensure these backup processes are recognized and excluded by specifying their event actions in the rule configuration.
+
+### Response and remediation
+
+- Isolate the affected system immediately to prevent further unauthorized access and lateral movement within the network.
+- Terminate any suspicious processes identified as part of the credential dumping activity to halt ongoing malicious actions.
+- Change all potentially compromised credentials, prioritizing those with elevated privileges, to mitigate unauthorized access risks.
+- Conduct a thorough review of access logs and system events to identify any additional compromised accounts or systems.
+- Restore affected systems from a known good backup to ensure the integrity of the system and data.
+- Implement enhanced monitoring on the affected systems and accounts to detect any signs of recurring or related malicious activity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional containment or remediation actions are necessary."""
+
+
+[[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/promotions/credential_access_endgame_cred_dumping_prevented.toml

@@ -0,0 +1,90 @@
+[metadata]
+creation_date = "2020/02/18"
+maturity = "production"
+promotion = true
+updated_date = "2025/03/21"
+
+[rule]
+author = ["Elastic"]
+description = """
+Elastic Endgame prevented Credential Dumping. Click the Elastic Endgame icon in the event.module column or the link in
+the rule.reference column for additional information.
+"""
+from = "now-2m"
+index = ["endgame-*"]
+interval = "1m"
+language = "kuery"
+license = "Elastic License v2"
+max_signals = 1000
+name = "Credential Dumping - Prevented - Elastic Endgame"
+risk_score = 47
+rule_id = "db8c33a8-03cd-4988-9e2c-d0a4863adb13"
+setup = """## Setup
+
+### Additional notes
+
+For information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).
+"""
+severity = "medium"
+tags = ["Data Source: Elastic Endgame", "Use Case: Threat Detection", "Tactic: Credential Access", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:cred_theft_event or endgame.event_subtype_full:cred_theft_event)
+'''
+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 Credential Dumping - Prevented - Elastic Endgame
+
+Elastic Endgame is a security solution that proactively prevents credential dumping, a technique where attackers extract sensitive authentication data from systems. Adversaries exploit this to gain unauthorized access to networks. The detection rule identifies prevention alerts by monitoring specific event actions and metadata, signaling attempts to steal credentials, thus enabling timely threat mitigation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of event.kind:alert and event.module:endgame, ensuring the alert is related to Elastic Endgame's prevention of credential dumping.
+- Examine the event.action and endgame.event_subtype_full fields for the value cred_theft_event to understand the specific credential theft attempt that was prevented.
+- Investigate the source and destination systems involved in the alert to identify potential points of compromise or targeted systems.
+- Check for any related alerts or events in the same timeframe that might indicate a coordinated attack or further attempts at credential access.
+- Assess the user accounts involved in the alert to determine if they have been compromised or if there are any unauthorized access attempts.
+- Review the risk score and severity to prioritize the investigation and response actions based on the potential impact on the organization.
+
+### False positive analysis
+
+- Routine administrative tools or scripts that access credential stores may trigger alerts. Review and whitelist these tools if they are verified as non-threatening.
+- Security software performing legitimate credential checks can be mistaken for credential dumping. Identify and exclude these processes from alert generation.
+- Automated backup systems accessing credential data for legitimate purposes might be flagged. Ensure these systems are recognized and excluded from the rule.
+- Regular system maintenance activities that involve credential verification could cause false positives. Document and exclude these activities if they are part of standard operations.
+- User behavior analytics might misinterpret legitimate user actions as credential theft. Implement user behavior baselines to reduce such false positives.
+
+### Response and remediation
+
+- Isolate the affected system immediately to prevent further unauthorized access or lateral movement within the network.
+- Terminate any suspicious processes identified as part of the credential dumping attempt to halt ongoing malicious activities.
+- Change all potentially compromised credentials, especially those with elevated privileges, to prevent unauthorized access using stolen credentials.
+- Conduct a thorough review of access logs and event data to identify any additional systems that may have been targeted or compromised.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation.
+- Implement additional monitoring on the affected system and related network segments to detect any further suspicious activities or attempts at credential theft.
+- Review and update endpoint protection configurations to ensure that similar threats are detected and prevented in the future, leveraging insights from the MITRE ATT&CK framework."""
+
+
+[[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/"
+