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

nldcsc_elastic_rules/rules/linux/credential_access_potential_linux_local_account_bruteforce.toml

@@ -0,0 +1,118 @@
+[metadata]
+creation_date = "2023/07/26"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/02/04"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies multiple consecutive login attempts executed by one process targeting a local linux user account within a
+short time interval. Adversaries might brute force login attempts across different users with a default wordlist or a
+set of customly crafted passwords in an attempt to gain access to these accounts.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.process*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential Linux Local Account Brute Force Detected"
+risk_score = 47
+rule_id = "835c0622-114e-40b5-a346-f843ea5d01f1"
+setup = """## Setup
+
+This rule requires data coming in from Elastic Defend.
+
+### Elastic Defend Integration Setup
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+#### Prerequisite Requirements:
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+
+#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
+For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
+- Click "Save and Continue".
+- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
+For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+type = "eql"
+
+query = '''
+sequence by host.id, process.parent.executable, user.id with maxspan=1s
+  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "su" and
+   not process.parent.name in (
+     "bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "clickhouse-server", "ma", "gitlab-runner",
+     "updatedb.findutils", "cron", "perl", "sudo", "java", "cloud-app-identify", "ambari-sudo.sh"
+   )
+  ] with runs=10
+'''
+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 Linux Local Account Brute Force Detected
+
+In Linux environments, the 'su' command is used to switch user accounts, often requiring a password. Adversaries exploit this by attempting numerous logins with various passwords to gain unauthorized access. The detection rule identifies suspicious activity by monitoring rapid, repeated 'su' command executions from a single process, excluding common legitimate parent processes, indicating potential brute force attempts.
+
+### Possible investigation steps
+
+- Review the process execution details to identify the parent process of the 'su' command, focusing on any unusual or unauthorized parent processes not listed in the exclusion list.
+- Analyze the frequency and pattern of the 'su' command executions from the identified process to determine if they align with typical user behavior or indicate a brute force attempt.
+- Check the user account targeted by the 'su' command attempts to assess if it is a high-value or sensitive account that might be of interest to adversaries.
+- Investigate the source host (host.id) to determine if there are any other suspicious activities or anomalies associated with it, such as unusual network connections or other security alerts.
+- Correlate the event timestamps with other logs or alerts to identify any concurrent suspicious activities that might indicate a coordinated attack effort.
+
+### False positive analysis
+
+- Legitimate administrative scripts or automation tools may trigger the rule if they execute the 'su' command frequently. To mitigate this, identify and whitelist these scripts or tools by adding their parent process names to the exclusion list.
+- Scheduled tasks or cron jobs that require switching users might be misidentified as brute force attempts. Review and exclude these tasks by specifying their parent process names in the exclusion criteria.
+- Development or testing environments where frequent user switching is part of normal operations can generate false positives. Consider excluding these environments from monitoring or adjust the detection threshold to better fit the operational context.
+- Continuous integration or deployment systems that use the 'su' command for user context switching can be mistaken for brute force attempts. Add these systems' parent process names to the exclusion list to prevent false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected host to prevent further unauthorized access or lateral movement within the network.
+- Terminate the suspicious process identified by the detection rule to stop ongoing brute force attempts.
+- Reset passwords for the targeted user accounts to prevent unauthorized access using potentially compromised credentials.
+- Review and update the password policy to enforce strong, complex passwords and consider implementing account lockout mechanisms after a certain number of failed login attempts.
+- Conduct a thorough review of the affected system for any signs of successful unauthorized access or additional malicious activity, such as new user accounts or scheduled tasks.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected.
+- Enhance monitoring and logging on the affected host and similar systems to detect and respond to future brute force attempts more effectively."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1110"
+name = "Brute Force"
+reference = "https://attack.mitre.org/techniques/T1110/"
+[[rule.threat.technique.subtechnique]]
+id = "T1110.001"
+name = "Password Guessing"
+reference = "https://attack.mitre.org/techniques/T1110/001/"
+
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+

nldcsc_elastic_rules/rules/linux/credential_access_potential_linux_ssh_bruteforce_external.toml

@@ -0,0 +1,117 @@
+[metadata]
+creation_date = "2022/09/14"
+integration = ["system"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies multiple external consecutive login failures targeting a user account from the same source address within a
+short time interval. Adversaries will often brute force login attempts across multiple users with a common or known
+password, in an attempt to gain access to these accounts.
+"""
+from = "now-9m"
+index = ["filebeat-*", "logs-system.auth-*"]
+language = "eql"
+license = "Elastic License v2"
+max_signals = 5
+name = "Potential External Linux SSH Brute Force Detected"
+note = """## Triage and analysis
+
+### Investigating Potential External Linux SSH Brute Force Detected
+
+The rule identifies consecutive SSH login failures targeting a user account from the same source IP address to the same target host indicating brute force login attempts.
+
+This rule will generate a lot of noise for systems with a front-facing SSH service, as adversaries scan the internet for remotely accessible SSH services and try to brute force them to gain unauthorized access. 
+
+In case this rule generates too much noise and external brute forcing is of not much interest, consider turning this rule off and enabling "Potential Internal Linux SSH Brute Force Detected" to detect internal brute force attempts.
+
+#### Possible investigation steps
+
+- Investigate the login failure user name(s).
+- Investigate the source IP address of the failed ssh login attempt(s).
+- Investigate other alerts associated with the user/host during the past 48 hours.
+- Identify the source and the target computer and their roles in the IT environment.
+
+### False positive analysis
+
+- Authentication misconfiguration or obsolete credentials.
+- Service account password expired.
+- Infrastructure or availability issue.
+
+### Related Rules
+
+- Potential Internal Linux SSH Brute Force Detected - 1c27fa22-7727-4dd3-81c0-de6da5555feb
+- Potential SSH Password Guessing - 8cb84371-d053-4f4f-bce0-c74990e28f28
+
+### 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.
+- 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.
+- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
+- 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).
+"""
+risk_score = 21
+rule_id = "fa210b61-b627-4e5e-86f4-17e8270656ab"
+setup = """## Setup
+
+This rule requires data coming in from Filebeat.
+
+### Filebeat Setup
+Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing.
+
+#### The following steps should be executed in order to add the Filebeat on a Linux System:
+- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
+- To install the APT and YUM repositories follow the setup instructions in this [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html).
+- To run Filebeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html).
+- To run Filebeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html).
+- For quick start information for Filebeat refer to the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html).
+- For complete “Setup and Run Filebeat” information refer to the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html).
+
+#### Rule Specific Setup Note
+- This rule requires the “Filebeat System Module” to be enabled.
+- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions.
+- To run the system module of Filebeat on Linux follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html).
+"""
+severity = "low"
+tags = ["Domain: Endpoint", "OS: Linux", "Use Case: Threat Detection", "Tactic: Credential Access", "Resources: Investigation Guide"]
+type = "eql"
+
+query = '''
+sequence by host.id, source.ip, user.name with maxspan=15s
+  [ authentication where host.os.type == "linux" and 
+   event.action in ("ssh_login", "user_login") and event.outcome == "failure" and
+   not cidrmatch(source.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24",
+       "192.0.0.0/29", "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32",
+       "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4",
+       "100.64.0.0/10", "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", 
+       "::1", "FE80::/10", "FF00::/8") ] with runs = 10
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1110"
+name = "Brute Force"
+reference = "https://attack.mitre.org/techniques/T1110/"
+[[rule.threat.technique.subtechnique]]
+id = "T1110.001"
+name = "Password Guessing"
+reference = "https://attack.mitre.org/techniques/T1110/001/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1110.003"
+name = "Password Spraying"
+reference = "https://attack.mitre.org/techniques/T1110/003/"
+
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+

nldcsc_elastic_rules/rules/linux/credential_access_potential_linux_ssh_bruteforce_internal.toml

@@ -0,0 +1,113 @@
+[metadata]
+creation_date = "2023/02/21"
+integration = ["system"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies multiple internal consecutive login failures targeting a user account from the same source address within a
+short time interval. Adversaries will often brute force login attempts across multiple users with a common or known
+password, in an attempt to gain access to these accounts.
+"""
+from = "now-9m"
+index = ["filebeat-*", "logs-system.auth-*"]
+language = "eql"
+license = "Elastic License v2"
+max_signals = 5
+name = "Potential Internal Linux SSH Brute Force Detected"
+note = """## Triage and analysis
+
+### Investigating Potential Internal Linux SSH Brute Force Detected
+
+The rule identifies consecutive internal SSH login failures targeting a user account from the same source IP address to the same target host indicating brute force login attempts.
+
+#### Possible investigation steps
+
+- Investigate the login failure user name(s).
+- Investigate the source IP address of the failed ssh login attempt(s).
+- Investigate other alerts associated with the user/host during the past 48 hours.
+- Identify the source and the target computer and their roles in the IT environment.
+
+### False positive analysis
+
+- Authentication misconfiguration or obsolete credentials.
+- Service account password expired.
+- Infrastructure or availability issue.
+
+### Related Rules
+
+- Potential External Linux SSH Brute Force Detected - fa210b61-b627-4e5e-86f4-17e8270656ab
+- Potential SSH Password Guessing - 8cb84371-d053-4f4f-bce0-c74990e28f28
+
+### 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.
+- 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.
+- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
+- 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).
+"""
+risk_score = 47
+rule_id = "1c27fa22-7727-4dd3-81c0-de6da5555feb"
+setup = """## Setup
+
+This rule requires data coming in from Filebeat.
+
+### Filebeat Setup
+Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing.
+
+#### The following steps should be executed in order to add the Filebeat on a Linux System:
+- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
+- To install the APT and YUM repositories follow the setup instructions in this [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html).
+- To run Filebeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html).
+- To run Filebeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html).
+- For quick start information for Filebeat refer to the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html).
+- For complete “Setup and Run Filebeat” information refer to the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html).
+
+#### Rule Specific Setup Note
+- This rule requires the “Filebeat System Module” to be enabled.
+- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions.
+- To run the system module of Filebeat on Linux follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html).
+"""
+severity = "medium"
+tags = ["Domain: Endpoint", "OS: Linux", "Use Case: Threat Detection", "Tactic: Credential Access", "Resources: Investigation Guide"]
+type = "eql"
+
+query = '''
+sequence by host.id, source.ip, user.name with maxspan=15s
+  [ authentication where host.os.type == "linux" and 
+   event.action in ("ssh_login", "user_login") and event.outcome == "failure" and
+   cidrmatch(source.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24",
+       "192.0.0.0/29", "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32",
+       "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4",
+       "100.64.0.0/10", "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", 
+       "::1", "FE80::/10", "FF00::/8") ] with runs = 10
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1110"
+name = "Brute Force"
+reference = "https://attack.mitre.org/techniques/T1110/"
+[[rule.threat.technique.subtechnique]]
+id = "T1110.001"
+name = "Password Guessing"
+reference = "https://attack.mitre.org/techniques/T1110/001/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1110.003"
+name = "Password Spraying"
+reference = "https://attack.mitre.org/techniques/T1110/003/"
+
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+

nldcsc_elastic_rules/rules/linux/credential_access_potential_successful_linux_ftp_bruteforce.toml

@@ -0,0 +1,136 @@
+[metadata]
+creation_date = "2023/07/06"
+integration = ["auditd_manager"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+An FTP (file transfer protocol) brute force attack is a method where an attacker systematically tries different
+combinations of usernames and passwords to gain unauthorized access to an FTP server, and if successful, the impact can
+include unauthorized data access, manipulation, or theft, compromising the security and integrity of the server and
+potentially exposing sensitive information. This rule identifies multiple consecutive authentication failures targeting
+a specific user account from the same source address and within a short time interval, followed by a successful
+authentication.
+"""
+from = "now-9m"
+index = ["auditbeat-*", "logs-auditd_manager.auditd-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential Successful Linux FTP Brute Force Attack Detected"
+risk_score = 47
+rule_id = "66712812-e7f2-4a1d-bbda-dd0b5cf20c5d"
+setup = """## Setup
+
+This rule requires data coming in from one of the following integrations:
+- Auditbeat
+- Auditd Manager
+
+### Auditbeat Setup
+Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations.
+
+#### The following steps should be executed in order to add the Auditbeat on a Linux System:
+- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
+- To install the APT and YUM repositories follow the setup instructions in this [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html).
+- To run Auditbeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html).
+- To run Auditbeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html).
+- For complete “Setup and Run Auditbeat” information refer to the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html).
+
+### Auditd Manager Integration Setup
+The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.
+Auditd Manager provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system.
+
+#### The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" on a Linux System:
+- Go to the Kibana home page and click “Add integrations”.
+- In the query bar, search for “Auditd Manager” and select the integration to see more details about it.
+- Click “Add Auditd Manager”.
+- Configure the integration name and optionally add a description.
+- Review optional and advanced settings accordingly.
+- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.
+- Click “Save and Continue”.
+- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).
+
+#### Rule Specific Setup Note
+Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.
+However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from.
+- For this detection rule no additional audit rules are required to be added to the integration.
+"""
+severity = "medium"
+tags = [
+    "Data Source: Auditd Manager",
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Resources: Investigation Guide",
+]
+type = "eql"
+
+query = '''
+sequence by host.id, auditd.data.addr, related.user with maxspan=5s
+  [authentication where host.os.type == "linux" and event.action == "authenticated" and
+   auditd.data.terminal == "ftp" and event.outcome == "failure" and auditd.data.addr != null and
+   auditd.data.addr != "0.0.0.0" and auditd.data.addr != "::"] with runs=10
+  [authentication where host.os.type == "linux" and event.action  == "authenticated" and
+   auditd.data.terminal == "ftp" and event.outcome == "success" and auditd.data.addr != null and
+   auditd.data.addr != "0.0.0.0" and auditd.data.addr != "::"] | tail 1
+'''
+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 Successful Linux FTP Brute Force Attack Detected
+
+FTP is a protocol used for transferring files between systems, often requiring authentication. Adversaries exploit this by attempting numerous username-password combinations to gain unauthorized access, potentially leading to data breaches. The detection rule identifies a pattern of repeated failed login attempts from a single source, followed by a successful login, indicating a possible brute force attack.
+
+### Possible investigation steps
+
+- Review the source IP address (auditd.data.addr) involved in the failed and successful login attempts to determine if it is known or associated with previous malicious activity.
+- Analyze the timeline of the failed login attempts followed by the successful login to assess the likelihood of a brute force attack, considering the maxspan of 5 seconds.
+- Check the user account (related.user) targeted by the login attempts to determine if it is a high-value account or has been involved in previous security incidents.
+- Investigate the host (host.id) where the login attempts occurred to identify any other suspicious activities or anomalies around the time of the alert.
+- Correlate the detected activity with other logs or alerts from the same time period to identify potential lateral movement or further compromise within the network.
+
+### False positive analysis
+
+- Repeated failed logins from automated scripts or monitoring tools can trigger false positives. Identify and whitelist IP addresses of known internal systems or services that perform regular FTP checks.
+- Users with incorrect credentials saved in FTP clients may cause multiple failed attempts before a successful login. Educate users on updating saved credentials and consider excluding specific user accounts from the rule if they frequently trigger alerts.
+- Scheduled tasks or cron jobs that attempt to connect with outdated credentials can result in false positives. Review and update scheduled tasks to ensure they use current credentials, and exclude these tasks from monitoring if they are non-threatening.
+- High-volume legitimate FTP traffic from trusted partners or vendors might mimic brute force patterns. Establish a list of trusted external IP addresses and exclude them from the rule to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Reset the compromised user account's password and any other accounts that may have been accessed using the same credentials.
+- Review and analyze the logs from the affected system to identify any unauthorized changes or data access that occurred during the breach.
+- Implement IP blocking or rate limiting for the source address identified in the alert to prevent further brute force attempts from the same origin.
+- Conduct a thorough security assessment of the FTP server configuration to ensure it adheres to best practices, such as disabling anonymous access and enforcing strong password policies.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems were affected.
+- Enhance monitoring and alerting for similar brute force patterns by ensuring that detection rules are tuned to capture variations in attack techniques."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1110"
+name = "Brute Force"
+reference = "https://attack.mitre.org/techniques/T1110/"
+[[rule.threat.technique.subtechnique]]
+id = "T1110.001"
+name = "Password Guessing"
+reference = "https://attack.mitre.org/techniques/T1110/001/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1110.003"
+name = "Password Spraying"
+reference = "https://attack.mitre.org/techniques/T1110/003/"
+
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+

nldcsc_elastic_rules/rules/linux/credential_access_potential_successful_linux_rdp_bruteforce.toml

@@ -0,0 +1,135 @@
+[metadata]
+creation_date = "2023/07/06"
+integration = ["auditd_manager"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+An RDP (Remote Desktop Protocol) brute force attack involves an attacker repeatedly attempting various username and
+password combinations to gain unauthorized access to a remote computer via RDP, and if successful, the potential impact
+can include unauthorized control over the compromised system, data theft, or the ability to launch further attacks
+within the network, jeopardizing the security and confidentiality of the targeted system and potentially compromising
+the entire network infrastructure. This rule identifies multiple consecutive authentication failures targeting a
+specific user account within a short time interval, followed by a successful authentication.
+"""
+from = "now-9m"
+index = ["auditbeat-*", "logs-auditd_manager.auditd-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential Successful Linux RDP Brute Force Attack Detected"
+risk_score = 47
+rule_id = "521fbe5c-a78d-4b6b-a323-f978b0e4c4c0"
+setup = """## Setup
+
+This rule requires data coming in from one of the following integrations:
+- Auditbeat
+- Auditd Manager
+
+### Auditbeat Setup
+Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations.
+
+#### The following steps should be executed in order to add the Auditbeat on a Linux System:
+- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
+- To install the APT and YUM repositories follow the setup instructions in this [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html).
+- To run Auditbeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html).
+- To run Auditbeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html).
+- For complete “Setup and Run Auditbeat” information refer to the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html).
+
+### Auditd Manager Integration Setup
+The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.
+Auditd Manager provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system.
+
+#### The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" on a Linux System:
+- Go to the Kibana home page and click “Add integrations”.
+- In the query bar, search for “Auditd Manager” and select the integration to see more details about it.
+- Click “Add Auditd Manager”.
+- Configure the integration name and optionally add a description.
+- Review optional and advanced settings accordingly.
+- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.
+- Click “Save and Continue”.
+- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).
+
+#### Rule Specific Setup Note
+Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.
+However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from.
+- For this detection rule no additional audit rules are required to be added to the integration.
+"""
+severity = "medium"
+tags = [
+    "Data Source: Auditd Manager",
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Resources: Investigation Guide",
+]
+type = "eql"
+
+query = '''
+sequence by host.id, related.user with maxspan=5s
+  [authentication where host.os.type == "linux" and event.action == "authenticated" and
+   auditd.data.terminal : "*rdp*" and event.outcome == "failure"] with runs=10
+  [authentication where host.os.type == "linux" and event.action  == "authenticated" and
+   auditd.data.terminal : "*rdp*" and event.outcome == "success"] | tail 1
+'''
+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 Successful Linux RDP Brute Force Attack Detected
+
+Remote Desktop Protocol (RDP) enables users to connect to and control remote systems, often used for administrative tasks. Adversaries exploit RDP by attempting numerous login attempts to gain unauthorized access, potentially leading to data breaches or further network infiltration. The detection rule identifies a pattern of failed login attempts followed by a successful one, indicating a possible brute force attack, thus alerting security teams to investigate and mitigate the threat.
+
+### Possible investigation steps
+
+- Review the authentication logs on the affected Linux host to identify the specific user account targeted by the failed and successful login attempts, focusing on entries with event.action as "authenticated" and auditd.data.terminal containing "*rdp*".
+- Analyze the source IP addresses associated with the failed and successful login attempts to determine if they originate from known or suspicious locations.
+- Check for any unusual activity or changes on the compromised system following the successful login, such as new user accounts, modified files, or unexpected network connections.
+- Correlate the timestamps of the authentication events with other security logs to identify any concurrent suspicious activities or anomalies within the network.
+- Investigate the user account's recent activity and permissions to assess potential impacts and determine if the account has been used for unauthorized access or lateral movement within the network.
+- Evaluate the risk score and severity of the alert in the context of the organization's security posture and prioritize response actions accordingly.
+
+### False positive analysis
+
+- Legitimate administrative activities may trigger the rule if administrators frequently log in using RDP for system management. To handle this, create exceptions for known administrator accounts or IP addresses that regularly perform these tasks.
+- Automated scripts or services that use RDP for routine operations can cause false positives. Identify these scripts and whitelist their associated user accounts or IPs to prevent unnecessary alerts.
+- Scheduled tasks or cron jobs that involve RDP connections might be misinterpreted as brute force attempts. Exclude these tasks by specifying their user accounts or terminal identifiers in the rule configuration.
+- Security testing or penetration testing activities can mimic brute force patterns. Coordinate with security teams to exclude these activities during testing periods by temporarily adjusting the rule parameters or adding exceptions for testing IP ranges.
+
+### Response and remediation
+
+- Immediately isolate the affected Linux host from the network to prevent further unauthorized access or lateral movement by the attacker.
+- Reset the compromised user account's password and any other accounts that may have been accessed using the same credentials to prevent further unauthorized access.
+- Conduct a thorough review of the affected system for any signs of additional compromise, such as unauthorized software installations or changes to system configurations, and remove any malicious artifacts.
+- Implement multi-factor authentication (MFA) for RDP access to enhance security and reduce the risk of future brute force attacks.
+- Review and tighten firewall rules to restrict RDP access to only trusted IP addresses and consider using a VPN for remote access.
+- Monitor the network for any unusual activity or further attempts to exploit RDP, using enhanced logging and alerting mechanisms.
+- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and to ensure comprehensive remediation and recovery actions are taken."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1110"
+name = "Brute Force"
+reference = "https://attack.mitre.org/techniques/T1110/"
+[[rule.threat.technique.subtechnique]]
+id = "T1110.001"
+name = "Password Guessing"
+reference = "https://attack.mitre.org/techniques/T1110/001/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1110.003"
+name = "Password Spraying"
+reference = "https://attack.mitre.org/techniques/T1110/003/"
+
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+