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

nldcsc_elastic_rules/rules/ml/credential_access_ml_auth_spike_in_logon_events_from_a_source_ip.toml

@@ -0,0 +1,162 @@
+[metadata]
+creation_date = "2021/06/10"
+integration = ["auditd_manager", "endpoint", "system"]
+maturity = "production"
+updated_date = "2024/06/18"
+
+[rule]
+anomaly_threshold = 75
+author = ["Elastic"]
+description = """
+A machine learning job found an unusually large spike in successful authentication events from a particular source IP
+address. This can be due to password spraying, user enumeration or brute force activity.
+"""
+false_positives = [
+    """
+    Build servers and CI systems can sometimes trigger this alert. Security test cycles that include brute force or
+    password spraying activities may trigger this alert.
+    """,
+]
+from = "now-30m"
+interval = "15m"
+license = "Elastic License v2"
+machine_learning_job_id = "auth_high_count_logon_events_for_a_source_ip"
+name = "Spike in Successful Logon Events from a Source IP"
+setup = """## Setup
+
+This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:
+- Elastic Defend
+- Auditd Manager
+- System
+
+### Anomaly Detection Setup
+
+Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).
+
+### 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 to your 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/current/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).
+
+### 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" to your 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.
+
+### System Integration Setup
+The System integration allows you to collect system logs and metrics from your servers with Elastic Agent.
+
+#### The following steps should be executed in order to add the Elastic Agent System integration "system" to your system:
+- Go to the Kibana home page and click “Add integrations”.
+- In the query bar, search for “System” and select the integration to see more details about it.
+- Click “Add System”.
+- Configure the integration name and optionally add a description.
+- Review optional and advanced settings accordingly.
+- Add the newly installed “system” to an existing or a new agent policy, and deploy the agent on your system from which system log files are desirable.
+- Click “Save and Continue”.
+- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/system).
+"""
+note = """## Triage and analysis
+
+### Investigating Spike in Successful Logon Events from a Source IP
+
+This rule uses a machine learning job to detect a substantial spike in successful authentication events. This could indicate post-exploitation activities that aim to test which hosts, services, and other resources the attacker can access with the compromised credentials.
+
+#### Possible investigation steps
+
+- Identify the specifics of the involved assets, such as role, criticality, and associated users.
+- Check if the authentication comes from different sources.
+- Use the historical data available to determine if the same behavior happened in the past.
+- Investigate other alerts associated with the involved users during the past 48 hours.
+- Check whether the involved credentials are used in automation or scheduled tasks.
+- If this activity is suspicious, contact the account owner and confirm whether they are aware of it.
+
+### False positive analysis
+
+- Understand the context of the authentications by contacting the asset owners. If this activity is related to a new business process or newly implemented (approved) technology, consider adding exceptions — preferably with a combination of user and source conditions.
+
+### 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.
+- 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://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
+risk_score = 21
+rule_id = "e26aed74-c816-40d3-a810-48d6fbd8b2fd"
+severity = "low"
+tags = [
+    "Use Case: Identity and Access Audit",
+    "Use Case: Threat Detection",
+    "Rule Type: ML",
+    "Rule Type: Machine Learning",
+    "Tactic: Credential Access",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
+type = "machine_learning"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1110"
+name = "Brute Force"
+reference = "https://attack.mitre.org/techniques/T1110/"
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+[[rule.threat.technique.subtechnique]]
+id = "T1078.002"
+name = "Domain Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/002/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1078.003"
+name = "Local Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/003/"
+
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/ml/credential_access_ml_linux_anomalous_metadata_process.toml

@@ -0,0 +1,140 @@
+[metadata]
+creation_date = "2020/09/22"
+integration = ["auditd_manager", "endpoint"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+anomaly_threshold = 50
+author = ["Elastic"]
+description = """
+Looks for anomalous access to the metadata service by an unusual process. The metadata service may be targeted in order
+to harvest credentials or user data scripts containing secrets.
+"""
+false_positives = [
+    """
+    A newly installed program or one that runs very rarely as part of a monthly or quarterly workflow could trigger this
+    detection rule.
+    """,
+]
+from = "now-45m"
+interval = "15m"
+license = "Elastic License v2"
+machine_learning_job_id = ["v3_linux_rare_metadata_process"]
+name = "Unusual Linux Process Calling the Metadata Service"
+setup = """## Setup
+
+This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:
+- Elastic Defend
+- Auditd Manager
+
+### Anomaly Detection Setup
+
+Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).
+
+### 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 to your 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/current/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).
+
+### 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" to your 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.
+"""
+risk_score = 21
+rule_id = "9d302377-d226-4e12-b54c-1906b5aec4f6"
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Rule Type: ML",
+    "Rule Type: Machine Learning",
+    "Tactic: Credential Access",
+    "Resources: Investigation Guide",
+]
+type = "machine_learning"
+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 Unusual Linux Process Calling the Metadata Service
+
+In cloud environments, the metadata service provides essential instance-specific data, including credentials and configuration scripts. Adversaries may exploit this service by using atypical processes to access sensitive information, potentially leading to credential theft. The detection rule leverages machine learning to identify anomalous process behavior, flagging unusual access patterns indicative of malicious intent.
+
+### Possible investigation steps
+
+- Review the process name and command line arguments associated with the alert to identify any unusual or suspicious activity.
+- Check the user account under which the process is running to determine if it has legitimate access to the metadata service.
+- Investigate the process's parent process to understand the context of how it was initiated and whether it aligns with expected behavior.
+- Analyze network logs to verify if the process made any outbound connections to the metadata service and assess the volume and frequency of these requests.
+- Cross-reference the process and user information with recent changes or deployments in the environment to rule out any legitimate use cases.
+- Examine system logs for any other suspicious activities or anomalies around the time the alert was triggered, such as unauthorized access attempts or privilege escalations.
+
+### False positive analysis
+
+- Routine system updates or maintenance scripts may access the metadata service, triggering false positives. Users can create exceptions for known update processes to prevent unnecessary alerts.
+- Automated backup or monitoring tools might interact with the metadata service as part of their normal operations. Identify these tools and whitelist their processes to reduce false alarms.
+- Custom scripts developed in-house for configuration management might access the metadata service. Review these scripts and add them to an exception list if they are verified as non-threatening.
+- Cloud management agents provided by the cloud service provider may access the metadata service for legitimate purposes. Verify these agents and exclude them from the detection rule to avoid false positives.
+- Development or testing environments often have processes that mimic production behavior, including metadata service access. Ensure these environments are accounted for in the rule configuration to minimize false alerts.
+
+### Response and remediation
+
+- Isolate the affected instance immediately to prevent further unauthorized access to the metadata service and potential lateral movement within the network.
+- Terminate the unusual process accessing the metadata service to stop any ongoing data exfiltration or credential harvesting.
+- Conduct a thorough review of access logs and process execution history on the affected instance to identify any additional unauthorized activities or compromised credentials.
+- Rotate all credentials and secrets that may have been exposed through the metadata service to mitigate the risk of credential theft and unauthorized access.
+- Implement network segmentation and access controls to restrict access to the metadata service, ensuring only authorized processes and users can interact with it.
+- Escalate the incident to the security operations team for further investigation and to determine if additional instances or services have been compromised.
+- Update and enhance monitoring rules to detect similar anomalous behaviors in the future, focusing on unusual process activities and access patterns to the metadata service."""
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1552"
+name = "Unsecured Credentials"
+reference = "https://attack.mitre.org/techniques/T1552/"
+[[rule.threat.technique.subtechnique]]
+id = "T1552.005"
+name = "Cloud Instance Metadata API"
+reference = "https://attack.mitre.org/techniques/T1552/005/"
+
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+

nldcsc_elastic_rules/rules/ml/credential_access_ml_linux_anomalous_metadata_user.toml

@@ -0,0 +1,141 @@
+[metadata]
+creation_date = "2020/09/22"
+integration = ["auditd_manager", "endpoint"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+anomaly_threshold = 75
+author = ["Elastic"]
+description = """
+Looks for anomalous access to the cloud platform metadata service by an unusual user. The metadata service may be
+targeted in order to harvest credentials or user data scripts containing secrets.
+"""
+false_positives = [
+    """
+    A newly installed program, or one that runs under a new or rarely used user context, could trigger this detection
+    rule. Manual interrogation of the metadata service during debugging or troubleshooting could trigger this rule.
+    """,
+]
+from = "now-45m"
+interval = "15m"
+license = "Elastic License v2"
+machine_learning_job_id = ["v3_linux_rare_metadata_user"]
+name = "Unusual Linux User Calling the Metadata Service"
+setup = """## Setup
+
+This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:
+- Elastic Defend
+- Auditd Manager
+
+### Anomaly Detection Setup
+
+Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).
+
+### 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 to your 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/current/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).
+
+### 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" to your 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.
+"""
+risk_score = 21
+rule_id = "1faec04b-d902-4f89-8aff-92cd9043c16f"
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Rule Type: ML",
+    "Rule Type: Machine Learning",
+    "Tactic: Credential Access",
+    "Resources: Investigation Guide",
+]
+type = "machine_learning"
+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 Unusual Linux User Calling the Metadata Service
+
+Cloud platforms provide a metadata service that allows instances to access configuration data, including credentials. Adversaries may exploit this by using unusual Linux users to query the service, aiming to extract sensitive information. The detection rule leverages machine learning to identify anomalous access patterns, focusing on credential access tactics, thus alerting analysts to potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific Linux user account that accessed the metadata service and the timestamp of the activity.
+- Check the user's login history and recent activity on the system to determine if the access pattern is consistent with their normal behavior or if it appears suspicious.
+- Investigate the source IP address and geolocation associated with the metadata service access to identify any anomalies or unexpected locations.
+- Examine system logs and audit trails for any additional unauthorized or unusual access attempts around the same time frame.
+- Verify if the user account has legitimate reasons to access the metadata service, such as running specific applications or scripts that require metadata information.
+- Assess whether there have been any recent changes to user permissions or roles that could explain the access, and ensure that these changes were authorized.
+- If suspicious activity is confirmed, consider isolating the affected instance and user account to prevent further unauthorized access while conducting a deeper investigation.
+
+### False positive analysis
+
+- Routine administrative scripts may access the metadata service for legitimate configuration purposes. To handle this, identify and whitelist these scripts to prevent unnecessary alerts.
+- Automated backup or monitoring tools might query the metadata service as part of their normal operations. Exclude these tools by adding them to an exception list based on their user accounts or process identifiers.
+- Scheduled tasks or cron jobs that require metadata access for updates or maintenance can trigger false positives. Review and document these tasks, then configure the rule to ignore these specific access patterns.
+- Development or testing environments often simulate metadata service access to mimic production scenarios. Ensure these environments are recognized and excluded from the rule to avoid false alerts.
+- Temporary user accounts created for specific projects or tasks may access the metadata service. Regularly audit these accounts and adjust the rule to exclude them if their access is deemed non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected Linux instance from the network to prevent further unauthorized access or data exfiltration.
+- Revoke any credentials or tokens that may have been exposed or accessed through the metadata service to prevent misuse.
+- Conduct a thorough review of the instance's user accounts and permissions, removing any unauthorized or suspicious accounts and tightening access controls.
+- Analyze system logs and metadata service access logs to identify the source and scope of the breach, focusing on the unusual user activity.
+- Restore the affected instance from a known good backup if any unauthorized changes or malware are detected.
+- Implement additional monitoring and alerting for metadata service access, particularly for unusual user accounts, to detect similar threats in the future.
+- Escalate the incident to the security operations team for further investigation and to determine if additional instances or services are affected."""
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1552"
+name = "Unsecured Credentials"
+reference = "https://attack.mitre.org/techniques/T1552/"
+[[rule.threat.technique.subtechnique]]
+id = "T1552.005"
+name = "Cloud Instance Metadata API"
+reference = "https://attack.mitre.org/techniques/T1552/005/"
+
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+

nldcsc_elastic_rules/rules/ml/credential_access_ml_suspicious_login_activity.toml

@@ -0,0 +1,145 @@
+[metadata]
+creation_date = "2020/03/25"
+integration = ["auditd_manager", "endpoint", "system"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+anomaly_threshold = 50
+author = ["Elastic"]
+description = "Identifies an unusually high number of authentication attempts."
+false_positives = [
+    """
+    Security audits may trigger this alert. Conditions that generate bursts of failed logins, such as misconfigured
+    applications or account lockouts could trigger this alert.
+    """,
+]
+from = "now-45m"
+interval = "15m"
+license = "Elastic License v2"
+machine_learning_job_id = "suspicious_login_activity"
+name = "Unusual Login Activity"
+setup = """## Setup
+
+This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:
+- Elastic Defend
+- Auditd Manager
+- System
+
+### Anomaly Detection Setup
+
+Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).
+
+### 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 to your 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/current/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).
+
+### 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" to your 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.
+
+### System Integration Setup
+The System integration allows you to collect system logs and metrics from your servers with Elastic Agent.
+
+#### The following steps should be executed in order to add the Elastic Agent System integration "system" to your system:
+- Go to the Kibana home page and click “Add integrations”.
+- In the query bar, search for “System” and select the integration to see more details about it.
+- Click “Add System”.
+- Configure the integration name and optionally add a description.
+- Review optional and advanced settings accordingly.
+- Add the newly installed “system” to an existing or a new agent policy, and deploy the agent on your system from which system log files are desirable.
+- Click “Save and Continue”.
+- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/system).
+"""
+references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
+risk_score = 21
+rule_id = "4330272b-9724-4bc6-a3ca-f1532b81e5c2"
+severity = "low"
+tags = [
+    "Use Case: Identity and Access Audit",
+    "Use Case: Threat Detection",
+    "Rule Type: ML",
+    "Rule Type: Machine Learning",
+    "Tactic: Credential Access",
+    "Resources: Investigation Guide",
+]
+type = "machine_learning"
+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 Unusual Login Activity
+The 'Unusual Login Activity' detection leverages machine learning to identify anomalies in authentication patterns, flagging potential brute force attacks. Adversaries exploit credential access by attempting numerous logins to gain unauthorized entry. This rule assesses login frequency and patterns, alerting analysts to deviations indicative of credential abuse, thus enhancing threat detection and identity audit processes.
+
+### Possible investigation steps
+
+- Review the source IP addresses associated with the unusual login attempts to determine if they are known or suspicious.
+- Check the user accounts involved in the alert for any recent changes or unusual activity, such as password resets or privilege escalations.
+- Analyze the timestamps of the login attempts to identify patterns or timeframes that may indicate automated or scripted attacks.
+- Correlate the login attempts with other security events or logs to identify any concurrent suspicious activities, such as failed login attempts or access to sensitive resources.
+- Investigate the geographic locations of the login attempts to see if they align with the user's typical login behavior or if they suggest potential compromise.
+- Assess the risk score and severity of the alert in the context of the organization's security posture and any ongoing threats or incidents.
+
+### False positive analysis
+
+- High login activity from automated scripts or scheduled tasks can trigger false positives. Identify and whitelist these known scripts to prevent unnecessary alerts.
+- Employees using shared accounts may cause an increase in login attempts. Implement user-specific accounts and monitor shared account usage to reduce false positives.
+- Frequent logins from IT personnel conducting routine maintenance can be misinterpreted as unusual activity. Exclude these users or adjust thresholds for specific roles to minimize false alerts.
+- Users with legitimate reasons for high login frequency, such as customer support staff, should be identified and their activity patterns analyzed to adjust detection parameters accordingly.
+- Remote workers using VPNs or accessing systems from multiple locations might trigger alerts. Consider location-based exceptions for known remote access points to avoid false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected user accounts to prevent further unauthorized access and contain the threat.
+- Reset passwords for the compromised accounts and enforce multi-factor authentication (MFA) to enhance security.
+- Conduct a thorough review of recent login activity and access logs to identify any unauthorized access or data exfiltration.
+- Notify the security operations team to monitor for any further suspicious activity and ensure continuous surveillance of the affected systems.
+- Escalate the incident to the incident response team if there is evidence of data compromise or if the attack persists despite initial containment efforts.
+- Implement additional monitoring rules to detect similar brute force attempts in the future, focusing on login frequency and patterns.
+- Review and update access controls and authentication policies to prevent recurrence, ensuring they align with best practices for credential security."""
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1110"
+name = "Brute Force"
+reference = "https://attack.mitre.org/techniques/T1110/"
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+