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

nldcsc_elastic_rules/rules/_deprecated/privilege_escalation_mount_launched_inside_a_privileged_container.toml

@@ -0,0 +1,98 @@
+[metadata]
+creation_date = "2023/10/26"
+integration = ["cloud_defend"]
+deprecation_date = "2025/03/14"
+maturity = "deprecated"
+updated_date = "2025/03/14"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects the use of the mount utility from inside a privileged container. The mount command is used to make a
+device or file system accessible to the system, and then to connect its root directory to a specified mount point on the
+local file system. When launched inside a privileged container--a container deployed with all the capabilities of the
+host machine-- an attacker can access sensitive host level files which could be used for further privilege escalation
+and container escapes to the host machine. Any usage of mount inside a running privileged container should be further
+investigated.
+"""
+from = "now-6m"
+index = ["logs-cloud_defend*"]
+interval = "5m"
+language = "eql"
+license = "Elastic License v2"
+name = "Deprecated - Mount Launched Inside a Privileged Container"
+references = [
+    "https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation#privileged",
+]
+risk_score = 21
+rule_id = "41f7da9e-4e9f-4a81-9b58-40d725d83bc0"
+severity = "low"
+tags = [
+    "Data Source: Elastic Defend for Containers",
+    "Domain: Container",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where event.module == "cloud_defend" and  event.type== "start" and
+(process.name== "mount" or process.args== "mount") and container.security_context.privileged == true
+'''
+note = """## Setup
+
+This rule was deprecated in the 8.18 and 9.0 versions of the Elastic Stack due to deprecation of the 'Defend For Containers' integration. Users using 8.18+ versions should disable this rule and enable linux-based rules tagged "Domain: Container".
+
+## 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 Deprecated - Mount Launched Inside a Privileged Container
+
+In containerized environments, the `mount` utility is crucial for attaching file systems to the system's directory tree. When executed within a privileged container, which has extensive host capabilities, it can be exploited by adversaries to access sensitive host files, potentially leading to privilege escalation or container escapes. The detection rule identifies such misuse by monitoring the execution of `mount` in privileged containers, flagging potential security threats for further investigation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm that the process name or arguments include "mount" and that the container's security context is marked as privileged.
+- Identify the container involved in the alert by examining the container ID or name, and gather information about its purpose and the applications it runs.
+- Check the container's deployment configuration to verify if it was intentionally set as privileged and assess whether this level of privilege is necessary for its function.
+- Investigate the user or process that initiated the mount command within the container to determine if it aligns with expected behavior or if it indicates potential malicious activity.
+- Examine the mounted file systems and directories to identify any sensitive host files that may have been accessed or exposed.
+- Review logs and historical data for any previous suspicious activities associated with the same container or user to identify patterns or repeated attempts at privilege escalation.
+
+### False positive analysis
+
+- Routine maintenance tasks within privileged containers may trigger the rule. Exclude known maintenance scripts or processes by adding them to an exception list based on their unique identifiers or command patterns.
+- Backup operations that require mounting file systems might be flagged. Identify and exclude these operations by specifying the backup process names or arguments in the rule exceptions.
+- Development or testing environments often use privileged containers for convenience. If these environments are known and controlled, consider excluding them by container IDs or labels to reduce noise.
+- Automated deployment tools that use mount commands in privileged containers can be mistaken for threats. Review and whitelist these tools by their process names or specific arguments to prevent false alerts.
+- Certain monitoring or logging solutions may use mount operations for data collection. Verify these solutions and exclude their processes if they are legitimate and necessary for system operations.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further access to sensitive host files. This can be done by stopping the container or disconnecting it from the network.
+- Review and revoke any unnecessary privileges from the container's security context to prevent similar incidents. Ensure that containers run with the least privileges necessary.
+- Conduct a thorough analysis of the container's file system and logs to identify any unauthorized access or modifications to host files.
+- If unauthorized access is confirmed, perform a comprehensive audit of the host system to check for any signs of compromise or privilege escalation attempts.
+- Patch and update the container image and host system to address any vulnerabilities that may have been exploited.
+- Implement stricter access controls and monitoring for privileged containers, ensuring that only trusted users and processes can execute sensitive commands like `mount`.
+- Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures or incident response actions."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1611"
+name = "Escape to Host"
+reference = "https://attack.mitre.org/techniques/T1611/"
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+

nldcsc_elastic_rules/rules/_deprecated/privilege_escalation_potential_container_escape_via_modified_notify_on_release_file.toml

@@ -0,0 +1,99 @@
+[metadata]
+creation_date = "2023/10/26"
+integration = ["cloud_defend"]
+deprecation_date = "2025/03/14"
+maturity = "deprecated"
+updated_date = "2025/03/14"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects modification of the cgroup notify_on_release file from inside a container. When the notify_on_release
+flag is enabled (1) in a cgroup, then whenever the last task in the cgroup exits or attaches to another cgroup, the
+command specified in the release_agent file is run and invoked from the host. A privileged container with SYS_ADMIN
+capabilities, enables a threat actor to mount a cgroup directory and modify the notify_on_release flag in order to take
+advantage of this feature, which could be used for further privilege escalation and container escapes to the host
+machine.
+"""
+from = "now-6m"
+index = ["logs-cloud_defend*"]
+interval = "5m"
+language = "eql"
+license = "Elastic License v2"
+name = "Deprecated - Potential Container Escape via Modified notify_on_release File"
+references = [
+    "https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/",
+    "https://sysdig.com/blog/detecting-mitigating-cve-2022-0492-sysdig/",
+]
+risk_score = 73
+rule_id = "ef65e82c-d8b4-4895-9824-5f6bc6166804"
+severity = "high"
+tags = [
+    "Data Source: Elastic Defend for Containers",
+    "Domain: Container",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+file where event.module == "cloud_defend" and event.action == "open" and
+event.type == "change" and file.name : "notify_on_release"
+'''
+note = """## Setup
+
+This rule was deprecated in the 8.18 and 9.0 versions of the Elastic Stack due to deprecation of the 'Defend For Containers' integration. Users using 8.18+ versions should disable this rule and enable linux-based rules tagged "Domain: Container".
+
+## 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 Deprecated - Potential Container Escape via Modified notify_on_release File
+
+In containerized environments, the `notify_on_release` file in cgroups can trigger host-level commands when a cgroup becomes empty. Adversaries exploit this by modifying the file from privileged containers, potentially executing unauthorized commands on the host. The detection rule monitors changes to `notify_on_release` files, flagging suspicious modifications indicative of privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file involved is indeed the "notify_on_release" file and verify the event.module is "cloud_defend" with event.action as "open" and event.type as "change".
+- Identify the container from which the modification attempt originated by examining the associated metadata, such as container ID or name, to understand the context of the alert.
+- Check the privileges and capabilities assigned to the container, specifically looking for SYS_ADMIN capabilities, which could allow modification of cgroup settings.
+- Investigate the release_agent file associated with the cgroup to determine if any unauthorized or suspicious commands are configured to execute upon cgroup release.
+- Review recent activity logs and command history within the container to identify any anomalous behavior or commands that could indicate an attempt to exploit the notify_on_release mechanism.
+- Assess the potential impact on the host system by determining if any unauthorized commands have been executed as a result of the modification, and evaluate the need for containment or remediation actions.
+
+### False positive analysis
+
+- Routine maintenance tasks in containerized environments may involve legitimate modifications to the notify_on_release file. Users should verify if such changes align with scheduled maintenance activities.
+- Automated container orchestration tools might modify cgroup settings, including the notify_on_release file, as part of their normal operations. Users can create exceptions for known orchestration tools by identifying their specific process IDs or user accounts.
+- Some containerized applications may require modifications to cgroup settings for performance tuning or resource management. Users should document these applications and exclude their expected behavior from triggering alerts.
+- Development and testing environments often involve frequent changes to container configurations, including cgroup files. Users can reduce noise by applying the rule only to production environments or by setting up separate monitoring profiles for non-production systems.
+- If a specific container consistently triggers alerts without malicious intent, users can whitelist the container by its unique identifier or image name, ensuring that only unexpected changes are flagged.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized actions. This can be done by stopping the container or disconnecting it from the network.
+- Review and revoke any unnecessary privileges or capabilities, such as SYS_ADMIN, from the container to minimize the risk of exploitation.
+- Inspect the release_agent file associated with the cgroup to identify any unauthorized commands or scripts that may have been set for execution.
+- Remove or reset any malicious or unauthorized entries in the release_agent file to prevent further execution of host-level commands.
+- Conduct a thorough audit of the host system for any signs of compromise or unauthorized access, focusing on logs and system changes around the time of the alert.
+- Patch and update the container runtime and host operating system to address any known vulnerabilities that could facilitate container escapes.
+- Enhance monitoring and alerting for similar activities by ensuring that all cgroup modifications are logged and reviewed regularly, and consider implementing additional security controls such as AppArmor or SELinux to restrict container capabilities."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1611"
+name = "Escape to Host"
+reference = "https://attack.mitre.org/techniques/T1611/"
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+

nldcsc_elastic_rules/rules/_deprecated/privilege_escalation_potential_container_escape_via_modified_release_agent_file.toml

@@ -0,0 +1,98 @@
+[metadata]
+creation_date = "2023/10/26"
+integration = ["cloud_defend"]
+deprecation_date = "2025/03/14"
+maturity = "deprecated"
+updated_date = "2025/03/14"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects modification of the CGroup release_agent file from inside a privileged container. The release_agent is
+a script that is executed at the termination of any process on that CGroup and is invoked from the host. A privileged
+container with SYS_ADMIN capabilities, enables a threat actor to mount a CGroup directory and modify the release_agent
+which could be used for further privilege escalation and container escapes to the host machine.
+"""
+from = "now-6m"
+index = ["logs-cloud_defend*"]
+interval = "5m"
+language = "eql"
+license = "Elastic License v2"
+name = "Deprecated - Potential Container Escape via Modified release_agent File"
+references = [
+    "https://blog.aquasec.com/threat-alert-container-escape",
+    "https://sysdig.com/blog/detecting-mitigating-cve-2022-0492-sysdig/",
+    "https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation#privileged-escape-abusing-existent-release_agent-cve-2022-0492-poc1",
+]
+risk_score = 47
+rule_id = "160896de-b66f-42cb-8fef-20f53a9006ea"
+severity = "medium"
+tags = [
+    "Data Source: Elastic Defend for Containers",
+    "Domain: Container",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+file where event.module == "cloud_defend" and event.action == "open" and
+event.type == "change" and file.name : "release_agent"
+'''
+note = """## Setup
+
+This rule was deprecated in the 8.18 and 9.0 versions of the Elastic Stack due to deprecation of the 'Defend For Containers' integration. Users using 8.18+ versions should disable this rule and enable linux-based rules tagged "Domain: Container".
+
+## 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 Deprecated - Potential Container Escape via Modified release_agent File
+
+In containerized environments, the release_agent file in CGroup directories can execute scripts upon process termination. Adversaries exploit this by modifying the file from privileged containers, potentially escalating privileges or escaping to the host. The detection rule monitors changes to the release_agent file, flagging unauthorized modifications indicative of such exploits.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file involved is the release_agent file and that the event.module is "cloud_defend" with event.action as "open" and event.type as "change".
+- Identify the container from which the modification attempt originated, focusing on whether it has SYS_ADMIN capabilities, which could indicate a privileged container.
+- Check the history of the release_agent file for any recent changes or modifications, including timestamps and user accounts involved, to understand the context of the modification.
+- Investigate the processes running within the container at the time of the alert to identify any suspicious or unauthorized activities that could be related to privilege escalation attempts.
+- Examine the network activity and connections from the container to detect any unusual outbound traffic that might suggest an attempt to communicate with external systems or exfiltrate data.
+- Review system logs and audit logs on the host for any signs of unauthorized access or privilege escalation attempts that coincide with the alert timestamp.
+- Assess the security posture of the container environment, including the configuration of CGroup directories and permissions, to identify potential vulnerabilities that could be exploited for container escape.
+
+### False positive analysis
+
+- Routine maintenance scripts or system updates may modify the release_agent file without malicious intent. Users can create exceptions for known maintenance activities by identifying the specific processes or scripts involved and excluding them from the rule.
+- Automated container management tools might access and modify the release_agent file as part of their normal operations. Users should verify the legitimacy of these tools and whitelist their actions to prevent unnecessary alerts.
+- Custom container orchestration solutions could interact with the release_agent file for legitimate reasons. Users should document these interactions and configure the rule to ignore changes made by these trusted solutions.
+- Development and testing environments often involve frequent changes to container configurations, including the release_agent file. Users can reduce false positives by setting up separate monitoring profiles for these environments, allowing more lenient detection thresholds.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized actions or potential spread to other containers or the host system.
+- Revoke SYS_ADMIN capabilities from the container to limit its ability to modify critical system files and directories.
+- Conduct a thorough review of the modified release_agent file to identify any malicious scripts or commands that may have been inserted.
+- Restore the release_agent file to its original state from a known good backup to ensure no unauthorized scripts are executed.
+- Investigate the source of the privilege escalation to determine how the adversary gained SYS_ADMIN capabilities and address any security gaps.
+- Escalate the incident to the security operations team for further analysis and to assess the potential impact on the host system.
+- Implement additional monitoring and alerting for changes to critical files and directories within privileged containers to enhance detection of similar threats in the future."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1611"
+name = "Escape to Host"
+reference = "https://attack.mitre.org/techniques/T1611/"
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+

nldcsc_elastic_rules/rules/_deprecated/privilege_escalation_printspooler_malicious_driver_file_changes.toml

@@ -0,0 +1,51 @@
+[metadata]
+creation_date = "2021/07/06"
+deprecation_date = "2022/03/16"
+maturity = "deprecated"
+updated_date = "2022/03/16"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects the creation or modification of a print driver with an unusual file name. This may indicate attempts to exploit
+privilege escalation vulnerabilities related to the Print Spooler service. For more information refer to CVE-2021-34527
+and verify that the impacted system is investigated.
+"""
+from = "now-9m"
+index = ["winlogbeat-*", "logs-endpoint.events.*", "logs-windows.*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential PrintNightmare File Modification"
+references = [
+    "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527",
+    "https://github.com/afwu/PrintNightmare",
+]
+risk_score = 73
+rule_id = "5e87f165-45c2-4b80-bfa5-52822552c997"
+severity = "high"
+tags = ["Elastic", "Host", "Windows", "Threat Detection", "Privilege Escalation"]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+/* This rule is compatible with both Sysmon and Elastic Endpoint */
+
+file where process.name : "spoolsv.exe" and 
+ file.name : ("kernelbase.dll", "ntdll.dll", "kernel32.dll", "winhttp.dll", "user32.dll") and
+ file.path : "?:\\Windows\\System32\\spool\\drivers\\x64\\3\\*"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1068"
+reference = "https://attack.mitre.org/techniques/T1068/"
+name = "Exploitation for Privilege Escalation"
+
+
+[rule.threat.tactic]
+id = "TA0004"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+name = "Privilege Escalation"
+

nldcsc_elastic_rules/rules/_deprecated/privilege_escalation_printspooler_malicious_registry_modification.toml

@@ -0,0 +1,50 @@
+[metadata]
+creation_date = "2021/07/06"
+deprecation_date = "2022/03/16"
+maturity = "deprecated"
+updated_date = "2022/03/16"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects attempts to exploit privilege escalation vulnerabilities related to the Print Spooler service. For more
+information refer to CVE-2021-34527 and verify that the impacted system is investigated.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential PrintNightmare Exploit Registry Modification"
+references = [
+    "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527",
+    "https://github.com/afwu/PrintNightmare",
+]
+risk_score = 73
+rule_id = "6506c9fd-229e-4722-8f0f-69be759afd2a"
+severity = "high"
+tags = ["Elastic", "Host", "Windows", "Threat Detection", "Privilege Escalation"]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+/* This rule is not compatible with Sysmon due to schema issues */
+
+registry where process.name : "spoolsv.exe" and
+  (registry.path : "HKLM\\SYSTEM\\ControlSet*\\Control\\Print\\Environments\\Windows*\\Drivers\\Version-3\\mimikatz*\\Data File" or
+  (registry.path : "HKLM\\SYSTEM\\ControlSet*\\Control\\Print\\Environments\\Windows*\\Drivers\\Version-3\\*\\Configuration File" and
+   registry.data.strings : ("kernelbase.dll", "ntdll.dll", "kernel32.dll", "winhttp.dll", "user32.dll")))
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+name = "Exploitation for Privilege Escalation"
+id = "T1068"
+reference = "https://attack.mitre.org/techniques/T1068/"
+
+
+[rule.threat.tactic]
+name = "Privilege Escalation"
+id = "TA0004"
+reference = "https://attack.mitre.org/tactics/TA0004/"

nldcsc_elastic_rules/rules/_deprecated/privilege_escalation_root_login_without_mfa.toml

@@ -0,0 +1,104 @@
+[metadata]
+creation_date = "2020/07/06"
+integration = ["aws"]
+deprecation_date = "2025/11/21"
+maturity = "deprecated"
+updated_date = "2025/11/21"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies attempts to login to AWS as the root user without using multi-factor authentication (MFA). Amazon AWS best
+practices indicate that the root user should be protected by MFA.
+"""
+false_positives = [
+    """
+    Some organizations allow login with the root user without MFA, however, this is not considered best practice by AWS
+    and increases the risk of compromised credentials.
+    """,
+]
+from = "now-60m"
+index = ["filebeat-*", "logs-aws.cloudtrail-*"]
+interval = "10m"
+language = "kuery"
+license = "Elastic License v2"
+name = "Deprecated - AWS Root Login Without MFA"
+note = """## Triage and analysis
+
+### Investigating Deprecated - AWS Root Login Without MFA
+
+Multi-factor authentication (MFA) in AWS is a simple best practice that adds an extra layer of protection on top of your user name and password. With MFA enabled, when a user signs in to an AWS Management Console, they will be prompted for their user name and password, as well as for an authentication code from their AWS MFA device. Taken together, these multiple factors provide increased security for your AWS account settings and resources.
+
+For more information about using MFA in AWS, access the [official documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html).
+
+The AWS root account is the one identity that has complete access to all AWS services and resources in the account, which is created when the AWS account is created. AWS strongly recommends that you do not use the root user for your everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create your first IAM user. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks. Amazon provides a [list of the tasks that require root user](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root).
+
+This rule looks for attempts to log in to AWS as the root user without using multi-factor authentication (MFA), meaning the account is not secured properly.
+
+#### Possible investigation steps
+
+- Investigate other alerts associated with the user account during the past 48 hours.
+- Examine whether this activity is common in the environment by looking for past occurrences on your logs.
+- Consider the source IP address and geolocation for the calling user who issued the command. Do they look normal for the calling user?
+- Examine the commands, API calls, and data management actions performed by the account in the last 24 hours.
+- Contact the account owner and confirm whether they are aware of this activity.
+- If you suspect the account has been compromised, scope potentially compromised assets by tracking access to servers,
+services, and data accessed by the account in the last 24 hours.
+
+### False positive analysis
+
+- While this activity is not inherently malicious, the root account must use MFA. The security team should address any potential benign true positive (B-TP), as this configuration can risk the entire cloud environment.
+
+### Response and remediation
+
+- Initiate the incident response process based on the outcome of the triage.
+- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
+    - Identify the account role in the cloud environment.
+    - Identify the services or servers involved criticality.
+    - Work with your IT team to identify and minimize the impact on users.
+    - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
+    - Identify if there are any regulatory or legal ramifications related to this activity.
+- Configure multi-factor authentication for the user.
+- Follow security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.
+- 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).
+
+## Setup
+
+The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = ["https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html"]
+risk_score = 73
+rule_id = "bc0c6f0d-dab0-47a3-b135-0925f0a333bc"
+severity = "high"
+tags = [
+    "Domain: Cloud",
+    "Data Source: AWS",
+    "Data Source: Amazon Web Services",
+    "Data Source: AWS Route53",
+    "Use Case: Identity and Access Audit",
+    "Resources: Investigation Guide",
+    "Tactic: Privilege Escalation",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:aws.cloudtrail and event.provider:signin.amazonaws.com and event.action:ConsoleLogin and
+  aws.cloudtrail.user_identity.type:Root and
+  aws.cloudtrail.console_login.additional_eventdata.mfa_used:false and
+  event.outcome:success
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+

nldcsc_elastic_rules/rules/_deprecated/privilege_escalation_setgid_bit_set_via_chmod.toml

@@ -0,0 +1,56 @@
+[metadata]
+creation_date = "2020/04/23"
+deprecation_date = "2021/03/16"
+maturity = "deprecated"
+updated_date = "2021/03/16"
+
+[rule]
+author = ["Elastic"]
+description = """
+An adversary may add the setgid bit to a file or directory in order to run a file with the privileges of the owning
+group. An adversary can take advantage of this to either do a shell escape or exploit a vulnerability in an application
+with the setgid bit to get code running in a different user’s context. Additionally, adversaries can use this mechanism
+on their own malware to make sure they're able to execute in elevated contexts in the future.
+"""
+from = "now-9m"
+index = ["auditbeat-*", "logs-endpoint.events.*"]
+language = "lucene"
+license = "Elastic License"
+max_signals = 33
+name = "Setgid Bit Set via chmod"
+risk_score = 21
+rule_id = "3a86e085-094c-412d-97ff-2439731e59cb"
+severity = "low"
+tags = ["Elastic", "Host", "Linux", "Threat Detection", "Privilege Escalation"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.category:process AND event.type:(start or process_started) AND process.name:chmod AND process.args:(g+s OR /2[0-9]{3}/) AND NOT user.name:root
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1548"
+name = "Abuse Elevation Control Mechanism"
+reference = "https://attack.mitre.org/techniques/T1548/"
+[[rule.threat.technique.subtechnique]]
+id = "T1548.001"
+name = "Setuid and Setgid"
+reference = "https://attack.mitre.org/techniques/T1548/001/"
+
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"